Merge avoidance

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Ambox warning pn.svg
Este artigo foi proposto para eliminação semirrápida por um ou mais editores. A(s) justificativas apresentada(s) para eliminação foram:
  • Último editor: Hume42

Por favor, melhore o artigo se possível e procure enquadrá-lo dentro das regras do projeto.
Caso não haja oposição à eliminação desta página, ela será suprimida a partir de 24 de junho. Para mais informações, veja Política de eliminação e Eliminação semirrápida.


Encontre referências para o artigo: Google (notícias, livros e acadêmico)


Usuário: Se esta página possui arquivos de mídia que não são utilizáveis em outras páginas, adicione uma nota em WP:PER, para que um administrador lusófono do Wikimedia Commons verifique se ela se encontra no escopo do projeto.

Aviso ao criador: Os principais editores da página podem ser avisados (recomendável) e seu criador (se registrado) deve ser notificado com
{{subst:Aviso-ESR|1=Merge avoidance}} ~~~~
Aviso ao criador com nota de boas-vindas:
{{subst:Av-bv-ESR|1=Merge avoidance|2=~~~~}}

Merge avoidance (criptomoedas)[editar | editar código-fonte]

O merge avoidance[1] é um protocolo de pagamento de bitcoins proposto por Mike Hearn em 2013, ele é baseado na ideia de tentar evitar o gasto de outputs não relacionados na mesma transação de Bitcoin. [2]

Em transações do Bitcoin quando um receptor recebe satoshis[3], que corresponde a uma subunidade monetária do Bitcoin, no output daquela mesma transação, o pagador pode rastrear como o receptor gasta aqueles satoshis. O pagador não pode ver automaticamente outras transações concluídas por aquele receptor, contanto que o último use endereços únicos para cada transação. No entanto, se o receptor gasta satoshis advindos de dois pagadores diferentes na mesma transação, os pagadores conseguem enxergar as transações realizadas um do outro. Isso é chamado merge.Quanto mais um receptor realiza o merge de outputs das transações, mais fácil é para um agente malicioso rastrear a quantidade de satoshis que o receptor ganhou, gastou, e economizou, causando um vazamento dos dados privados do receptor. O método de merge avoidance prega a evasão destes merges como consequência da proteção dos dados dos usuários que realizam transações Bitcoin.[2]

Problemas de segurança e privacidade do Bitcoin[editar | editar código-fonte]

O vazamento de informações pessoais dos usuários é uma das principais preocupações sobre a politica de privacidade do Bitcoin. Existe uma certa facilidade de um adversário saber sobre as informações pessoais , o saldo da carteira digital, o histórico de transações e outras informações do usuário alvo[4].

Reúso de endereços[editar | editar código-fonte]

A maioria dos problemas de privacidade do Bitcoin são relacionados a um adversário descobrindo quais outputs pertencem a uma mesma carteira digital. Ao realizar essa descoberta, ele pode descobrir o saldo de uma carteira digital e todo o histórico de transações de uma pessoa-alvo, pois todo o histórico de transações do bitcoin é guardado em uma planilha pública chamada Blockchain. Isso pode ser ainda mais fácil por conta de sites como Blockchain.info que indexam outputs e transações ao endereço das carteiras digitais, permitindo que qualquer um olhe todas as transações referentes a aquele endereço. [5][6].

Casos de reúso de endereços[editar | editar código-fonte]

Problemas de carteira de usuários finais[editar | editar código-fonte]

O reuso de endereço é uma definição padrão na implementação do Bitcoin, isso causa uma grande quantidade de vazamento de informações privadas. Em carteiras digitais mais antigas (não HD[7]), o uso constante de endereços diferentes pode causar a invalidação de backups antigos da carteira digital, levando ao usuário a perder seu dinheiro. Também há um problema de reúso de endereços em smartphones mais simples, pode haver uma sobrecarga de memória nestes dispositivos se os endereços forem mudados constantemente, então o reúso de endereços é considerado um requisito essencial nesses tipos de dispositivos para o funcionamento de carteiras digitais.

