Evitação de mesclagem: técnicas de aprimoramento de Política de Privacidade no protocolo Bitcoin

Mike ouvir é um desenvolvedor de software que trabalha na equipe de desenvolvimento do Bitcoin CORE e também no Google. Neste artigo, Mike discute alguns vazamentos de Política de Privacidade do Bitcoin e uma nova técnica que atualmente não tem um nome, mas que ele chama deevitar mesclagem.

Introdução à Política de Privacidade do Bitcoin

É um fato lamentável que, apesar da reputação do bitcoin na imprensa, seus usuários atualmente vazam grandes quantidades de informações pessoais.

É angustiantemente fácil para alguém Aprenda sobre seu saldo, histórico de negociação e mais. Proteger essas informações é uma função básica de qualquer sistema financeiro útil.

Aqui estão alguns vazamentos que surgem no uso diário.

Reutilização de endereços

Muitos problemas de Política de Privacidade no Bitcoin são causados ​​por um adversário aprendendo quais saídas são de propriedade da mesma carteira. Se você puder calcular isso, poderá descobrir o saldo da carteira e possivelmente com quem ela foi negociada.

A maneira mais comum de isso acontecer é quando endereços são reutilizados. Isso é facilmente compreendido porque sites populares como blockchain.info indexam saídas e transações por endereço, permitindo que você pesquise rapidamente todas as transações que fazem referência a qualquer endereço fornecido.

A reutilização de endereços tem muitas causas raiz diferentes. Aqui estão algumas amostras:

1. Problemas com a carteira do usuário final

A biblioteca bitcoinj sempre reutiliza endereços por Política, vazando assim muitas informações privadas. Há duas razões para isso. Uma é que antes do desenvolvimento das carteiras HD, usar constantemente as chaves resultaria na invalidação de backups de carteiras antigas.

O Bitcoin-Qt tem um “pool de chaves” para tentar resolver isso, mas isso só adia o problema: o pool de chaves pode ser silenciosamente esgotado, dando o mesmo problema. Invalidar backups pode fazer com que as pessoas percam dinheiro.

Uma vez que as carteiras HD forem implementadas (o que está em andamento), esse problema desaparecerá, deixando apenas o segundo problema de pressão de memória em telefones de baixo custo. A reutilização de endereços ainda pode ser necessária em tais dispositivos, mas telefones de alto custo e desktops/laptops T devem encontrar problemas.

2. Problemas com a carteira do servidor

Não há implementações de carteiras públicas e de código aberto que sejam escaláveis para carteiras com números muito grandes de chaves. Até onde eu sei, as exchanges e os principais processadores de pagamento tiveram que implementar muito código personalizado para contornar a falta de escalabilidade do Bitcoin-Qt (e bitcoinj).

Isso pressiona os receptores a reutilizar endereços.

3. Convenções sociais

Pessoas colocando endereços estáticos em assinaturas de fóruns, códigos QR, ETC

Com o tempo, precisaremos progredir com todas essas questões para reduzir a reutilização de endereços. Carteiras HD e o protocolo de pagamento são ferramentas importantes para nos ajudar a atingir isso.

Alterar saídas

Um dos vazamentos de Política de Privacidade mais irritantes no Bitcoin é que as pessoas descobrem os limites mínimos do seu saldo.

Como isso funciona pode ser entendido intuitivamente por meio da analogia do dinheiro. Com o dinheiro de papel, se você entregar uma nota de 500 CHF para pagar uma bebida que custa apenas 5 CHF, o barman descobre que seu saldo é de pelo menos 495 CHF. Pode ser mais alto, é claro, mas pelo menos não é menor. O Bitcoin tem o mesmo problema.

A causa raiz desse problema é uma incompatibilidade entre o tamanho do pagamento que você deseja fazer e as moedas (saídas) disponíveis para você.

Se a incompatibilidade for em uma direção, você terá muitas saídas pequenas e fazer pagamentos por quantias não pequenas começará a custar muito em taxas, porque as transações geradas serão enormes.

Se a incompatibilidade for na outra direção, pagar por algo pequeno exigirá o uso de uma moeda grande, e o troco vazará dados valiosos sobre o quão rico você é.

Tráfego de rede

As conexões P2P do Bitcoin não são criptografadas. Um motivo é que a maioria dos dados que fluem pela rede P2P é pública, portanto criptografá-los parece inútil.

Outro motivo é que, por sua própria natureza, quando você se conecta a uma rede P2P, seus pares podem ser qualquer pessoa e fazer qualquer coisa – por exemplo, eles podem ser nós administrados pela NSA.