Problemas nos servidores de carteiras digitais[editar | editar código-fonte]

Atualmente, não existem implementações em código aberto de carteiras digitais que escalam com carteiras com um grande número de endereços, os maiores processadores de pagamento tem que implementar uma grande quantidade de código customizado para compensar a falta de escalabilidade do Bitcoin Core. Isso implica nos receptores tendo que reusar os seus endereços chave.

Convenções sociais[editar | editar código-fonte]

Alguns usuários tem o hábito de publicar seus endereços estáticos em assinaturas de fóruns, páginas de doação, emails, QR codes, entre outros. Isso pode ser um grande problema que pode afetar a privacidade dos usuários, pois os endereços publicados nesses meios são estáticos, então qualquer indivíduo pode rastrear todas as transações que estão armazenadas na Blockchain.[8]

O troco de transações Bitcoin[editar | editar código-fonte]

Quando um output de uma transação Bitcoin é usado como input de outra transação, ele deve ser gasto por inteiro. Em alguns casos, se os valores das moedas são maiores do que o usuário deseja pagar, o cliente gera um novo endereço de Bitcoin e envia a diferença para esse endereço. Isso é conhecido como o troco das transações Bitcoin[9].

No Bitcoin não existem cédulas de dinheiro físicas, ao invés disso os elementos das transações são chamados de inputs e outputs. Quando um usuário gasta bitcoins ao fazer uma transação, deve-se usar o valor inteiro de um output não gasto e transformá-lo em um input de uma nova transação. As carteiras digitais de Bitcoin escondem esse processo pois ficam procurando por outputs não gastos e os somando para obter seu valor total. Então, quando alguém possui, por exemplo, 100 Bitcoins isso significa que a soma de todos os seus outputs não gastos é de 100 Bitcoins[9].

Furos de privacidade causados pelo troco das transações Bitcoin[editar | editar código-fonte]

O Bitcoin usa uma planilha pública para armazenar todas as transações dos usuários e qualquer usuário pode procurá-las por por seu endereço chave. Sabendo disso e de que o vazamento de dados de privacidade são na sua maioria das vezes causadas pelo reúso de endereços, um adversário pode aprender sobre o limite inferior da conta de um alvo ao observar a incompatibilidade entre o tamanho do seu pagamento e as suas moedas disponíveis (output). Se a incompatibilidade segue uma direção, o alvo que está realizando a transação possui um monte de pequenos outputs, fazer pagamentos para qualquer valor grande irá causar uma grande quantidade de dinheiro gasto em taxas, pois as transações geradas são de grande tamanho. Mas se a incompatibilidade segue a outra direção, e a pessoa que está fazendo a transação deseja pagar um pequeno valor com uma moeda grande, o troco irá vazar informações valiosas sobre quantos Bitcoins aquela pessoa possui[4].

Os problemas na abordagem do CoinJoin citados por Hearn[editar | editar código-fonte]

A abordagem do CoinJoin para resolver os problemas de privacidade do Bitcoin recebeu bastante atenção em suas primeiras implementações. Existe um debate sobre a abordagem do CoinJoin entre os usuários do Bitcoin, alguns a veem como uma ferramenta de privacidade que serve para os usuários protegerem seus dados, por outro lado, outros a enxergam como apenas uma ferramenta para evitar o rastreamento dos Bitcoins. A idéia principal do CoinJoin é que quando o usuário desejar fazer um pagamento, ele deve achar outro indivíduo que deseja realizar um pagamento e ambos devem fazer um pagamento conjunto. Na sua proposta do merge avoidance, Mike Hearn o compara com o CoinJoin[10] e sugere que este último possui vários problemas, como[8]:

  • Vulnerabilidade a ataques Sybyl/DoS aos serviços de mixing.
  • Imensamente complexo de se implementar corretamente.
  • É um serviço legalmente questionável.
  • Possui um tipo de centralização (um dos principais lemas do Bitcoin é descentralização).
  • Problemas de experiência do usuário.