E isso nem é algo ruim! Por que a NSA T deveria executar nós? Se alguém dissesse a eles para não fazerem isso, isso implicaria em algum tipo de autoridade central que estava ditando quem pode executar o Bitcoin e quem T. T queremos isso.

Então criptografar dados é útil quando você tem uma ideia clara de quem deve vê-los e quem T deve. Criptografar dados públicos para pessoas aleatórias sobre as quais você não sabe nada – não é tão útil.

Apesar de tudo isso, ainda há quatro razões pelas quais seria útil criptografar conexões.

O primeira razãoé paraFiltros Bloom.

Essas são representações compactas do que é relevante para sua carteira: normalmente, quais endereços/chaves estão nela. Um filtro é ONE e pode ser barulhento, ou seja, você T pode ler endereços diretamente de um filtro, você pode apenas aplicá-lo à cadeia de blocos e ver o que ele corresponde.

Os filtros podem ter falsos positivos, então um nó nunca pode ter certeza se um endereço é realmente seu ou não. Isso é muito bom, mas mesmo com uma alta taxa de falsos positivos, ainda reduz bastante as moedas que você pode ter.

Os filtros Bloom não são informações públicas, eles são apenas compartilhados entre um cliente e o nó ao qual ele se conecta. Então seria bom escondê-los contra bisbilhoteiros passivos, como pessoas que compartilham seu hotspot wifi.

O segunda razãoé que, embora as transações sejam públicas, seu endereço IP de origem não é (ou não deveria ser).

Mas um adversário que consegue observar muitos links de internet poderia decidir com bastante segurança onde uma transação começou, registrando precisamente os horários em que uma transação foi vista pela primeira vez e examinando o primeiro momento em que ela transitou por um LINK de fibra.

Parece que algumas agências de inteligência poderiam fazer esse tipo de análise. Criptografar links T garante uma correção para isso porque a análise de tempo ainda pode ser possível, mas certamente torna isso mais difícil.

O terceira razãoé que se a criptografia fosse combinada com a autenticação “confiança no primeiro uso” (TOFU), seria mais difícil até mesmo para MITMs ativos realizarem ataques Sybil em carteiras e alimentá-las com dados ruins.

Isso é mais importante para clientes SPV do que nós completos, mas ambos podem se beneficiar.

O razão finalse isso for implementado corretamente, o uso de SSL para conexões P2P tornaria mais difícil identificá-las e bloqueá-las usando dispositivos de inspeção profunda de pacotes.

CoinJoin

De todos os problemas acima, a solução para o vazamento de dados por meio de saídas de alterações é uma das mais debatidas (embora muitas pessoas T percebam que estão debatendo isso).

O Proposta CoinJoin recebeu muita atenção e algumas implementações iniciais. Algumas pessoas veem isso principalmente como uma ferramenta de Política de Privacidade , e outras como uma maneira de tentar quebrar o rastreamento de moedas.

Quando usado para Política de Privacidade, pode ser melhor descrito como uma maneira de tentar excluir informações que já foram vazadas.

No entanto, o CoinJoin tem uma série de problemas sérios que tornam uma alternativa desejável.

É profundamente complexo de implementar bem, vulnerável a ataques Sybil/DoS (geralmente são a mesma coisa neste contexto), legalmente questionável e não está claro se a ofuscação funciona.

O Roubo no mercado de ovelhas viu alguém alegar rastrear moedas por meio de tumblers e mixers, e aparentemente com um mínimo de sucesso. Uma das ferramentas do rastreador eram ataques sybil/DoS em serviços de mixagem, então essas não são uma preocupação teórica.

Embora implementações de brinquedo não sejam muito difíceis de montar, implementações robustas no mundo real, com tratamento adequado de tempo limite, verificações de segurança, boa integração com a interface de carteira ETC, exigem muito mais esforço.

Até agora, apenas blockchain.info conseguiu criar um (em sharedcoin.com), e você só precisa confiar que ele T KEEP logs. Caso contrário, qualquer um com os logs poderia desmisturar.

Talvez a questão menos discutida seja a experiência do usuário.

Uma transação CoinJoin requer que outras pessoas participem. Quanto mais pessoas participarem, melhor. No entanto, o Bitcoin atualmente só atinge o pico de cerca de uma transação por segundo.

Mesmo que todas as transações fossem unidas por CoinJoin e todas se reunissem em um único ponto (aff, centralização!), você ainda teria que esperar de 10 a 15 segundos para conseguir um bom conjunto de participantes para interagir.

Isso é só para começar o protocolo. Então, todos esses participantes teriam que recuperar a transação do candidato e assinar. Se algum tempo acabar, a coisa toda tem que começar de novo.

Em condições precárias, pode facilmente levar um minuto ou mais para concluir esse processo, especialmente se alguns participantes tiverem redes instáveis (por exemplo, telefones) e estiverem usando Tor. Considerando que estamos tentando melhorar o desempenho em vez de reduzi-lo, isso parece um grande problema por si só.

Embora o aumento do tráfego e do uso ajudasse a reduzir esse problema, mesmo que o tráfego dobrasse, dividir o único ponto de encontro central imediatamente colocaria os tempos de espera de volta à estaca ONE.

Você pode resolver esse problema fazendo CoinJoins em segundo plano, sem relação com um gasto real que esteja ocorrendo.

Isso resolve o problema de esperar na fila da cafeteria, mas taxas devem ser pagas sobre essas transações, e pode ser difícil explicar às pessoas por que seu saldo caiu repentinamente da noite para o dia devido a um imposto de Política de Privacidade inesperado.

Esse tipo de surpresa desagradável tornaria o Bitcoin pouco atraente para usuários comuns. Também levanta a questão de quando e com que frequência isso é feito.

Fusão de evasão

Como uma causa raiz comum de vazamentos de Política de Privacidade é uma incompatibilidade entre os tamanhos das moedas disponíveis e o que é necessário, parece que poderíamos abordar o problema de outro ângulo: evitando criar qualquer vazamento de informações que precise ser apagado em primeiro lugar.

Considere o caso de ALICE, uma funcionária de uma cafeteria que recebe um salário.

ALICE faz um ótimo trabalho e seu chefe reconhece isso com um salário maior que o normal.

Seu colega de trabalho Bob suspeita que T recebe tanto quanto ALICE e quer saber, então convence ALICE a fazer um pequeno pagamento a ele logo após o dia do pagamento (talvez eles façam uma aposta e Bob ganhe).

Com Bitcoin regular, a carteira de Alice provavelmente usará sua saída de salário e a mudança revelará o que ela recebe. Mesmo que ela já tenha feito vários pagamentos, Bob pode Siga a cadeia de transações para trás até encontrar um número razoavelmente redondo na data certa e concluir que é mais provável que seja o pagamento de salário dela.

O CoinJoin simples também T a ajuda. Ela colocaria uma entrada grande na mistura e receberia uma saída grande.

Ela poderia Request muitas saídas menores, mas a entrada ainda seria do tamanho de um salário e na data certa. A menos que muitas pessoas que ganham salários do tamanho de uma cafeteria compartilhem a mesma transação CoinJoin, o vazamento T foi corrigido.

O que ela realmente precisa é evitar ter uma saída única tão grande em primeiro lugar. Vamos chamar isso de evitação de mesclagem.

Quando ela submete seuRequest de pagamento BIP 70ao seu empregador, ela pede uma boa mistura de denominações, como se estivesse comprando dinheiro em uma casa de câmbio.

A Request também especifica um endereço exclusivo para cada saída. O protocolo de pagamento não especifica como uma carteira deve satisfazer essa Request, mas permite a possibilidade de que a carteira do remetente envie múltiplas transações independentes para satisfazer as saídas desejadas.

[post-citação]

Se o empregador dela usar uma carteira antiga que T entenda a prevenção de mesclagem, ela gerará e enviará a ela uma única transação gigante com muitas entradas (de todos os cafés) e todas as saídas solicitadas.

Parecerá muito com uma transação CoinJoin, mas tem apenas um único participante. No entanto, não há como saber isso apenas olhando para a blockchain.

Se o empregador dela usar uma carteira mais nova que entenda a prevenção de mesclagem, algo melhor acontecerá: ela receberá uma série de transações diferentes e menores, cada uma das quais criará uma ou duas das saídas que ela solicitou.

Não há nada que LINK nenhum deles. Como ela confia que seu empregador não gastará duas vezes, ela pode espalhar a transmissão para que nem mesmo o tempo os denuncie.

Se a seleção de saídas for escolhida de forma inteligente, ela nunca estará em uma situação em que tenha saídas estranhamente grandes ou pequenas para um pagamento específico. Bob simplesmente verá uma pequena transação que produz uma pequena saída de troco, e não importa o quão longe ele rastreie para trás, ele nunca encontrará nenhuma saída do tamanho de um salário. ALICE vence!