Merge avoidance[editar | editar código-fonte]

Um dos principais temas discutidos sobre a privacidade do Bitcoin é o vazamento de dados causado pelo troco de transações Bitcoin, então o principal motivo do seu furo de privacidade é a incompatibilidade entre o tamanho das moedas disponíveis versus o que é necessário para realizar o pagamento. A abordagem do merge avoidance [11]sobre o problema é evitar a criação de qualquer vazamento de informação que necessite ser deletado depois. Uma estratégia de merge avoidance simples é sempre tentar pagar com o menor output disponível, o qual é maior que a quantidade que é necessária para realizar o pagamento. Por exemplo, se um usuário possui quatro outputs disponíveis de 100, 200, 500 e 900 satoshis[3], ele deve realizar um pagamento de 300 satoshis com o output de 500 satoshis para evitar o merge entre os outputs das transações. Dessa forma, contanto que ele tenha outputs maiores que os seus pagamentos, ele evitará o merge.[2] [12]

O exemplo do pagamento do funcionário[editar | editar código-fonte]

Um famoso exemplo para a explicação da eficiência do ''merge avoidance'' é o exemplo do pagamento de salários de funcionários de uma empresta, ele é descrito da seguinte maneira:

"Ana é uma funcionária que recebe seu salário em bitcoins. Ana possui uma performance excelente em seu trabalho e seu chefe reconhece isso pagando a ela um salário acima do normal. O seu colega de trabalho Bill suspeita que ele não recebe o mesmo salário de Ana e quer saber se isso é verdade e por isso ele tenta convencê-la a fazer um pagamento para ele no dia em que ambos recebem seus salários. Se Ana é paga usando o Bitcoin normal, então sua carteira digital irá provavelmente usar seu output de salário e o troco irá revelar a quantidade que ela recebe. Mesmo se ela já tivesse feito diversas transações, Bill pode visitar um site de rastreamento de transações e seguir a Blockchain até que ele ache um número que seja suspeito na data de seus pagamentos e conclua que este seja o salário de Ana.

A abordagem do CoinJoin possui problemas ao enfrentar essa situação. Ela iria colocar um input grande no mix e receberia um output grande. Ela poderia pedir vários outputs menores, mas o input continuaria sendo do tamanho e na data do seu salário. A não ser que várias pessoas que ganham a mesma quantidade de Ana compartilhem a mesma transação CoinJoin, o furo de privacidade não seria evitado.

O que Ana precisa é para não ter seus dados de pagamento vazados é evitar ter um input tão grande em primeiro lugar. Isso é chamado merge avoidance. Quando ela submete o pedido de recebimento de salário ao seu chefe, ele irá pedir (para prevenir o vazamento de dados) um bom mix de denominações, da mesma maneira de quando uma pessoa precisa comprar dinheiro estrangeiro de uma casa de câmbio. Também há a necessidade de especificar um endereço único para cada output no pedido. O protocolo de pagamento não especifica como uma carteira digital deve satisfazer esse pedido, mas ele possibilita que a carteira digital do pagador submeta múltiplas transações independentes para satisfazer os outputs desejados.

Um fator que deve ser levado em cosideração que o comportamento do pagamento depende de qual carteira digital o seu chefe está usando, uma carteira antiga que não suporta merge avoidance ou uma nova que suporta o protocolo:

  • Se o seu chefe usa uma carteira antiga que não suporta merge avoidance, ela irá gerar e submeter para Ana uma transação única e gigante que há diversos inputs e todos seus outputs requisitados. Isso irá parecer bastante com uma transação do CoinJoin, mas com apenas um participante. No entanto não é possível saber disso olhando apenas para a blockchain.
  • Se o seu chefe usar uma carteira mais nova que suporta o merge avoidance, então ela irá receber um diverso número de transações diferentes e menores, cada uma delas irá criar um ou dois outputs requisitados por ela, não há nada que os ligue. Por ela confiar em seu chefe em não realizar um duplo gasto, ela não pode espalhar o broadcast de uma maneira que nem o tempo deles os entreguem.

Se a seleção dos outputs for sábia, ela nunca irá entrar em uma situação que ela possua outputs estranhamente grandes ou pequenos para um pagamento particular. Bill irá simplesmente ver uma pequena transação que possui um output pequeno e não importa o quão longe ele tente rastrear a transação ele nunca irá achar uma transação que possa parecer um pagamento de salário".[8]

Prós do merge avoidance[editar | editar código-fonte]

  • Pode ser escrito incrementalmente, um algoritmo simples e não tão inteligente pode entretanto, aumentar a privacidade do usuário. Mais adiante, um algoritmo melhor pode ser desenvolvido e submetido, e isso não irá implicar em nenhum upgrade global. Isso é bom para o modelo de projetos de contribuição voluntária que o Bitcoin possui.
  • É muito simples e não possui elementos não independentes ou grandes máquinas de estado. Você não precisa de preocupar sobre um telefone móvel entrando em um túnel no momento errado, ou sobre rodar uma implementação ruim do software.
  • Não há centralização;
  • Não há riscos legais, pois você não está contando com nenhum tipo de serviços que já foram considerados maquinarias para lavagem de dinheiro.
  • É robusto. O método do CoinJoin pode aparentar funcionar na maioria dos casos, mas ainda há casos de furos de privacidade. O merge avoidance não possui esse tipo de problema.
  • O merge avoidance não interfere no rastreamento de transações[4].

Contras[editar | editar código-fonte]

  • O quão sua segurança é boa depende bastante em quão inteligentemente as pessoas que estão lhe pagando estão construindo as transações. Por esse motivo, sua privacidade depende de pessoas que não tem muito incentivo para tomar alguma atitude a respeito. Mas provavelmente, um software de carteira virtual comum irá fazer isso da maneira correta.
  • O número de transações é aumentado, no entanto o overhead não é tão grande quanto se pode pensar, uma transação é somente uma lista de inputs, outputs e um header de dois campos. Inputs e outputs não são realmente mudados por uma boa implementação do CoinJoin, e os headers podem ser facilmente comprimidos para economizar espaço. A diferença estaria na ordem de bytes do que na de kilobytes.
  • Ele depende do protocolo de pagamento. Mas muitas coisas do sistema de Bitcoin depende disso, e o pagamento de protocolo é critico para evitar o reúso de endereços, o que na verdade é necessário para qualquer esquema de melhora de privacidade funcione. [8]

Referências[editar | editar código-fonte]

  1. [1]Harrigan, Martin, and Christoph Fretter. "The Unreasonable Effectiveness of Address Clustering." arXiv preprint arXiv:1605.06369 (2016).
  2. a b c [2]Bitcoin developer guide - Merge avoidance
  3. a b [3] Satoshi(unit) - Bitcoin wiki
  4. a b c [4]Androulaki, Elli, et al. "Evaluating user privacy in bitcoin." International Conference on Financial Cryptography and Data Security. Springer Berlin Heidelberg, 2013.
  5. [5]Bitcoin developer guide - Key reuse
  6. [6]Barcelo, Jaume. "User Privacy in the Public Bitcoin Blockchain." URL: http://www. dtic. upf. edu/~ jbarcelo/papers/20140704_User_Privacy_in_the_Public_Bitcoin_Blockc hain/paper. pdf (Accessed 09/05/2016) (2014)
  7. [7]Deterministic wallet - Bitcoin wiki
  8. a b c d [8]Merge avoidance A note on privacy-enhancing techniques in the Bitcoin protocol
  9. a b [9] Bitcoin wiki - Change
  10. [10]CoinJoin - Bitcoin wiki
  11. [11]Wang, Weihong, and Peng Li. "IC card-based bitcoin payment design and implement." (2015).
  12. [12]Poelstra, Andrew, and Gregory Maxwell. "Toward Unlinkable Bitcoin Transactions."

Referências externas[editar | editar código-fonte]

Veja Também[editar | editar código-fonte]