Saídas de alteração podem vazar dados de outra forma. Bob falhou em sua tentativa de Aprenda o salário de Alice rastreando para trás através da cadeia de blocos, mas ele ainda pode observar a saída de alteração do pagamento que recebeu para ver o que acontece com ela.

Se a mudança for posteriormente combinada com muitas outras para criar um pagamento enorme, de repente ele sabe que ALICE deve ter possuído pelo menos essa mesma quantia de dinheiro.

Aqui, CoinJoin parece que deveria funcionar – se a mudança for para uma mistura, quem pode dizer quem é dono das saídas? Mas é frágil. Mesmo que as saídas sejam dimensionadas aleatoriamente, na ausência de prevenção de mesclagem, elas serão recombinadas novamente para fazer um grande pagamento.

Se ALICE mencionar de passagem que vai viajar com o namorado, Bob pode olhar as saídas da mixagem em que a alteração foi feita e esperar que algumas das saídas sejam recombinadas.

Se 1/3 dos resultados não forem gastos, 1/3 forem gastos sem serem combinados de forma significativa e outro 1/3 for combinado em um pagamento de US$ 5.000 na noite anterior à menção de ALICE sobre suas férias, é bem provável que a viagem esteja custando a ela US$ 5.000.

Propriedades de implementação

Este esquema tem várias coisas que o tornam agradável de implementar:

• Ele pode ser escrito incrementalmente – um algoritmo simples e não muito inteligente pode, no entanto, ainda melhorar a Política de Privacidade de alguém. Mais tarde, um algoritmo melhor pode ser desenvolvido e implantado, mas T requer nenhuma atualização global complicada. Isso é um bom ajuste para o modelo de desenvolvimento de carteiras concorrentes e de acessos esporádicos conduzido por voluntários que o Bitcoin tem.
• É muito simples e não tem partes móveis ou grandes máquinas de estado. Você T precisa se preocupar com um celular aleatório do outro lado do mundo entrando em um túnel no momento errado, ou executando uma reimplementação bugada do software.
• Não há centralização, nem mesmo servidores de encontro temporários.
• Não há riscos legais, porque você não está contando com nenhum serviço que possa ser considerado uma ferramenta de lavagem de dinheiro.
• É robusto. Acima, dei exemplos de como o CoinJoin pode parecer funcionar, mas ainda vazar na presença de muito pouca informação adicional. A prevenção de mesclagem T tem esse problema.

Há também algumas desvantagens:

• O quão boa é sua Política de Privacidade depende muito de quão inteligentemente as pessoas que lhe enviam dinheiro elaboram transações. Assim, sua Política de Privacidade depende de pessoas que podem não ter muito incentivo para fazer algo a respeito. Esperançosamente, um software de carteira comum faria a coisa certa por padrão.
• Ele aumenta o número de transações, embora a sobrecarga não seja tão alta quanto você pode pensar – uma transação é meramente uma lista de entradas, saídas e um cabeçalho de dois campos (versão e tempo de bloqueio). Entradas e saídas não são realmente alteradas em uma boa implementação de CoinJoin, e a versão/tempo de bloqueio poderia ser facilmente compactada/codificada em varint para economizar espaço. A diferença seria na ordem de bytes em vez de quilobytes.
• Ele depende do protocolo de pagamento. Mas muitas coisas dependem disso, e o protocolo de pagamento é essencial para reprimir a reutilização de endereços, o que é necessário para que todos os esquemas de Política de Privacidade propostos funcionem de qualquer maneira. É importante que tornemos o BIP70 o mais fácil e difundido possível.

A prevenção de mesclagem T interfere no rastreamento de moedas. Algumas pessoas podem desejar implementar sistemas CoinJoin somente por esse motivo.

No entanto, T consigo imaginar que isso se torne generalizado. Se a Política de Privacidade das pessoas estiver sendo protegida por outros meios, então o CoinJoin se torna um sistema de “ajudar ladrões a esconder seu dinheiro roubado”, o que reduz o incentivo para participar, aumenta ainda mais o risco legal e faria as pessoas se perguntarem por que seus aplicativos de carteira estavam pedindo que pagassem taxas simplesmente para proteger pessoas que elas provavelmente acham que são más.

Além disso, oIncidente no mercado de ovelhasmostra que o combate descentralizado ao crime como técnica às vezes é a única opção: ninguém vai pedir ajuda à polícia para recuperar o dinheiro roubado das drogas, e nenhum governo se daria ao trabalho de ajudar se o fizessem.

Este artigo foi publicado originalmente emMédio

Imagem do teclado de Política de Privacidadevia Shutterstock