name: Privacidade na Bitcoin goal: Compreender e dominar os princípios de proteção da privacidade ao utilizar a Bitcoin objectives:

• Definir os conceitos teóricos necessários para compreender as questões de privacidade
• Identificar e mitigar os riscos associados à perda de confidencialidade para os utilizadores de Bitcoin
• Utilizar métodos e ferramentas para proteger a sua privacidade na Bitcoin
• Compreender os métodos de análise da cadeia e desenvolver estratégias de defesa

Proteger a sua privacidade na Bitcoin

Num mundo em que a confidencialidade das transacções financeiras se está a tornar gradualmente um luxo, é essencial compreender e dominar os princípios de proteção da privacidade quando se utiliza Bitcoin. Este curso de formação dá-lhe todas as chaves, teóricas e práticas, para o conseguir de forma autónoma.

Atualmente, na Bitcoin, há empresas especializadas na análise da cadeia de blocos. A sua atividade principal consiste precisamente em intrometer-se na sua esfera privada, a fim de comprometer a confidencialidade das suas transacções. Na realidade, não existe um "direito à privacidade" no Bitcoin. Assim, cabe-lhe a si, o utilizador, fazer valer os seus direitos naturais e proteger a confidencialidade das suas transacções, porque ninguém o fará por si.

O curso foi concebido para ser abrangente e geral. Cada conceito técnico é abordado em pormenor e apoiado por diagramas explicativos. O objetivo é tornar o conhecimento acessível a todos. O BTC204 é, por isso, acessível a principiantes e a utilizadores intermédios. O curso também oferece um valor acrescentado para os bitcoiners mais experientes, uma vez que aprofundamos certos conceitos técnicos que são frequentemente mal compreendidos.

Junte-se a nós para transformar a sua utilização da Bitcoin e tornar-se um utilizador informado, capaz de compreender as questões relacionadas com a confidencialidade e a proteção da sua privacidade.

Introdução

Visão geral do curso

Bem-vindo ao curso BTC204!

Num mundo em que a confidencialidade das transacções financeiras se está a tornar gradualmente um luxo, é essencial compreender e dominar os princípios de proteção da privacidade quando se utiliza Bitcoin. Este curso de formação dá-lhe todas as chaves, teóricas e práticas, para o conseguir de forma autónoma.

Atualmente, na Bitcoin, há empresas especializadas na análise da cadeia de blocos. A sua atividade principal consiste precisamente em intrometer-se na sua esfera privada, a fim de comprometer a confidencialidade das suas transacções. Na realidade, não existe um "direito à privacidade" no Bitcoin. Assim, cabe-lhe a si, o utilizador, fazer valer os seus direitos naturais e proteger a confidencialidade das suas transacções, porque ninguém o fará por si.

O Bitcoin não se trata apenas de "Number Go Up" e de preservar o valor das poupanças. Com as suas caraterísticas únicas e a sua história, é, antes de mais, o instrumento da contra-economia. Graças a esta formidável invenção, pode dispor livremente do seu dinheiro, gastá-lo e acumulá-lo, sem que ninguém o possa impedir.

Bitcoin oferece uma fuga pacífica do jugo do Estado, permitindo-lhe desfrutar plenamente dos seus direitos naturais, que não podem ser desafiados por leis estabelecidas. Graças à invenção de Satoshi Nakamoto, tem o poder de impor o respeito pela sua propriedade privada e recuperar a liberdade de contratar.

No entanto, a Bitcoin não é anónima por defeito, o que pode representar um risco para os indivíduos envolvidos na contra-economia, particularmente em regiões sob um regime despótico. Mas este não é o único perigo. Uma vez que a bitcoin é um ativo valioso e incensurável, pode ser um alvo para os ladrões. Assim, proteger a sua privacidade torna-se também uma questão de segurança: pode ajudá-lo a evitar pirataria informática e agressões físicas.

Como veremos, embora o protocolo ofereça certas protecções de confidencialidade por si só, é crucial utilizar ferramentas adicionais para otimizar e defender essa confidencialidade.

Este curso de formação foi concebido para fornecer uma visão geral e abrangente das questões envolvidas na confidencialidade da Bitcoin. Cada conceito técnico é abordado em pormenor, apoiado por diagramas explicativos. O objetivo é tornar este conhecimento acessível a todos, mesmo aos principiantes e aos utilizadores intermédios. Para os utilizadores mais experientes de Bitcoin, também abordamos conceitos altamente técnicos e por vezes pouco conhecidos ao longo do curso, para aprofundar a compreensão de cada assunto.

O objetivo deste curso de formação não é torná-lo totalmente anónimo na sua utilização da Bitcoin, mas sim fornecer-lhe as ferramentas essenciais para saber como proteger a sua confidencialidade de acordo com os seus objectivos pessoais. Terá a liberdade de escolher entre os conceitos e ferramentas apresentados para desenvolver as suas próprias estratégias, adaptadas aos seus objectivos e necessidades específicas.

Secção 1: Definições e conceitos-chave

Para começar, vamos rever os princípios fundamentais que regem o funcionamento da Bitcoin, para depois podermos abordar com calma as noções relacionadas com a confidencialidade. É essencial dominar alguns conceitos básicos, tais como UTXO, receção de endereços e scripting, antes de poder compreender plenamente os conceitos que iremos abordar nas secções seguintes. Introduziremos também o modelo geral de confidencialidade da Bitcoin, tal como imaginado por Satoshi Nakamoto, o que nos permitirá compreender as apostas e os riscos associados.

Secção 2: Compreender e proteger-se contra a análise da cadeia

Na segunda secção, analisamos as técnicas utilizadas pelas empresas de análise de blockchain para rastrear a sua atividade no Bitcoin. Compreender estes métodos é crucial para reforçar a proteção da sua privacidade. O objetivo desta secção é examinar as estratégias dos atacantes para melhor compreender os riscos e preparar o terreno para as técnicas que estudaremos nas secções seguintes. Analisaremos padrões de transação, heurísticas internas e externas e interpretações prováveis desses padrões. Para além da teoria, aprenderemos a utilizar um explorador de blocos para análise de cadeias, através de exemplos práticos e exercícios.

Secção 3: Dominar as melhores práticas para proteger a sua privacidade

Na terceira secção do nosso curso de formação, vamos ao que interessa: a prática! O objetivo é dominar todas as melhores práticas essenciais que devem tornar-se reflexos naturais para qualquer utilizador de Bitcoin. Iremos abordar a utilização de endereços em branco, etiquetagem, consolidação, utilização de nós completos, bem como KYC e métodos de aquisição. O objetivo é fornecer-lhe uma visão geral abrangente das armadilhas a evitar, a fim de estabelecer uma base sólida na nossa busca para proteger a privacidade. Para algumas destas práticas, será orientado para um tutorial específico sobre a forma de as implementar.

Secção 4: Compreender as transacções coinjoin

Como é que podemos falar de privacidade na Bitcoin sem mencionar os coinjoins? Na secção 4, descobrirá tudo o que precisa de saber sobre este método de mistura. Aprenderá o que são coinjoins, a sua história e objectivos, bem como os diferentes tipos de coinjoins que existem. Finalmente, para os utilizadores mais experientes, veremos o que são os anonsets e a entropia e como calculá-los.

Secção 5: Compreender os desafios de outras técnicas avançadas de confidencialidade

Na quinta secção, vamos dar uma vista de olhos a todas as outras técnicas disponíveis para proteger a sua privacidade na Bitcoin, para além do coinjoin. Ao longo dos anos, os programadores têm demonstrado uma criatividade notável na conceção de ferramentas dedicadas à privacidade. Analisaremos todos estes métodos, como o payjoin, as transacções colaborativas, o Coin Swap e o Atomic Swap, detalhando o seu funcionamento, os seus objectivos e as suas fraquezas.

Também analisaremos a privacidade ao nível da rede de nós e da disseminação de transacções. Também discutiremos os vários protocolos que foram propostos ao longo dos anos para melhorar a privacidade do utilizador na Bitcoin, incluindo protocolos de endereço estático.

Pronto para explorar os meandros da privacidade no Bitcoin? Vamos lá!

Definições e conceitos-chave

O modelo UTXO da Bitcoin

A Bitcoin é, antes de mais, uma moeda, mas sabe realmente como as BTC são representadas no protocolo?

UTXOs sobre Bitcoin: o que são?

O protocolo Bitcoin baseia-se no modelo UTXO, que significa "Unspent Transaction Output" (saída de transação não gasta).

Este modelo difere profundamente dos sistemas bancários tradicionais, que se baseiam num mecanismo de contas e saldos para acompanhar os fluxos financeiros. De facto, no sistema bancário, os saldos individuais são mantidos em contas associadas a uma identidade. Por exemplo, quando compra uma baguete a um padeiro, o seu banco debita simplesmente o montante da compra na sua conta, reduzindo o seu saldo, enquanto a conta do padeiro é creditada com o mesmo montante, aumentando o seu saldo. Neste sistema, não existe qualquer noção de ligação entre o dinheiro que entra na sua conta e o dinheiro que sai dela, para além dos registos de transacções.

A Bitcoin funciona de forma diferente. O conceito de conta não existe e as unidades monetárias não são geridas através de saldos, mas sim através de UTXOs. Um UTXO representa uma quantidade específica de bitcoins que ainda não foi gasta, formando assim um "pedaço de bitcoin", que pode ser grande ou pequeno. Por exemplo, um UTXO pode valer 500 BTC ou simplesmente 700 SATS.

**> O satoshi, frequentemente abreviado para sat, é a unidade mais pequena da Bitcoin, comparável ao cêntimo nas moedas fiduciárias.

1 BTC = 100 000 000 SATS

Teoricamente, um UTXO pode representar qualquer valor em bitcoins, variando de um sat a um máximo teórico de cerca de 21 milhões de BTC. No entanto, é logicamente impossível possuir todos os 21 milhões de bitcoins, e existe um limiar económico inferior chamado "dust", abaixo do qual um UTXO é considerado economicamente não rentável para gastar.

**> O maior UTXO já criado no Bitcoin tinha um valor de 500.000 BTC. Foi criado pela plataforma MtGox durante uma operação de consolidação em novembro de 2011: 29a3efd3ef04f9153d47a990bd7b048a4b2d213daaa5fb8ed670fb85f13bdbcf

UTXOs e condições de despesa

Os UTXOs são os instrumentos de troca na Bitcoin. Cada transação resulta no consumo de UTXOs como inputs e na criação de novos UTXOs como outputs. Quando uma transação é concluída, os UTXOs utilizados como entradas são considerados "gastos", e novos UTXOs são gerados e atribuídos aos destinatários indicados nas saídas da transação. Assim, um UTXO representa simplesmente uma saída de transação não gasta e, por conseguinte, uma quantidade de bitcoins pertencentes a um utilizador num determinado momento.

Todos os UTXOs são protegidos por scripts que definem as condições em que podem ser gastos. Para consumir um UTXO, um utilizador deve demonstrar à rede que satisfaz as condições estipuladas pelo script que protege esse UTXO. Normalmente, os UTXOs são protegidos por uma chave pública (ou um endereço de receção que representa essa chave pública). Para gastar um UTXO associado a esta chave pública, o utilizador deve provar que possui a chave privada correspondente, fornecendo uma assinatura digital feita com esta chave. É por isso que dizemos que a sua carteira Bitcoin não contém realmente bitcoins, mas armazena as suas chaves privadas, que por sua vez lhe dão acesso aos seus UTXOs e, por extensão, aos bitcoins que representam.

Como não existe o conceito de conta no Bitcoin, o saldo de uma carteira é simplesmente a soma dos valores de todos os UTXOs que ela pode gastar. Por exemplo, se a sua carteira Bitcoin pode gastar os seguintes 4 UTXOs:

- 2 BTC
- 8 BTC
- 5 BTC
- 2 BTC

O saldo total da sua carteira seria de 17 BTC.

A estrutura das transacções Bitcoin

Entradas e saídas de transacções

Uma transação Bitcoin é uma operação registada na cadeia de blocos que transfere a propriedade de bitcoins de uma pessoa para outra. Mais precisamente, uma vez que estamos num modelo UTXO e não existem contas, a transação satisfaz as condições de despesa que garantiram um ou mais UTXOs, consome-os e, de forma equivalente, cria novos UTXOs com novas condições de despesa. Em suma, uma transação move bitcoins de um script satisfeito para um novo script concebido para os proteger.

Cada transação Bitcoin é, portanto, composta por uma ou mais entradas e uma ou mais saídas. Os inputs são UTXOs consumidos pela transação para gerar outputs. Os outputs são novos UTXOs que podem ser utilizados como inputs para futuras transacções.

**> Teoricamente, uma transação de bitcoin pode ter um número infinito de entradas e saídas. O único limite é o tamanho máximo do bloco.

Cada entrada numa transação Bitcoin refere-se a um UTXO anterior não gasto. Para utilizar uma UTXO como input, o seu detentor deve demonstrar que é o legítimo proprietário através da validação do script associado, ou seja, satisfazendo a condição de gasto imposta. De um modo geral, isto significa fornecer uma assinatura digital produzida com a chave privada correspondente à chave pública que inicialmente protegeu este UTXO. O guião consiste, portanto, em verificar se a assinatura corresponde à chave pública utilizada aquando da receção dos fundos.

Cada saída, por sua vez, especifica a quantidade de bitcoins a serem transferidos, bem como o destinatário. Este último é definido por um novo script, que normalmente bloqueia o UTXO recém-criado com um endereço de receção ou uma nova chave pública.

Para que uma transação seja considerada válida de acordo com as regras de consenso, o total de outputs deve ser inferior ou igual ao total de inputs. Por outras palavras, a soma dos novos UTXOs gerados pela transação não deve exceder a soma dos UTXOs consumidos como entradas. Este princípio é lógico: se tiver apenas 500.000 SATS, não pode efetuar uma compra de 700.000 SATS.

Troca e fusão numa transação Bitcoin

A ação de uma transação Bitcoin sobre o UTXO pode assim ser comparada à fundição de uma moeda de ouro. De facto, um UTXO não é divisível, mas apenas fusível. Isto significa que um utilizador não pode simplesmente dividir um UTXO que representa um determinado montante em bitcoins em vários UTXOs mais pequenos. Ele deve consumi-lo inteiramente numa transação para criar um ou mais novos UTXOs de valores arbitrários em outputs, que devem ser menores ou iguais ao valor inicial.

Este mecanismo é semelhante ao de uma moeda de ouro. Digamos que possui uma moeda de 2 onças e pretende efetuar um pagamento de 1 onça, partindo do princípio que o vendedor não lhe pode dar troco. Teria de derreter a sua moeda e fundir 2 novas moedas de 1 onça cada.

A Bitcoin funciona de forma semelhante. Imaginemos que Alice tem um UTXO de 10.000 SATS e deseja comprar uma baguete que custa 4.000 SATS. Alice fará uma transação com 1 UTXO de 10.000 SATS como entrada, que consumirá na totalidade, e 2 UTXOs de 4.000 SATS e 6.000 SATS como saída. O UTXO de 4.000 SATS será enviado ao padeiro como pagamento pela baguete, enquanto o UTXO de 6.000 SATS retornará à Alice na forma de troco. Esse UTXO, que retorna ao emissor original da transação, é conhecido como "troca" no jargão do Bitcoin.

Agora vamos imaginar que Alice não tem um único UTXO de 10.000 SATS, mas sim dois UTXOs de 3.000 SATS cada. Nessa situação, nenhum dos UTXOs individualmente é suficiente para ajustar os 4.000 SATS da varinha. Alice deve, portanto, usar simultaneamente as 2 UTXOs de 3.000 SATS como entradas para sua transação. Desta forma, a quantidade total de entradas atingirá os 6.000 SATS, permitindo-lhe satisfazer o pagamento de 4.000 SATS ao padeiro. Este método, em que vários UTXOs são agrupados como consumos de uma transação, é frequentemente designado por "fusão".

Taxas de transação

Intuitivamente, poder-se-ia pensar que os custos de transação também representam o resultado de uma transação. Mas, na realidade, não é esse o caso. Os custos de transação representam a diferença entre o total dos inputs e o total dos outputs. Isto significa que, depois de utilizar parte do valor dos inputs para cobrir os outputs desejados numa transação, uma certa soma dos inputs fica por utilizar. Esta soma residual constitui os custos de transação.

Frais = total inputs - total outputs

Vejamos o exemplo de Alice, que tem um UTXO de 10.000 SATS e quer comprar uma baguete a 4.000 SATS. Alice cria uma transação com o seu UTXO de 10.000 SATS como entrada. Em seguida, ela gera uma saída de 4.000 SATS para o padeiro pagar pela baguete. Para encorajar os mineiros a integrar a sua transação num bloco, Alice atribui 200 SATS em taxas. Ela cria então um segundo output, a troca, que lhe será devolvida, no valor de 5.800 SATS.

Aplicando a fórmula da taxa, verifica-se que restam efetivamente 200 SATS para os menores:

Frais = total inputs - total outputs
Frais = 10 000 - (4 000 + 5 800)
Frais = 10 000 - 9 800
Frais = 200

Quando um mineiro consegue validar um bloco, está autorizado a cobrar estas taxas por todas as transacções incluídas no seu bloco, através da chamada transação "coinbase".

Criar UTXOs em Bitcoin

Se seguiu atentamente os parágrafos anteriores, sabe que os UTXOs só podem ser criados consumindo outros UTXOs existentes. Desta forma, as moedas Bitcoin formam uma cadeia contínua. No entanto, pode estar a perguntar-se como surgiram os primeiros UTXOs nesta cadeia. Isto levanta um problema semelhante ao da galinha e do ovo: de onde vieram estes UTXOs originais?

A resposta está na transação coinbase.

A coinbase é um tipo específico de transação Bitcoin, que é única para cada bloco e é sempre a primeira de todas. Permite ao mineiro que encontrou uma prova de trabalho válida receber a sua recompensa de bloco. Esta recompensa é composta por dois elementos: concessão do bloco e taxa de transação, discutidos na secção anterior.

A transação coinbase é única na medida em que é a única capaz de criar bitcoins ex nihilo, sem a necessidade de consumir inputs para gerar outputs. Estes bitcoins recém-criados são aquilo a que podemos chamar "UTXOs originais".

Os bitcoins subsidiados por blocos são novos BTC criados de raiz, de acordo com um calendário de emissão pré-estabelecido nas regras de consenso. O subsídio por bloco é reduzido para metade a cada 210.000 blocos, ou seja, aproximadamente a cada quatro anos, num processo conhecido como "halving". Originalmente, eram criados 50 bitcoins com cada subsídio, mas este montante tem vindo a diminuir gradualmente; atualmente, é de 3,125 bitcoins por bloco.

Quanto às taxas de transação, embora também representem BTC recém-criadas, não devem exceder a diferença entre o total de entradas e saídas de todas as transacções num bloco. Vimos anteriormente que estas taxas representam a parte dos inputs que não é utilizada nos outputs da transação. Esta porção é tecnicamente "perdida" durante a transação e o mineiro tem o direito de recriar este valor sob a forma de um ou mais novos UTXOs. Trata-se de uma transferência de valor entre o emissor da transação e o mineiro que a adiciona à cadeia de blocos.

**> Os bitcoins gerados por uma transação coinbase estão sujeitos a um período de maturidade de 100 blocos, durante o qual não podem ser gastos pelo mineiro. Esta regra foi concebida para evitar complicações relacionadas com a utilização de bitcoins recém-criados numa cadeia que poderia mais tarde tornar-se obsoleta.

As implicações do modelo UTXO

Em primeiro lugar, o modelo UTXO influencia diretamente as taxas de transação do Bitcoin. Uma vez que a capacidade de cada bloco é limitada, os mineiros favorecem as transacções que oferecem as melhores taxas em relação ao espaço que irão ocupar no bloco. De facto, quanto mais UTXOs uma transação incluir nas suas entradas e saídas, mais pesada é e, portanto, exige taxas mais elevadas. Esta é uma das razões pelas quais tentamos frequentemente reduzir o número de UTXOs na nossa carteira, o que também pode afetar a confidencialidade, um assunto que abordaremos em pormenor na terceira parte deste curso.

Em segundo lugar, como mencionado nas secções anteriores, as moedas Bitcoin são essencialmente uma cadeia de UTXOs. Cada transação cria assim uma ligação entre um UTXO passado e um UTXO futuro. Os UTXOs permitem assim seguir explicitamente o percurso das Bitcoins desde a sua criação até à sua utilização atual. Esta transparência pode ser considerada positiva, uma vez que permite a cada utilizador verificar a autenticidade dos bitcoins recebidos. No entanto, é também neste princípio de rastreabilidade e auditabilidade que se baseia a análise da cadeia de blocos, uma prática destinada a comprometer a sua confidencialidade. Esta prática será analisada em pormenor na segunda parte do curso.

O modelo de privacidade da Bitcoin

Dinheiro: autenticidade, integridade e despesas duplas

Uma das funções da moeda é resolver o problema da dupla coincidência de necessidades. Num sistema baseado na troca direta, a conclusão de uma troca exige não só encontrar um indivíduo que esteja a dar um bem correspondente à minha necessidade, mas também fornecer-lhe um bem de valor equivalente que satisfaça a sua própria necessidade. Encontrar este equilíbrio é uma questão complexa.

É por isso que utilizamos o dinheiro para movimentar o valor no espaço e no tempo.

Para que a moeda resolva este problema, é essencial que a parte que fornece um bem ou serviço esteja convencida da sua capacidade de gastar essa soma numa data posterior. Assim, qualquer indivíduo racional que deseje aceitar uma moeda, seja ela digital ou física, assegurar-se-á de que esta satisfaz dois critérios fundamentais:

• A peça deve ter integridade e autenticidade ;**
• e não deve ser gasto duas vezes

Se estiver a utilizar moeda física, é a primeira caraterística que é mais complexa de afirmar. Em diferentes períodos da história, a integridade das moedas metálicas foi frequentemente afetada por práticas como o corte ou a perfuração. Na Roma antiga, por exemplo, era prática comum os cidadãos rasparem os bordos das moedas de ouro para recolherem um pouco do metal precioso, guardando-as para transacções futuras. O valor intrínseco da moeda era assim reduzido, mas o seu valor facial permanecia o mesmo. Esta é uma das razões pelas quais o bordo da moeda foi posteriormente canelado.

A autenticidade é também uma caraterística difícil de verificar num suporte monetário físico. As técnicas actuais de combate à contrafação de moeda são cada vez mais complexas, obrigando os retalhistas a investir em sistemas de verificação dispendiosos.

Por outro lado, devido à sua natureza, a dupla utilização não constitui um problema para as moedas físicas. Se eu lhe der uma nota de 10 euros, ela sai irrevogavelmente da minha posse e passa para a sua, o que exclui, naturalmente, qualquer possibilidade de gasto múltiplo das unidades monetárias que incorpora. Em suma, não poderei voltar a gastar esta nota de 10 euros.

No caso da moeda digital, a dificuldade é diferente. Garantir a autenticidade e a integridade de uma moeda é muitas vezes mais simples. Como vimos na secção anterior, o modelo UTXO da Bitcoin permite rastrear uma moeda até à sua origem e, assim, verificar se foi efetivamente criada por um mineiro em conformidade com as regras de consenso.

Por outro lado, garantir que não haja gastos duplos é mais complexo, uma vez que todos os bens digitais são, na sua essência, informação. Ao contrário dos bens físicos, a informação não se divide quando é trocada, mas propaga-se por multiplicação. Por exemplo, se eu lhe enviar um documento por correio eletrónico, este será duplicado. Não pode ter a certeza de que eu apaguei o documento original.

Evitar a duplicação de despesas com Bitcoin

A única forma de evitar esta duplicação de um ativo digital é ter conhecimento de todas as trocas no sistema. Desta forma, podemos saber quem possui o quê e atualizar as participações de cada um em função das transacções efectuadas. É o que acontece, por exemplo, com a moeda escritural no sistema bancário. Quando se paga 10 euros a um comerciante com cartão de crédito, o banco regista a troca e actualiza o livro de contas.

Na Bitcoin, o gasto duplo é evitado da mesma forma. Procuramos confirmar a ausência de uma transação que já tenha gasto as moedas em questão. Se as moedas nunca foram usadas, então podemos ter a certeza de que não ocorrerá um gasto duplo. Este princípio foi descrito por Satoshi Nakamoto no Livro Branco com a famosa frase:

**A única forma de confirmar a ausência de uma transação é ter conhecimento de todas as transacções

Mas, ao contrário do modelo bancário, não queremos ter de confiar numa entidade central na Bitcoin. Assim, todos os utilizadores precisam de poder confirmar esta ausência de gastos duplos, sem depender de terceiros. Portanto, todos precisam estar cientes de todas as transações de Bitcoin. É por isso que as transacções Bitcoin são transmitidas publicamente em todos os nós da rede e registadas em texto claro na blockchain.

É precisamente esta divulgação pública da informação que complica a proteção da privacidade na Bitcoin. No sistema bancário tradicional, em teoria, apenas a instituição financeira tem conhecimento das transacções efectuadas. Com o Bitcoin, por outro lado, todos os utilizadores são informados de todas as transacções, através dos seus respectivos nós.

O modelo de confidencialidade: sistema bancário vs. Bitcoin

No sistema tradicional, a conta bancária está ligada à identidade do cliente. O banqueiro pode saber que conta bancária pertence a que cliente e que transacções lhe estão associadas. No entanto, este fluxo de informação é cortado entre o banco e o domínio público. Por outras palavras, é impossível conhecer o saldo e as transacções de uma conta bancária pertencente a outro indivíduo. Apenas o banco tem acesso a esta informação.

Por exemplo, o seu banqueiro sabe que compra a sua baguete todas as manhãs ao padeiro local, mas o seu vizinho não tem conhecimento desta transação. Desta forma, o fluxo de informação é acessível às partes envolvidas, nomeadamente ao banco, mas permanece inacessível a terceiros.

Devido ao constrangimento da divulgação pública das transacções que vimos na secção anterior, o modelo de confidencialidade da Bitcoin não pode seguir o modelo do sistema bancário. No caso da Bitcoin, uma vez que o fluxo de informação não pode ser quebrado entre as transacções e o domínio público, o modelo de privacidade assenta na separação entre a identidade do utilizador e as próprias transacções.

Por exemplo, se comprar uma baguete ao padeiro, pagando em BTC, o seu vizinho, que tem o seu próprio nó completo, pode ver a sua transação passar, tal como pode ver todas as outras transacções no sistema. No entanto, se os princípios de confidencialidade forem respeitados, ele não deve poder associar esta transação específica à sua identidade.

Mas como as transacções de Bitcoin são públicas, é possível estabelecer ligações entre elas para deduzir informações sobre as partes envolvidas. Esta atividade constitui mesmo uma especialidade de pleno direito, conhecida como "análise de blockchain". Na próxima parte do curso, convido-o a explorar os fundamentos da análise de blockchain, para que possa compreender como os seus bitcoins são rastreados e defender-se melhor contra eles.

Compreender e proteger-se contra a análise da cadeia

O que é a análise da cadeia Bitcoin?

Definição e funcionamento

A análise da cadeia de blocos é a prática de rastrear o fluxo de bitcoins na cadeia de blocos. De um modo geral, a análise da cadeia baseia-se na observação de caraterísticas em amostras de transacções anteriores. Em seguida, consiste em identificar essas mesmas caraterísticas numa transação que se pretende analisar e deduzir interpretações plausíveis a partir delas. Este método de resolução de problemas, baseado numa abordagem prática para encontrar uma solução suficientemente boa, é conhecido como "heurística".

Em termos leigos, há três fases principais na análise da cadeia:

1. Observar a cadeia de blocos ;

2. A identificação de elementos conhecidos ;

3. **A dedução de pressupostos

A análise da cadeia de blocos pode ser efectuada por qualquer pessoa. Basta ter acesso à informação pública da blockchain através de um nó completo para observar os movimentos das transacções e formular hipóteses. Existem também ferramentas gratuitas que facilitam esta análise, como o OXT.me, que exploraremos em pormenor nos dois últimos capítulos desta secção. No entanto, o principal risco para a confidencialidade vem de empresas especializadas em análise de cadeias de caracteres. Essas empresas levaram a análise de blockchain a uma escala industrial e vendem seus serviços para instituições financeiras e governos. Entre essas empresas, a Chainalysis é certamente a mais conhecida.

Objectivos da análise da cadeia

Um dos objectivos da análise da cadeia de blocos é agrupar várias actividades na Bitcoin, a fim de determinar a singularidade do utilizador que as realizou. Posteriormente, será possível tentar associar este conjunto de actividades a uma identidade real.

Voltemos ao capítulo anterior. Expliquei por que razão o modelo de privacidade da Bitcoin se baseava originalmente na separação entre a identidade do utilizador e as transacções. Por conseguinte, seria tentador pensar que a análise da cadeia de blocos é inútil, uma vez que, mesmo que consigamos agregar actividades na cadeia, não as podemos associar a uma identidade real.

Teoricamente, esta afirmação está correta. Na primeira parte deste curso, vimos que os pares de chaves criptográficas são utilizados para estabelecer condições no UTXO. Na sua essência, estes pares de chaves não divulgam qualquer informação sobre a identidade dos seus detentores. Assim, mesmo que consigamos agrupar as actividades associadas a diferentes pares de chaves, isso não nos diz nada sobre a entidade por detrás dessas actividades.

No entanto, a realidade prática é muito mais complexa. Há uma multiplicidade de comportamentos que podem ligar uma identidade real a uma atividade na cadeia. Em análise, isso é chamado de ponto de entrada, e há uma infinidade deles.

O mais comum é o KYC (Know Your Customer). Se retirar as suas Bitcoins de uma plataforma regulamentada para um dos seus endereços pessoais de receção, então algumas pessoas podem associar a sua identidade a esse endereço. De forma mais ampla, um ponto de entrada pode ser qualquer forma de interação entre sua vida real e uma transação de Bitcoin. Por exemplo, se publicar um endereço de receção nas suas redes sociais, este pode ser um ponto de entrada para análise. Se fizer um pagamento em Bitcoins ao seu padeiro, ele poderá associar o seu rosto (parte da sua identidade) a um endereço Bitcoin.

Esses pontos de entrada são praticamente inevitáveis quando se usa Bitcoin. Embora possamos tentar restringir o seu alcance, eles estarão sempre presentes. É por isso que é crucial combinar métodos destinados a preservar a sua privacidade. Embora manter uma separação entre a sua identidade real e as suas transacções seja uma abordagem interessante, continua a ser insuficiente hoje em dia. De facto, se todas as suas actividades onchain puderem ser agrupadas, então mesmo o mais pequeno ponto de entrada é suscetível de comprometer a camada única de confidencialidade que estabeleceu.

Defender-se da análise em cadeia

Por isso, também temos de ser capazes de lidar com a análise da cadeia de blocos na nossa utilização da Bitcoin. Ao fazê-lo, podemos minimizar a agregação das nossas actividades e limitar o impacto de um ponto de entrada na nossa privacidade.

Que melhor maneira de combater a análise de blockchain do que aprender sobre os métodos usados nela? Se queres saber como melhorar a tua privacidade na Bitcoin, tens de compreender estes métodos. Isto dar-lhe-á uma melhor compreensão de técnicas como coinjoin ou payjoin (técnicas que analisaremos nas partes finais do curso) e reduzirá os erros que poderá cometer.

https://planb.network/tutorials/privacy/on-chain/coinjoin-samourai-wallet-e566803d-ab3f-4d98-9136-5462009262ef

https://planb.network/tutorials/privacy/on-chain/payjoin-848b6a23-deb2-4c5f-a27e-93e2f842140f

Neste aspeto, podemos estabelecer uma analogia com a criptografia e a criptanálise. Um bom criptógrafo é, antes de mais, um bom criptanalista. Para conceber um novo algoritmo de encriptação, é necessário saber quais os ataques que irá enfrentar e também estudar porque é que os algoritmos anteriores foram quebrados. O mesmo princípio aplica-se à privacidade da Bitcoin. Compreender os métodos de análise de blockchain é a chave para se proteger contra eles. É por isso que incluí uma secção inteira sobre análise de cadeias neste curso de formação.

Métodos de análise em cadeia

É importante compreender que a análise de cordas não é uma ciência exacta. Baseia-se em heurísticas derivadas de observações anteriores ou de interpretações lógicas. Estas regras permitem-nos obter resultados bastante fiáveis, mas nunca com precisão absoluta. Por outras palavras, a análise de cadeias envolve sempre uma dimensão de probabilidade nas conclusões alcançadas. Por exemplo, pode ser possível estimar com vários graus de certeza que dois endereços pertencem à mesma entidade, mas a certeza total estará sempre fora de alcance.

O objetivo da análise em cadeia reside precisamente na agregação de várias heurísticas para minimizar o risco de erro. De certa forma, é uma acumulação de provas que nos aproxima da realidade.

Estas famosas heurísticas podem ser agrupadas em diferentes categorias, que descreveremos em pormenor mais adiante:

• Padrões de transação ;**
• Heurísticas internas à transação ;**
• Heurísticas externas à transação

Satoshi Nakamoto e análise da cadeia

As duas primeiras heurísticas de análise de cadeia foram descobertas pelo próprio Satoshi Nakamoto. Ele fala sobre elas na Parte 10 do Livro Branco do Bitcoin. Elas são :

• cIOH (Common Input Ownership Heuristic);
• e reutilização de endereços.

Fonte: S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf, 2009.

Veremos quais são nos próximos capítulos, mas é já interessante notar que estas duas heurísticas continuam a ter uma preeminência na análise da cadeia atualmente.

Padrões de transação

Um padrão de transação é simplesmente um modelo ou estrutura global de uma transação típica, que pode ser encontrado na cadeia de blocos e cuja interpretação provável é conhecida. Ao estudar padrões, concentramo-nos numa única transação e analisamo-la a um nível elevado.

Por outras palavras, vamos apenas analisar o número de UTXO nas entradas e o número de UTXO nas saídas, sem nos determos nos detalhes mais específicos ou no ambiente da transação. Com base no padrão observado, podemos interpretar a natureza da transação. Em seguida, procuramos as caraterísticas da sua estrutura e deduzimos uma interpretação.

Nesta secção, analisaremos em conjunto os principais modelos de transação encontrados na análise da cadeia e, para cada modelo, darei a interpretação provável desta estrutura, bem como um exemplo concreto.

Expedição única (ou pagamento único)

Vamos começar com um padrão muito comum, uma vez que é o que surge na maioria dos pagamentos em bitcoin. O modelo de pagamento simples caracteriza-se pelo consumo de um ou mais UTXOs como inputs e a produção de 2 UTXOs como outputs. Este modelo tem, portanto, o seguinte aspeto:

Quando detectamos esta estrutura de transação na cadeia de blocos, já podemos fazer uma interpretação. Como o seu nome indica, este modelo indica que estamos na presença de uma transação de envio ou de pagamento. O utilizador consumiu o seu próprio UTXO nos inputs para satisfazer nos outputs um UTXO de pagamento e um UTXO de troca (dinheiro devolvido ao mesmo utilizador).

Sabemos, portanto, que o utilizador observado já não está provavelmente na posse de um dos dois UTXOs de saída (o UTXO de pagamento), mas ainda está na posse do outro UTXO (o UTXO de troca).

De momento, não podemos especificar que saída representa que UTXO, uma vez que não é esse o objetivo do estudo de padrões. Chegaremos lá apoiando-nos nas heurísticas que estudaremos nas secções seguintes. Nesta fase, o nosso objetivo limita-se a identificar a natureza da transação em questão, que neste caso é um simples envio.

Por exemplo, aqui está uma transação Bitcoin que adopta o padrão de envio simples:

b6cc79f45fd2d7669ff94db5cb14c45f1f879ea0ba4c6e3d16ad53a18c34b769

Source : Mempool.space

Após este primeiro exemplo, deverá ter uma melhor compreensão do que significa estudar um "modelo de transação". Examinamos uma transação centrando-nos apenas na sua estrutura, sem ter em conta o seu ambiente ou os detalhes específicos da transação. Neste primeiro passo, estamos apenas a olhar para o quadro geral.

Agora que já sabe o que é um padrão, vamos passar para os outros modelos existentes.

Varrer

Este segundo modelo é caracterizado pelo consumo de um único UTXO como entrada e a produção de um único UTXO como saída.

A interpretação deste modelo é que estamos na presença de uma auto-transferência. O utilizador transferiu os seus bitcoins para si próprio, para outro endereço que lhe pertence. Uma vez que não há troca na transação, é altamente improvável que estejamos na presença de um pagamento. Com efeito, quando um pagamento é efectuado, é quase impossível que o pagador disponha de um UTXO correspondente exatamente ao montante exigido pelo vendedor, acrescido da taxa de transação. Em geral, o pagador é, portanto, obrigado a produzir um resultado de troca.

Sabemos então que o utilizador observado provavelmente ainda está na posse deste UTXO. No contexto de uma análise em cadeia, se soubermos que o UTXO utilizado como entrada na transação pertence a Alice, podemos assumir que o UTXO utilizado como saída também lhe pertence. O que se tornará interessante mais tarde é encontrar heurísticas internas à transação que possam reforçar este pressuposto (veremos estas heurísticas no capítulo 3.3).

Por exemplo, aqui está uma transação Bitcoin que adopta o padrão de varrimento:

35f1072a0fda5ae106efb4fda871ab40e1f8023c6c47f396441ad4b995ea693d

Source : Mempool.space

Mas atenção, este tipo de padrão também pode revelar uma auto-transferência para a conta de uma plataforma de câmbio de criptomoedas. Será o estudo dos endereços conhecidos e do contexto da transação que nos dirá se se trata de um swipe para uma carteira de autocustódia ou de um levantamento para uma plataforma. De facto, os endereços das plataformas de câmbio são muitas vezes facilmente identificáveis.

Vejamos novamente o exemplo da Alice: se a verificação conduzir a um endereço conhecido de uma plataforma (como a Binance, por exemplo), isso pode significar que os bitcoins foram transferidos para fora da posse direta da Alice, provavelmente com a intenção de os vender ou armazenar nessa plataforma. Por outro lado, se o endereço de destino for desconhecido, é razoável assumir que se trata simplesmente de outra carteira ainda pertencente a Alice. Mas este tipo de estudo está mais na categoria de heurística do que de padrões.

Consolidação

Este modelo é caracterizado pelo consumo de vários UTXOs na entrada e pela produção de um único UTXO na saída.

A interpretação deste padrão é que estamos na presença de uma consolidação. Esta é uma prática comum entre os utilizadores de Bitcoin, destinada a fundir várias UTXOs em antecipação de um possível aumento das taxas de transação. Ao realizar esta operação durante um período em que as taxas são baixas, é possível poupar em taxas futuras. Falaremos mais sobre essa prática no capítulo 4.3.

Podemos deduzir que o utilizador por trás deste modelo de transação estava provavelmente na posse de todos os UTXOs na entrada e ainda está na posse do UTXO na saída. Portanto, trata-se provavelmente de uma auto-transferência.

Tal como a varredura, este tipo de padrão também pode revelar uma auto-transferência para a conta de uma plataforma de troca. Será o estudo dos endereços conhecidos e do contexto da transação que nos dirá se se trata de uma consolidação para uma carteira de autocustódia ou de uma retirada para uma plataforma.

Por exemplo, aqui está uma transação Bitcoin que adopta o padrão de consolidação:

77c16914211e237a9bd51a7ce0b1a7368631caed515fe51b081d220590589e94

Source : Mempool.space

Numa análise em cadeia, este modelo pode revelar uma grande quantidade de informação. Por exemplo, se soubermos que uma das entradas pertence à Alice, podemos assumir que todas as outras entradas e a saída desta transação também lhe pertencem. Este pressuposto tornaria possível voltar atrás na cadeia de transacções anteriores para descobrir e analisar outras transacções susceptíveis de estarem associadas à Alice.

Despesas agrupadas

Este modelo é caracterizado pelo consumo de alguns UTXOs como inputs (frequentemente apenas um) e pela produção de muitos UTXOs como outputs.

A interpretação deste modelo é que estamos na presença de despesas agrupadas. É uma prática que revela provavelmente uma atividade económica muito grande, como uma plataforma de intercâmbio. As despesas agrupadas permitem a estas entidades poupar custos ao combinarem as suas despesas numa única transação.

Podemos deduzir deste modelo que o UTXO de entrada provém de uma empresa com um elevado nível de atividade económica, e que os UTXOs de saída se dispersarão. Muitos pertencerão aos clientes da empresa que retiraram bitcoins da plataforma. Outros poderão ir para empresas parceiras. Por fim, haverá certamente uma ou mais trocas que regressarão à empresa emissora.

Por exemplo, aqui está uma transação Bitcoin que adopta o padrão de gastos agrupados (presumivelmente, é uma transação emitida pela plataforma Bybit):

8a7288758b6e5d550897beedd13c70bcbaba8709af01a7dbcc1f574b89176b43

Source : Mempool.space

Transacções específicas do protocolo

Entre os padrões de transação, podemos também identificar aqueles que revelam a utilização de um protocolo específico. Por exemplo, os coinjoins da Whirlpool (discutidos na parte 5) terão uma estrutura facilmente identificável que os diferencia de outras transacções mais convencionais.

A análise deste padrão sugere que é provável que estejamos na presença de uma transação de colaboração. Também é possível observar uma coinjoin. Se esta última hipótese se revelar correta, então o número de saídas pode fornecer-nos uma estimativa aproximada do número de participantes no coinjoin.

Por exemplo, aqui está uma transação Bitcoin que adopta o padrão de transação colaborativa coinjoin:

00601af905bede31086d9b1b79ee8399bd60c97e9c5bba197bdebeee028b9bea

Source : Mempool.space

Existem muitos outros protocolos com as suas próprias estruturas específicas. Por exemplo, existem transacções Wabisabi, transacções Stamps e transacções Runes.

Graças a estes padrões de transação, já podemos interpretar uma certa quantidade de informação sobre uma determinada transação. Mas a estrutura da transação não é a única fonte de informação para análise. Podemos também estudar os seus pormenores. Estes pormenores internos são aquilo a que gosto de chamar "heurísticas internas" e que analisaremos no próximo capítulo.

Heurística interna

Uma heurística interna é uma caraterística específica que identificamos na própria transação, sem necessidade de examinar o seu ambiente, e que nos permite fazer deduções. Ao contrário dos padrões, que se centram na estrutura global da transação a um nível elevado, as heurísticas internas baseiam-se no conjunto de dados extraíveis. Isto inclui:

• As quantidades dos vários UTXOs que entram e saem;
• Tudo o que tem a ver com scripts: endereços de receção, controlo de versões, tempos de bloqueio...

De um modo geral, este tipo de heurística permitir-nos-á identificar a troca numa transação específica. Ao fazê-lo, podemos então perpetuar o rastreio de uma entidade ao longo de várias transacções diferentes. Com efeito, se identificarmos um UTXO pertencente a um utilizador que pretendemos seguir, é crucial determinar, quando este efectua uma transação, qual o output que foi transferido para outro utilizador e qual o output que representa a troca, que assim permanece na sua posse.

Mais uma vez, permitam-me recordar-vos que estas heurísticas não são absolutamente exactas. Individualmente, apenas nos permitem identificar cenários prováveis. É a acumulação de várias heurísticas que ajuda a reduzir a incerteza, sem nunca a poder eliminar completamente.

Semelhanças internas

Esta heurística envolve o estudo das semelhanças entre os inputs e os outputs da mesma transação. Se a mesma caraterística for observada nos inputs e em apenas um dos outputs da transação, então é provável que este output constitua a troca.

A caraterística mais óbvia é a reutilização de um endereço de receção na mesma transação.

Esta heurística deixa pouca margem para dúvidas. A menos que a sua chave privada tenha sido pirateada, o mesmo endereço de receção revela necessariamente a atividade de um único utilizador. A interpretação resultante é que a troca de transacções é a saída com o mesmo endereço de entrada. Podemos então continuar a seguir o rasto do indivíduo a partir desta troca.

Por exemplo, eis uma transação em que esta heurística pode provavelmente ser aplicada:

54364146665bfc453a55eae4bfb8fdf7c721d02cb96aadc480c8b16bdeb8d6d0

Source : Mempool.space

Estas semelhanças entre entradas e saídas não se limitam à reutilização de endereços. Qualquer semelhança na utilização de scripts pode ser utilizada para aplicar uma heurística. Por exemplo, podemos por vezes observar o mesmo versionamento entre o input e um dos outputs da transação.

Neste diagrama, podemos ver que a entrada n.º 0 desbloqueia um script P2WPKH (SegWit V0 começando com bc1q). A saída n° 0 usa o mesmo tipo de script. A saída n° 1, por outro lado, usa um script P2TR (SegWit V1 começando com bc1p). A interpretação desta caraterística é que é provável que o endereço com o mesmo versionamento que a entrada seja o endereço de troca. Assim, pertencerá sempre ao mesmo utilizador.

Eis uma transação em que esta heurística pode provavelmente ser aplicada:

db07516288771ce5d0a06b275962ec4af1b74500739f168e5800cbcb0e9dd578

Source : Mempool.space

Neste último, podemos ver que a entrada n.º 0 e a saída n.º 1 utilizam scripts P2WPKH (SegWit V0), enquanto a saída n.º 0 utiliza um script P2PKH diferente (Legacy).

No início dos anos 2010, esta heurística baseada no versionamento de scripts era relativamente inútil devido aos limitados tipos de scripts disponíveis. No entanto, ao longo do tempo e com as sucessivas actualizações do Bitcoin, foi introduzida uma diversidade crescente de tipos de scripts. Esta heurística está, portanto, a tornar-se cada vez mais relevante, uma vez que, com uma maior variedade de tipos de scripts, os utilizadores se dividem em grupos mais pequenos, aumentando assim as hipóteses de aplicar esta heurística de reutilização de versões internas. Por este motivo, apenas numa perspetiva de confidencialidade, é aconselhável optar pelo tipo de script mais comum. Por exemplo, no momento em que escrevo estas linhas, os scripts Taproot (bc1p) são menos utilizados do que os scripts SegWit V0 (bc1q). Embora os primeiros ofereçam benefícios económicos e de confidencialidade em certos contextos específicos, para utilizações mais tradicionais de assinatura única, pode fazer sentido manter um padrão mais antigo por razões de confidencialidade, até que o novo padrão seja mais amplamente adotado.

Pagamentos por números redondos

Outra heurística interna que nos pode ajudar a identificar a troca é a heurística do número redondo. De um modo geral, perante um padrão de pagamento simples (1 input e 2 outputs), se um dos outputs gastar um montante redondo, então este representa o pagamento.

Por eliminação, se uma saída representa o pagamento, a outra representa a troca. Por conseguinte, pode ser interpretado como provável que o utilizador da entrada esteja sempre na posse da saída identificada como a troca.

Convém sublinhar que esta heurística nem sempre é aplicável, uma vez que a maioria dos pagamentos continua a ser efectuada em unidades de conta fiduciárias. Com efeito, quando um retalhista em França aceita bitcoin, não apresenta geralmente preços estáveis em sats. Em vez disso, optará por uma conversão entre o preço em euros e o montante em bitcoins a pagar. Por conseguinte, não deve haver números redondos no final da transação.

No entanto, um analista pode tentar efetuar esta conversão tendo em conta a taxa de câmbio em vigor quando a transação foi transmitida na rede. Vejamos o exemplo de uma transação com uma entrada de 97 552 sats e duas saídas, uma de 31 085 sats e outra de 64 152 sats. À primeira vista, esta transação não parece envolver montantes redondos. No entanto, aplicando a taxa de câmbio de 64,339 euros no momento da transação, obtemos uma conversão em euros como se segue:

• Um contributo de 62,76 euros;
• Uma produção de 20 euros;
• Uma produção de 41,27 euros.

Uma vez convertida em moeda fiduciária, esta transação pode ser utilizada para aplicar a heurística de pagamento por montante redondo. A saída de 20 euros foi provavelmente para um comerciante, ou pelo menos mudou de proprietário. Por dedução, é provável que o montante de 41,27 euros tenha permanecido na posse do utilizador original.

Se, um dia, a bitcoin se tornar a unidade de conta preferida nas nossas bolsas, esta heurística poderá tornar-se ainda mais útil para a análise.

Por exemplo, eis uma transação em que esta heurística pode provavelmente ser aplicada:

2bcb42fab7fba17ac1b176060e7d7d7730a7b807d470815f5034d52e96d2828a

Source : Mempool.space

A maior produção

Quando identificamos uma diferença suficientemente grande entre dois outputs de transação num modelo de pagamento simples, podemos estimar que o maior output será provavelmente o de divisas.

Esta heurística da maior produção é certamente a mais imprecisa de todas. Por si só, é bastante fraca. No entanto, esta caraterística pode ser combinada com outras heurísticas para reduzir a incerteza da nossa interpretação.

Por exemplo, se estivermos a analisar uma transação com um pagamento redondo e um pagamento maior, a aplicação conjunta da heurística do pagamento redondo e da heurística do pagamento maior reduz o nosso nível de incerteza.

Por exemplo, eis uma transação em que esta heurística pode provavelmente ser aplicada:

b79d8f8e4756d34bbb26c659ab88314c220834c7a8b781c047a3916b56d14dcf

Source : Mempool.space

Heurística externa

O estudo das heurísticas externas consiste em analisar as semelhanças, os padrões e as caraterísticas de certos elementos que não são específicos da própria transação. Por outras palavras, se antes nos limitávamos a explorar os elementos intrínsecos à transação com as heurísticas internas, agora alargamos o nosso campo de análise ao ambiente da transação, graças às heurísticas externas.

Reutilização de endereços

Esta é uma das heurísticas mais conhecidas dos bitcoiners. A reutilização de endereços permite estabelecer uma ligação entre diferentes transacções e diferentes UTXOs. Ocorre quando um endereço de receção de Bitcoin é utilizado várias vezes.

Assim, é possível explorar a reutilização de endereços dentro da mesma transação como uma heurística interna para identificar a troca (como vimos no capítulo anterior). Mas a reutilização de endereços também pode ser usada como uma heurística externa para reconhecer a singularidade de uma entidade por detrás de várias transacções.

A interpretação da reutilização de um endereço é que todos os UTXOs bloqueados nesse endereço pertencem (ou pertenceram) à mesma entidade. Esta heurística deixa pouca margem para a incerteza. Uma vez identificada, a interpretação resultante é suscetível de corresponder à realidade. Por conseguinte, permite o agrupamento de diferentes actividades na cadeia.

Como explicado na introdução da Parte 3, esta heurística foi descoberta pelo próprio Satoshi Nakamoto. No Livro Branco, ele menciona uma solução para ajudar os utilizadores a evitar a sua geração, que consiste simplesmente em utilizar um endereço em branco para cada nova transação:

"_Como firewall adicional, pode ser utilizado um novo par de chaves para cada transação para as manter desvinculadas de um proprietário comum."

Fonte: S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf, 2009.

Por exemplo, aqui está um endereço que é reutilizado em várias transacções:

bc1qqtmeu0eyvem9a85l3sghuhral8tk0ar7m4a0a0

Fonte : Mempool.space

Semelhança de escrita e marcas de carteira

Para além da reutilização de endereços, existem muitas outras heurísticas que permitem associar acções ao mesmo portefólio ou grupo de endereços.

Em primeiro lugar, um analista pode procurar semelhanças na utilização de scripts. Por exemplo, certos scripts minoritários, como o multisig, podem ser mais fáceis de detetar do que os scripts SegWit V0. Quanto maior for o grupo em que nos estamos a esconder, mais difícil é detetar-nos. Esta é uma das razões pelas quais, em bons protocolos Coinjoin, todos os participantes usam exatamente o mesmo tipo de script.

De uma forma mais geral, um analista pode também concentrar-se nas impressões digitais caraterísticas de uma carteira. Trata-se de processos específicos de utilização que podem ser identificados com o objetivo de os explorar como heurísticos de rastreio. Por outras palavras, se observarmos uma acumulação das mesmas caraterísticas internas nas transacções atribuídas à entidade identificada, podemos tentar identificar essas mesmas caraterísticas noutras transacções.

Por exemplo, poderemos identificar que o utilizador rastreado envia sistematicamente as suas alterações para endereços P2TR (bc1p...). Se este processo se repetir, podemos usá-lo como uma heurística para o resto da nossa análise. Também podemos utilizar outras impressões digitais, como a ordem dos UTXOs, o local da alteração nas saídas, a sinalização RBF (Replace-by-Fee), ou o número da versão, o campo nSequence e o campo nLockTime.

Como refere @LaurentMT em Space Kek #19 (um podcast em francês), a utilidade das impressões digitais das carteiras na análise da cadeia está a aumentar significativamente ao longo do tempo. De facto, o número crescente de tipos de scripts e a implementação cada vez mais progressiva destas novas funcionalidades pelos programas informáticos de carteiras acentuam as diferenças. Em alguns casos, é mesmo possível identificar o software exato utilizado pela entidade que está a ser seguida. Por conseguinte, é importante compreender que o estudo das pegadas das carteiras é particularmente relevante para as transacções recentes, e não para as iniciadas no princípio da década de 2010.

Em suma, uma pegada pode ser qualquer prática específica, realizada automaticamente pela carteira ou manualmente pelo utilizador, que podemos encontrar noutras transacções para nos ajudar na nossa análise.

A Heurística de Propriedade de Entrada Comum (CIOH)

A heurística da propriedade comum dos inputs (Common Input Ownership Heuristic - CIOH) é uma heurística que afirma que, quando uma transação tem vários inputs, é provável que todos eles provenham de uma única entidade. Consequentemente, a sua propriedade é comum.

Para aplicar o CIOH, começamos por observar uma transação com várias entradas. Podem ser 2 entradas ou 30 entradas. Uma vez identificada esta caraterística, verificamos se a transação se enquadra num modelo de transação conhecido. Por exemplo, se existirem 5 entradas com aproximadamente o mesmo montante e 5 saídas com exatamente o mesmo montante, saberemos que se trata da estrutura de uma coinjoin. Não poderemos aplicar o CIOH.

Por outro lado, se a transação não se enquadrar em nenhum modelo de transação colaborativa conhecido, então podemos interpretar que todas as entradas são provavelmente provenientes da mesma entidade. Isto pode ser muito útil para alargar um cluster já conhecido ou continuar um rastreio.

O CIOH foi descoberto por Satoshi Nakamoto. Ele fala sobre isso na parte 10 do Livro Branco:

"_[...] a ligação é inevitável com transacções de múltiplas entradas, que revelam necessariamente que as suas entradas foram detidas pelo mesmo proprietário. O risco é que, se o proprietário de uma chave for revelado, as ligações podem revelar outras transacções que pertenciam ao mesmo proprietário

É particularmente fascinante notar que Satoshi Nakamoto, mesmo antes do lançamento oficial do Bitcoin, já tinha identificado as duas principais vulnerabilidades de privacidade para os utilizadores, nomeadamente o CIOH e a reutilização de endereços. Esta previsão é bastante notável, uma vez que estas duas heurísticas continuam a ser, ainda hoje, as mais úteis na análise da cadeia de blocos.

Para dar um exemplo, eis uma transação à qual podemos provavelmente aplicar o CIOH:

20618e63b6eed056263fa52a2282c8897ab2ee71604c7faccfe748e1a202d712

Source : Mempool.space

Dados fora da cadeia

Naturalmente, a análise da cadeia não se limita exclusivamente aos dados da cadeia. Quaisquer dados de uma análise anterior ou disponíveis na Internet também podem ser utilizados para aperfeiçoar uma análise.

Por exemplo, se observarmos que as transacções rastreadas são sistematicamente difundidas a partir do mesmo nó Bitcoin, e conseguirmos identificar o seu endereço IP, podemos ser capazes de identificar outras transacções da mesma entidade, bem como determinar parte da identidade do emissor. Embora esta prática não seja facilmente realizável, uma vez que requer a operação de numerosos nós, pode ser empregue por algumas empresas especializadas na análise de blockchain.

O analista também tem a opção de se basear em análises previamente tornadas públicas, ou nas suas próprias análises anteriores. Talvez possamos encontrar um output que aponte para um conjunto de endereços que já identificámos. Por vezes, também é possível confiar em resultados que apontam para uma plataforma de troca, uma vez que os endereços destas empresas são geralmente conhecidos.

Da mesma forma, é possível efetuar uma análise por eliminação. Por exemplo, se ao analisar uma transação com duas saídas, uma delas estiver relacionada com um grupo de endereços já conhecido, mas distinto da entidade que estamos a rastrear, então podemos interpretar que a outra saída representa provavelmente a troca.

A análise do canal inclui também uma componente OSINT (Open Source Intelligence) um pouco mais geral, que envolve pesquisas na Internet. É por esta razão que desaconselhamos a publicação de endereços diretamente nas redes sociais ou num sítio Web, seja ele pseudónimo ou não.

Modelos temporais

Pensamos menos nisso, mas certos comportamentos humanos são reconhecíveis em cadeia. Talvez o mais útil numa análise seja o seu padrão de sono! Sim, quando você dorme, você não transmite transações Bitcoin. Mas geralmente dorme mais ou menos à mesma hora. É por isso que é prática comum usar a análise temporal na análise de blockchain. Muito simplesmente, este é um censo dos tempos em que as transacções de uma determinada entidade são transmitidas para a rede Bitcoin. Ao analisar esses padrões temporais, podemos deduzir uma grande quantidade de informações.

Em primeiro lugar, uma análise temporal pode, por vezes, identificar a natureza da entidade seguida. Se observarmos que as transacções são difundidas de forma consistente ao longo de 24 horas, isso denuncia um elevado nível de atividade económica. É provável que a entidade por detrás destas transacções seja uma empresa, potencialmente internacional e talvez com procedimentos internos automatizados.

Por exemplo, [reconheci este padrão há alguns meses] (https://twitter.com/Loic_Pandul/status/1701127409712452072) ao analisar [a transação que tinha atribuído erradamente 19 bitcoins em taxas] (https://mempool.space/tx/d5392d474b4c436e1c9d1f4ff4be5f5f9bb0eb2e26b61d2781751474b7e870fd). Uma simples análise temporal permitiu-me colocar a hipótese de que estávamos a lidar com um serviço automatizado e, portanto, provavelmente com uma grande entidade, como uma plataforma de câmbio.

De facto, alguns dias mais tarde, descobriu-se que os fundos pertenciam ao PayPal, através da plataforma de câmbio Paxos.

Pelo contrário, se virmos que o padrão temporal está bastante distribuído por 16 horas específicas, então podemos estimar que estamos perante um utilizador individual, ou talvez uma empresa local, dependendo dos volumes trocados.

Para além da natureza da entidade observada, o padrão temporal também nos pode dizer aproximadamente onde o utilizador está localizado, graças aos fusos horários. Desta forma, podemos fazer corresponder outras transacções e utilizar os seus carimbos temporais como uma heurística adicional que pode ser acrescentada à nossa análise.

Por exemplo, no endereço multiusos que mencionei anteriormente, podemos ver que as transacções, tanto de entrada como de saída, estão concentradas num intervalo de 13 horas.

bc1qqtmeu0eyvem9a85l3sghuhral8tk0ar7m4a0a0

Fonte : OXT.me

Este intervalo corresponde provavelmente à Europa, África ou Médio Oriente. Podemos, portanto, assumir que o utilizador por detrás destas transacções vive nestas áreas.

Por outro lado, uma análise temporal deste tipo também levou à hipótese de Satoshi Nakamoto não estar a operar a partir do Japão, mas dos EUA: The Time Zones of Satoshi Nakamoto

Pôr em prática com um explorador de blocos

Neste último capítulo, vamos pôr em prática os conceitos que estudámos até agora. Vou mostrar-lhe exemplos de transacções reais de Bitcoin, e terá de extrair a informação que lhe peço.

Idealmente, para efetuar estes exercícios, seria preferível a utilização de uma ferramenta profissional de análise de cadeias. No entanto, desde a detenção dos criadores da carteira Samourai, a única ferramenta de análise gratuita OXT.me deixou de estar disponível. Por isso, vamos optar por um explorador de blocos clássico para estes exercícios. Recomendo a utilização do Mempool.space pelas suas inúmeras funcionalidades e pela sua gama de ferramentas de análise de cadeias, mas também pode optar por outro explorador como o Bitcoin Explorer.

Para começar, vou apresentar-te os exercícios. Utilize o seu explorador de blocos para os realizar e escreva as suas respostas numa folha de papel. Depois, no final deste capítulo, apresento-lhe as respostas para que possa verificar e corrigir os seus resultados.

*As transacções selecionadas para estes exercícios foram escolhidas de forma aleatória, apenas pelas suas caraterísticas. Este capítulo destina-se apenas a fins educativos e informativos. Gostaria de deixar claro que não apoio nem encorajo a utilização destas ferramentas para fins maliciosos. O objetivo é ensiná-lo a proteger-se contra a análise de cadeias de caracteres e não a realizar análises para expor a informação privada de outras pessoas

Exercício 1

Identificador da transação a analisar :

3769d3b124e47ef4ffb5b52d11df64b0a3f0b82bb10fd6b98c0fd5111789bef7

Qual é o nome do modelo desta transação e que interpretações plausíveis podem ser extraídas examinando apenas o seu modelo, ou seja, a estrutura da transação?

Exercício 2

Identificador da transação a analisar :

baa228f6859ca63e6b8eea24ffad7e871713749d693ebd85343859173b8d5c20

Qual é o nome do modelo desta transação e que interpretações plausíveis podem ser extraídas examinando apenas o seu modelo, ou seja, a estrutura da transação?

Exercício 3

Identificador da transação a analisar :

3a9eb9ccc3517cc25d1860924c66109262a4b68f4ed2d847f079b084da0cd32b

Qual é o modelo para esta transação?

Depois de identificar o seu modelo, utilizando as heurísticas internas da transação, que resultado é provável que a troca represente?

Exercício 4

Identificador da transação a analisar :

35f0b31c05503ebfdf7311df47f68a048e992e5cf4c97ec34aa2833cc0122a12

Qual é o modelo para esta transação?

Depois de identificar o seu modelo, utilizando as heurísticas internas da transação, que resultado é provável que a troca represente?

Exercício 5

Imaginemos que Loïc publicou um dos seus endereços de receção de Bitcoin na rede social Twitter :

bc1qja0hycrv7g9ww00jcqanhfpqmzx7luqalum3vu

Com base nestas informações e utilizando apenas a heurística de reutilização de endereços, que transacções Bitcoin podem ser associadas à identidade de Loïc?

Obviamente, não sou o verdadeiro proprietário deste endereço de receção e não o publiquei nas redes sociais. Trata-se de um endereço que retirei aleatoriamente da cadeia de blocos

Exercício 6

Após o exercício 5, graças à heurística de reutilização de endereços, conseguiu identificar várias transacções Bitcoin em que o Loïc parece estar envolvido. Normalmente, entre as transacções identificadas, deveria ter detectado esta:

2d9575553c99578268ffba49a1b2adc3b85a29926728bd0280703a04d051eace

Esta transação é a primeira a enviar fundos para o endereço de Loïc. De onde acha que vieram os bitcoins recebidos por Loïc através desta transação?

Exercício 7

Após o exercício 5, graças à heurística de reutilização de endereços, conseguiu identificar várias transacções Bitcoin em que Loïc parece estar envolvido. Agora quer descobrir de onde Loïc veio. Com base nas transacções encontradas, efectue uma análise temporal para encontrar o fuso horário mais provavelmente utilizado por Loïc. A partir deste fuso horário, determine o local onde Loïc parece viver (país, estado/região, cidade...).

Exercício 8

Aqui está a transação Bitcoin para estudar:

bb346dae645d09d32ed6eca1391d2ee97c57e11b4c31ae4325bcffdec40afd4f

Olhando apenas para esta transação, que informações podemos interpretar?

Soluções de exercícios

Exercício 1:

O modelo para esta transação é o modelo de pagamento simples. Se estudarmos apenas a sua estrutura, podemos interpretar que uma saída representa a troca e a outra saída representa um pagamento efetivo. Sabemos, portanto, que o utilizador observado já não está, provavelmente, na posse de um dos dois UTXOs do output (o do pagamento), mas continua na posse do outro UTXO (o da troca).

Exercício 2:

O modelo para esta transação é o das despesas agrupadas. Este modelo revela provavelmente uma atividade económica em grande escala, como uma plataforma de troca. Podemos deduzir que o UTXO de entrada provém de uma empresa com um elevado nível de atividade económica e que os UTXOs de saída estarão dispersos. Alguns pertencerão a clientes da empresa que retiraram os seus bitcoins para carteiras de auto-custódia. Outros poderão ir para empresas parceiras. Por fim, haverá, sem dúvida, alguma troca que regressará à empresa emissora.

Exercício 3:

O modelo para esta transação é o pagamento simples. Podemos, portanto, aplicar heurísticas internas à transação para tentar identificar a troca.

Pessoalmente, identifiquei pelo menos duas heurísticas internas que apoiam a mesma hipótese:

• A reutilização do mesmo tipo de guião ;
• A maior produção.

A heurística mais óbvia é a de reutilizar o mesmo tipo de script. De facto, o output 0 é um P2SH, reconhecível pelo seu endereço de receção que começa por 3 :

3Lcdauq6eqCWwQ3UzgNb4cu9bs88sz3mKD

Enquanto que a saída 1 é um P2WPKH, identificável pelo seu endereço que começa por bc1q :

bc1qya6sw6sta0mfr698n9jpd3j3nrkltdtwvelywa

O UTXO utilizado como entrada para esta transação também utiliza um script P2WPKH:

bc1qyfuytw8pcvg5vx37kkgwjspg73rpt56l5mx89k

Assim, podemos assumir que a saída 0 corresponde a um pagamento e a saída 1 é a troca de transacções, o que significa que o utilizador de entrada possui sempre a saída 1.

Para apoiar ou refutar esta hipótese, podemos procurar outras heurísticas que confirmem o nosso pensamento ou diminuam a probabilidade de a nossa hipótese estar correta.

Identifiquei pelo menos uma outra heurística. É a maior heurística de saída. A saída 0 mede 123.689 sats, enquanto a saída 1 mede 505.839 sats. Existe, portanto, uma diferença significativa entre estes dois outputs. A heurística da maior produção sugere que a maior produção será provavelmente a de divisas. Esta heurística reforça ainda mais a nossa hipótese inicial.

Por conseguinte, parece provável que o utilizador que forneceu o UTXO como entrada ainda detenha a saída 1, que parece incorporar a troca da transação.

Exercício 4:

O modelo para esta transação é o pagamento simples. Podemos, portanto, aplicar heurísticas internas à transação para tentar identificar a troca.

Pessoalmente, identifiquei pelo menos duas heurísticas internas que apoiam a mesma hipótese:

• A reutilização do mesmo tipo de guião ;
• A saída do posto redondo.

A heurística mais óbvia é a de reutilizar o mesmo tipo de script. De facto, o output 0 é um P2SH, reconhecível pelo seu endereço de receção que começa por 3 :

3FSH5Mnq6S5FyQoKR9Yjakk3X4KCGxeaD4

Enquanto que a saída 1 é um P2WPKH, identificável pelo seu endereço que começa por bc1q :

bc1qvdywdcfsyavt4v8uxmmrdt6meu4vgeg439n7sg

O UTXO utilizado como entrada para esta transação também utiliza um script P2WPKH:

bc1qku3f2y294h3ks5eusv63dslcua2xnlzxx0k6kp

Assim, podemos assumir que a saída 0 corresponde a um pagamento e a saída 1 é a troca de transacções, o que significa que o utilizador de entrada possui sempre a saída 1.

Para apoiar ou refutar esta hipótese, podemos procurar outras heurísticas que confirmem o nosso pensamento ou diminuam a probabilidade de a nossa hipótese estar correta.

Identifiquei pelo menos uma outra heurística. É o valor arredondado da saída. A saída 0 mede 70.000 sats, enquanto a saída 1 mede 22.962 sats. Portanto, temos uma saída perfeitamente redonda na unidade de conta BTC. A heurística da saída redonda sugere que o UTXO com um montante redondo é muito provavelmente o de pagamento e que, por eliminação, o outro representa troca. Esta heurística reforça ainda mais a nossa hipótese inicial.

No entanto, neste exemplo, outra heurística poderia desafiar a nossa hipótese inicial. De facto, o output 0 é superior ao output 1. Com base na heurística de que o maior output é geralmente de divisas, poderíamos deduzir que o output 0 é de divisas. No entanto, esta contra-hipótese parece pouco plausível, uma vez que as outras duas heurísticas parecem substancialmente mais convincentes do que a heurística da maior produção. Por conseguinte, parece razoável manter a nossa hipótese inicial apesar desta aparente contradição.

Por conseguinte, parece provável que o utilizador que forneceu o UTXO como entrada ainda detenha a saída 1, que parece incorporar a troca da transação.

Exercício 5:

Podemos ver que 8 transacções podem ser associadas à identidade de Loïc. Destas, 4 envolvem a receção de bitcoins:

2d9575553c99578268ffba49a1b2adc3b85a29926728bd0280703a04d051eace
8b70bd322e6118b8a002dbdb731d16b59c4a729c2379af376ae230cf8cdde0dd
d5864ea93e7a8db9d3fb113651d2131567e284e868021e114a67c3f5fb616ac4
bc4dcf2200c88ac1f976b8c9018ce70f9007e949435841fc5681fd33308dd762

Os outros 4 dizem respeito a envios de bitcoin:

8b52fe3c2cf8bef60828399d1c776c0e9e99e7aaeeff721fff70f4b68145d540
c12499e9a865b9e920012e39b4b9867ea821e44c047d022ebb5c9113f2910ed6
a6dbebebca119af3d05c0196b76f80fdbf78f20368ebef1b7fd3476d0814517d
3aeb7ce02c35eaecccc0a97a771d92c3e65e86bedff42a8185edd12ce89d89cc

Exercício 6:

Se olharmos para o modelo desta transação, é evidente que se trata de uma despesa agregada. Com efeito, a transação tem um único input e 51 outputs, o que indica um elevado nível de atividade económica. Podemos, por conseguinte, colocar a hipótese de Loïc ter retirado bitcoins de uma plataforma de troca.

Vários factores reforçam esta hipótese. Em primeiro lugar, o tipo de script utilizado para proteger a entrada UTXO é um script multisig P2SH 2/3, o que indica um nível avançado de segurança típico das plataformas de troca:

OP_PUSHNUM_2
OP_PUSHBYTES_33 03eae02975918af86577e1d8a257773118fd6ceaf43f1a543a4a04a410e9af4a59
OP_PUSHBYTES_33 03ba37b6c04aaf7099edc389e22eeb5eae643ce0ab89ac5afa4fb934f575f24b4e
OP_PUSHBYTES_33 03d95ef2dc0749859929f3ed4aa5668c7a95baa47133d3abec25896411321d2d2d
OP_PUSHNUM_3
OP_CHECKMULTISIG

Além disso, o endereço estudado 3PUv9tQMSDCEPSMsYSopA5wDW86pwRFbNF é reutilizado em mais de 220.000 transacções diferentes, o que é frequentemente caraterístico das plataformas de troca, geralmente pouco preocupadas com a sua confidencialidade.

A heurística temporal aplicada a este endereço também mostra uma transmissão regular de transacções quase diariamente durante um período de 3 meses, com horários alargados durante 24 horas, sugerindo a atividade contínua de uma plataforma de troca.

Por último, os volumes tratados por esta entidade são colossais. O endereço recebeu e enviou 44 BTC em 222 262 transacções entre dezembro de 2022 e março de 2023. Estes grandes volumes confirmam ainda mais a natureza provável da atividade de uma plataforma de intercâmbio.

Exercício 7:

Ao analisar as horas de confirmação da transação, podem ser identificadas as seguintes horas UTC:

05:43
20:51
18:12
17:16
04:28
23:38
07:45
21:55

Uma análise destes horários mostra que o UTC-7 e o UTC-8 são consistentes com um intervalo de atividade humana atual (entre as 08:00 e as 23:00) para a maioria dos horários:

05:43 UTC > 22:43 UTC-7
20:51 UTC > 13:51 UTC-7
18:12 UTC > 11:12 UTC-7
17:16 UTC > 10:16 UTC-7
04:28 UTC > 21:28 UTC-7
23:38 UTC > 16:38 UTC-7
07:45 UTC > 00:45 UTC-7
21:55 UTC > 14:55 UTC-7
05:43 UTC > 21:43 UTC-8
20:51 UTC > 12:51 UTC-8
18:12 UTC > 10:12 UTC-8
17:16 UTC > 09:16 UTC-8
04:28 UTC > 20:28 UTC-8
23:38 UTC > 15:38 UTC-8
07:45 UTC > 23:45 UTC-8
21:55 UTC > 13:55 UTC-8

O fuso horário UTC-7 é particularmente relevante no verão, uma vez que inclui estados e regiões como :

• Califórnia (com cidades como Los Angeles, São Francisco e San Diego);
• Nevada (com Las Vegas) ;
• Oregon (com Portland) ;
• Washington (com Seattle) ;
• A região canadiana da Colúmbia Britânica (com cidades como Vancouver e Victoria).

Estas informações sugerem que Loïc reside provavelmente na costa oeste dos Estados Unidos ou no Canadá.

Exercício 8:

A análise desta transação revela 5 entradas e uma única saída, sugerindo consolidação. Aplicando a heurística CIOH, podemos assumir que todos os UTXOs de entrada são propriedade de uma única entidade, e que o UTXO de saída também pertence a esta entidade. Parece que o utilizador optou por agrupar vários UTXOs que possuía, para formar um único UTXO na saída, com o objetivo de consolidar as suas partes. Este movimento foi provavelmente motivado por um desejo de tirar partido dos baixos custos de transação da época, a fim de reduzir os custos futuros.

Para redigir esta parte 3 sobre a análise da cadeia, recorri aos seguintes recursos:

• A série de quatro artigos intitulada: [Understanding Bitcoin Privacy with OXT] (https://medium.com/oxt-research/understanding-bitcoin-privacy-with-oxt-part-1-4-8177a40a5923), produzida pela Samourai Wallet em 2021 ;*
• Os vários relatórios da [OXT Research] (https://medium.com/oxt-research), bem como a sua ferramenta gratuita de análise da cadeia de blocos (que deixou de estar disponível de momento na sequência da detenção dos fundadores da carteira Samourai) ;*
• Em termos mais gerais, o meu conhecimento provém de vários tweets e conteúdos de @LaurentMT e @ErgoBTC ;*
• O Space Kek #19 no qual participei na companhia de @louneskmt, @TheoPantamis, @Sosthene___ e @LaurentMT.*

Gostaria de agradecer aos seus autores, criadores e produtores. Obrigado também aos revisores que corrigiram meticulosamente o artigo em que se baseia esta parte 3 e me deram os seus conselhos de especialistas :

• Gilles Cadignan ;*
• Ludovic Lars

Dominar as melhores práticas para proteger a sua privacidade

Reutilização de endereços

Depois de termos estudado as técnicas que podem quebrar a sua confidencialidade no Bitcoin, nesta terceira parte vamos agora analisar as melhores práticas a adotar para se proteger. O objetivo desta parte não é explorar métodos para melhorar a confidencialidade, um assunto que será tratado mais tarde, mas sim compreender como interagir corretamente com a Bitcoin para manter a confidencialidade que ela naturalmente oferece, sem recorrer a técnicas adicionais.

Obviamente, para começar esta terceira parte, vamos falar da reutilização de endereços. Este fenómeno é a principal ameaça à confidencialidade do utilizador. Este capítulo é certamente o mais importante de todo o curso.

O que é um endereço de receção?

Um endereço de receção de Bitcoin é uma cadeia ou identificador utilizado para receber bitcoins numa carteira.

Tecnicamente, um endereço de receção de Bitcoin não "recebe" bitcoins no sentido literal, mas serve antes para definir as condições em que os bitcoins podem ser gastos. Em termos concretos, quando um pagamento é enviado para si, a transação do remetente cria um novo UTXO para si como um output dos UTXOs que consumiu como inputs. Nesta saída, afixa um script que define como este UTXO pode ser gasto numa data posterior. Este script é conhecido como "ScriptPubKey" ou "Locking Script". O seu endereço de receção, ou mais precisamente o seu payload, está integrado neste script. Em termos leigos, este script basicamente diz:

"Para gastar este novo UTXO, tem de fornecer uma assinatura digital utilizando a chave privada associada a este endereço de receção."

Os endereços de Bitcoin vêm em diferentes tipos, dependendo do modelo de script usado. Os primeiros modelos, conhecidos como "Legacy*", incluem os endereços P2PKH (Pay-to-PubKey-Hash) e P2SH (Pay-to-Script-Hash). Os endereços P2PKH começam sempre com 1 e os P2SH com 3. Embora ainda sejam seguros, estes formatos estão agora obsoletos, uma vez que implicam custos de transação mais elevados e oferecem menos confidencialidade do que as novas normas.

Os endereços SegWit V0 (P2WPKH e P2WSH) e Taproot / SegWit V1 (P2TR) representam formatos modernos. Os endereços SegWit começam com bc1q e os endereços Taproot, introduzidos em 2021, começam com bc1p.

Por exemplo, aqui está um endereço de receção Taproot:

bc1ps5gd2ys8kllz9alpmcwxqegn7kl3elrpnnlegwkm3xpq2h8da07spxwtf5

A forma como a ScriptPubKey é construída dependerá da norma que estiver a ser utilizada:

| ScriptPubKey | Modelo de script

| ---------------- | ----------------------------------------------------------- |

| P2PKH | OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG |

| P2SH | OP_HASH160 <scriptHash> OP_EQUAL |

| P2WPKH | 0 <pubKeyHash> |

| P2WSH | 0 <witnessScriptHash> |

| P2SH - P2WPKH | OP_HASH160 <redeemScriptHash> OP_EQUAL |

| P2SH - P2WSH | OP_HASH160 <redeemScriptHash> OP_EQUAL |

| P2TR | 1 <pubKey> |

A construção dos endereços de receção depende também do modelo de guião escolhido:

• Para os endereços P2PKH e P2WPKH, a carga útil, ou seja, o núcleo do endereço, representa o hash da chave pública;
• Para os endereços P2SH e P2WSH, o payload representa o hash de um arquivo ;
• Quanto aos endereços P2TR, o payload é uma chave pública modificada. As saídas P2TR combinam aspectos de Pay-to-PubKey e Pay-to-Script. A chave pública tweaked é o resultado da adição de uma chave pública de gasto clássica com um "tweak", derivada da raiz Merkle de um conjunto de scripts que também podem ser usados para gastar bitcoins.

Os endereços exibidos no software da sua carteira também incluem um HRP (Human-Readable Part), normalmente bc para endereços pós-SegWit, um separador 1 e um número de versão q para SegWit V0 e p para Taproot/SegWit V1. Um checksum também é adicionado para garantir a integridade e validade do endereço durante a transmissão.

Por fim, os endereços são colocados num formato normalizado:

• Base58check para endereços Legacy antigos ;
• Bech32 para endereços SegWit ;
• Bech32m para endereços Taproot.

Aqui está a matriz de adição para os formatos bech32 e bech32m (SegWit e Taproot) a partir da base 10:

| + | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |

| --- | --- | --- | --- | --- | --- | --- | --- | --- |

| 0 | q | p | z | r | y | 9 | x | 8 |

| 8 | g | f | 2 | t | v | d | w | 0 |

| 16 | s | 3 | j | n | 5 | 4 | k | h |

| 24 | c | e | 6 | m | u | a | 7 | l |

O que é a reutilização de endereços?

A reutilização de endereços é a utilização do mesmo endereço de receção para bloquear vários UTXOs diferentes.

Como vimos na secção anterior, cada UTXO tem a sua própria ScriptPubKey, que o bloqueia e que tem de ser satisfeita para que o UTXO possa ser consumido como entrada numa nova transação. É nesta ScriptPubKey que os endereços de carga útil são integrados.

Quando diferentes ScriptPubKeys contêm o mesmo endereço de receção, isto é chamado de reutilização de endereço. Na prática, isto significa que um utilizador forneceu repetidamente o mesmo endereço a remetentes para receber bitcoins através de vários pagamentos. E é precisamente esta prática que é desastrosa para a sua privacidade.

Porque é que a reutilização de endereços é um problema?

Uma vez que a blockchain é pública, é fácil ver que endereços bloqueiam que UTXO e quantos bitcoins. Se o mesmo endereço for utilizado para várias transacções, é possível deduzir que todos os bitcoins associados a esse endereço pertencem à mesma pessoa. Esta prática compromete a privacidade do utilizador ao permitir estabelecer ligações determinísticas entre diferentes transacções e rastrear bitcoins na blockchain. O próprio Satoshi Nakamoto já tinha salientado este problema no Livro Branco da Bitcoin:

Como firewall adicional, pode ser utilizado um novo par de chaves para cada transação, de modo a mantê-las desvinculadas de um proprietário comum

Fonte: S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf, 2009.

A intenção de Satoshi com esta frase era criar uma firewall adicional no caso de uma associação entre a identidade de um utilizador e um par de chaves no Bitcoin, para evitar que toda a sua atividade fosse publicamente associada à sua identidade. Atualmente, com a proliferação de empresas de análise de cadeias de blocos e a regulamentação KYC, a utilização de endereços únicos já não é uma "barreira adicional", mas sim uma prática indispensável para quem deseja preservar um mínimo de privacidade.

Quando reutiliza um endereço, estabelece uma ligação quase inegável entre todas as transacções associadas a esse endereço. Embora isto não ponha diretamente em causa os seus fundos, uma vez que a criptografia de curva elíptica garante a segurança das suas chaves privadas, facilita o controlo das suas actividades. De facto, qualquer pessoa com um nó pode observar as transacções e os saldos dos endereços, comprometendo totalmente o seu anonimato.

Para ilustrar este ponto, tomemos o exemplo do Bob, um utilizador que compra regularmente bitcoins em pequenas quantidades na DCA e os envia sempre para o mesmo endereço. Passados dois anos, este endereço contém uma quantidade substancial de bitcoins. Se Bob utilizar este endereço para efetuar um pagamento a um comerciante local, este último poderá ver todos os fundos associados e deduzir o património de Bob. Isto pode levar a riscos de segurança pessoal, como tentativas de roubo ou extorsão. Se o Bob tivesse usado um endereço em branco para receber cada compra periódica, teria revelado infinitamente menos informação ao seu comerciante.

Na análise de cadeias de caracteres, existem 2 tipos de reutilização de endereços:

• Reutilização externa ;
• Reutilização interna numa transação.

A primeira é quando um endereço é reutilizado em várias transacções Bitcoin diferentes. Foi disto que falámos anteriormente: esta heurística deduz que todos os UTXOs passados por este endereço pertencem a uma única entidade.

A reutilização de endereços internos não ocorre quando a reutilização ocorre em várias transacções, mas quando ocorre numa única transação. Com efeito, se o mesmo endereço utilizado para bloquear uma entrada for utilizado como saída de uma transação, podemos deduzir que esta saída continua a pertencer ao mesmo utilizador (bolsa) e que a segunda saída representa o pagamento efetivo. Esta outra heurística permite perpetuar um traço de fundos ao longo de várias transacções.

A reutilização de endereços é um verdadeiro flagelo para a Bitcoin. De acordo com o sítio Web OXT.me (atualmente inacessível), a taxa global de reutilização de endereços na Bitcoin era de cerca de 52% em 2022:

Esta taxa é enorme, mas provém na sua esmagadora maioria de plataformas de intercâmbio e não de utilizadores individuais.

Como evitar a reutilização de endereços?

Evitar a reutilização de endereços é bastante simples: Basta utilizar um endereço novo e em branco para todos os novos pagamentos na sua carteira.

Graças ao BIP32, as carteiras modernas são agora determinísticas e hierárquicas. Isto significa que um utilizador pode gerar um grande número de endereços a partir de uma única informação inicial: a semente. Ao guardar esta informação única, é possível restaurar todas as chaves privadas da carteira, permitindo o acesso aos fundos garantidos pelos endereços correspondentes.

É por isso que, quando prime o botão "receber" no software da sua carteira, é sempre sugerido um endereço de receção não utilizado. Depois de receber bitcoins nesse endereço, o software sugere automaticamente um novo.

PS: Recentemente, alguns programas de software de carteiras anunciaram a sua intenção de deixar de gerar endereços em branco, receando que tal seja entendido como uma forma de lavagem de dinheiro pelas autoridades. Se o seu software for um destes, aconselho-o vivamente a substituí-lo imediatamente, pois esta situação não é aceitável para o utilizador Se precisar de um identificador estático para receber pagamentos, como donativos, não é aconselhável utilizar um endereço Bitcoin clássico devido ao risco de reutilização. Em vez disso, use um endereço Lightning ou opte por um identificador de pagamento onchain estático, como BIP47 ou Silent Payments. Estes protocolos são explicados em pormenor na Parte 6 deste curso de formação.

Etiquetagem e controlo de peças

Tal como descobrimos na secção sobre análise de cadeias de caracteres, existe uma grande quantidade de heurísticas e padrões que podem ser utilizados para deduzir informações sobre uma transação. Como utilizador, é importante estar ciente destas técnicas para se proteger melhor contra elas.

Isto envolve uma gestão rigorosa da sua carteira em auto-custódia, o que significa conhecer a origem dos seus UTXOs, bem como selecionar cuidadosamente quais os UTXOs a consumir ao efetuar pagamentos. Esta gestão eficiente da carteira assenta em duas caraterísticas importantes das boas carteiras Bitcoin: etiquetagem e controlo de moedas.

Neste capítulo, vamos olhar para estas caraterísticas e ver como pode usá-las de forma inteligente, sem adicionar muita carga de trabalho, para otimizar a sua privacidade no Bitcoin.

O que é a rotulagem?

A etiquetagem é a prática de atribuir uma anotação ou etiqueta a um UTXO específico numa carteira Bitcoin. Estas anotações são armazenadas localmente pelo software da carteira e nunca são transmitidas através da rede Bitcoin. A etiquetagem é, portanto, uma ferramenta de gestão pessoal.

Por exemplo, se eu tiver um UTXO de uma compra P2P no Bisq com Charles, posso rotulá-lo como "Non-KYC Bisq Charles".

A marcação é uma boa prática que ajuda a lembrar a origem ou o destino pretendido de um UTXO, o que facilita a gestão de fundos e a otimização da privacidade. De facto, a sua carteira Bitcoin protege certamente vários UTXOs. Se as fontes destes UTXOs forem diferentes, pode não querer fundir estes UTXOs no futuro, caso contrário poderia revelar a sua propriedade comum. Ao etiquetar corretamente todas as suas peças, pode ter a certeza de que se lembrará da sua origem quando precisar de as utilizar, mesmo que isso seja daqui a anos.

O que é o controlo de canto?

A utilização ativa da etiquetagem torna-se ainda mais interessante quando associada a uma opção de controlo de moedas no seu software de carteira.

O controlo de moedas é uma caraterística encontrada num bom software de carteira Bitcoin, dando-lhe a capacidade de selecionar manualmente UTXOs específicos para utilizar como entradas para completar uma transação. De facto, para satisfazer um pagamento de saída, é necessário consumir um UTXO de entrada em troca. Por várias razões, que veremos mais tarde, pode querer escolher exatamente quais as partes a consumir como entradas para satisfazer um determinado pagamento. É exatamente isto que o controlo de moedas lhe permite fazer. Para fazer uma analogia, esta funcionalidade é semelhante a escolher uma moeda específica da sua carteira quando paga a sua baguete.

A utilização de software de carteira com controlo de moedas, juntamente com a etiquetagem UTXO, permite aos utilizadores distinguir e selecionar com precisão os UTXOs para as suas transacções.

Como é que rotula os seus UTXOs?

Não existe um método único de rotulagem de UTXOs. Cabe-lhe a si definir um sistema de etiquetagem que seja fácil de compreender para a sua carteira. Em qualquer caso, tenha em mente que uma boa rotulagem é uma rotulagem que você pode entender quando precisar dela. Se a sua carteira de Bitcoin se destina principalmente a poupanças, as etiquetas podem não ser úteis nas próximas décadas. Por isso, certifique-se de que são claras, precisas e completas.

É importante que os seus entes queridos possam identificar facilmente a origem dos fundos se, um dia, precisarem de aceder à sua carteira. Isto ajudá-los-á tanto por razões de confidencialidade como por razões legais, caso tenham de justificar a origem dos fundos perante uma autoridade.

O aspeto mais importante a registar na etiqueta é a origem da UTXO. Deve simplesmente indicar como é que a moeda chegou à sua carteira. É o resultado de uma compra numa plataforma de troca? Um pagamento de fatura de um cliente? Uma troca peer-to-peer? Ou representa a troca de uma despesa? Por exemplo, pode especificar:

• remover Exchange.com` ;
• pagamento do cliente David` ;
• comprar P2P Charles` ;
• Alterar a compra do sofá

Para afinar a sua gestão de UTXO e respeitar as suas estratégias de segregação de fundos dentro da sua carteira, pode enriquecer os seus rótulos com um indicador adicional que reflicta estas separações. Se a sua carteira contiver duas categorias de UTXO que não pretende misturar, pode incorporar um marcador nas suas etiquetas para distinguir claramente estes grupos. Estes marcadores de separação dependerão dos seus próprios critérios, tais como a distinção entre UTXOs resultantes de um processo de aquisição que envolva KYC, ou entre fundos profissionais e pessoais. Tomando os exemplos de etiquetas mencionados acima, isto poderia traduzir-se em:

• KYC - Withdrawal Exchange.com ;
• KYC - Pagamento do cliente David ;
• NO KYC - Comprar P2P Charles ;
• NO KYC - Mudança de compra de sofá

Também é aconselhável perpetuar a rotulagem de uma parte ao longo das transacções. Por exemplo, ao consolidar UTXO no-KYC, certifique-se de que marca o UTXO resultante não apenas como consolidação, mas especificamente como consolidação no-KYC para manter um registo claro da origem das moedas.

Por último, não é obrigatório colocar uma data numa etiqueta. A maioria dos softwares de carteira já exibe a data da transação e é sempre possível encontrar esta informação num explorador de blocos graças ao seu TXID.

Como escolher as peças certas?

Quando se efectua uma transação, o controlo de moedas permite-lhe escolher especificamente quais os UTXOs a consumir como entradas para satisfazer a saída de pagamento. Esta escolha tem dois aspectos:

• A possibilidade de o destinatário do pagamento associar parte da sua identidade aos UTXOs utilizados nas entradas;
• A capacidade de um observador externo estabelecer ligações entre todos os UTXOs consumidos como entradas.

Para ilustrar o primeiro ponto, vejamos um exemplo concreto. Suponhamos que compra uma baguete em bitcoins ao seu padeiro. Utiliza um ou mais UTXOs que detém como inputs para pagar, pelo menos, o preço da baguete em outputs, bem como as taxas de transação. O seu padeiro pode então associar o seu rosto, ou qualquer outra parte da sua identidade que ele conheça, às moedas utilizadas como entradas. Sabendo da existência desta ligação, pode preferir escolher um UTXO específico em vez de outro quando efectua o pagamento.

Por exemplo, se um dos seus UTXOs for proveniente de uma plataforma de troca e preferir que o padeiro não saiba da sua conta nessa plataforma, evitará utilizar esse UTXO para pagamento. Se tiver um UTXO de valor elevado que revele uma quantidade significativa de bitcoins, também pode optar por não o utilizar para evitar que o padeiro tome conhecimento da sua fortuna em BTC.

A escolha das UTXOs a utilizar para este primeiro ponto é, portanto, uma decisão pessoal, influenciada pelo que está disposto a revelar ou não. Os rótulos que atribui aos seus UTXOs quando os recebe ajudá-lo-ão a selecionar aqueles que, uma vez gastos, apenas expõem informação que se sente confortável em revelar ao destinatário.

Para além da informação potencialmente revelada ao destinatário, a escolha dos inputs também influencia o que revela a todos os observadores da blockchain. De facto, ao utilizar vários UTXOs como inputs para a sua transação, revela que são propriedade da mesma entidade, de acordo com a heurística CIOH (Common Input Ownership Heuristic).

Por conseguinte, ao selecionar as suas peças, tem de estar ciente de que a transação que está prestes a transmitir criará uma ligação entre todos os UTXOs utilizados. Esta ligação pode ser problemática para a sua privacidade pessoal, especialmente se os UTXOs forem provenientes de fontes diferentes.

Tomemos o exemplo do meu UTXO sem KYC da Bisq; quero evitar combiná-lo com um UTXO de, digamos, uma plataforma de troca regulamentada que conhece a minha identidade. Com efeito, se alguma vez utilizar estes dois UTXO como inputs para a mesma transação, a plataforma regulamentada poderá associar a minha identidade ao UTXO que comprei no Bisq, que não estava anteriormente associado à minha identidade.

Finalmente, ao escolher quais UTXOs usar como entradas para uma transação, o mais importante é evitar o uso de múltiplos UTXOs. No máximo, quando puder, selecione uma única moeda suficientemente grande para satisfazer o seu pagamento. Desta forma, evita completamente os riscos associados à CIOH. No entanto, se nenhuma UTXO for suficiente para o pagamento e tiver de consumir várias, certifique-se de que provêm de fontes semelhantes para minimizar o risco de ligações indesejadas. Tenha também em conta que o destinatário pode associar as informações que possui sobre si ao historial das moedas utilizadas nas entradas.

Compreender a seleção automática de peças

Nas secções anteriores, discutimos a seleção manual de UTXOs a serem utilizados para uma transação. Mas o que acontece quando o software da carteira efectua esta seleção automaticamente? Existem vários métodos para determinar quais moedas consumir, e a seleção de UTXOs constitui um verdadeiro campo de pesquisa sobre Bitcoin. O principal objetivo deste processo automático é frequentemente minimizar os custos de transação para o utilizador.

Os métodos de seleção UTXO como o FIFO (First In First Out) e o LIFO (Last In First Out) estão entre os mais simples, mas também são os menos eficientes. Com o FIFO, as partes mais antigas da carteira são utilizadas em primeiro lugar. Esta abordagem é geralmente ineficiente tanto para minimizar os custos de transação como para preservar a confidencialidade, exceto nos casos em que são utilizados relógios de ponto relativos que têm de ser renovados regularmente. Por outro lado, o LIFO dá prioridade à utilização dos UTXOs mais recentes. Ambos os métodos, embora simples, revelam-se frequentemente ineficazes.

Um método mais avançado é o Knapsack Solver. Este foi usado na carteira Bitcoin Core até a versão 0.17. Consiste na seleção iterativa e aleatória de UTXOs da carteira, somando-os em subconjuntos, e mantendo a solução que reduz o peso da transação tanto quanto possível, de modo a reduzir o custo para o utilizador.

O Branch-and-Bound (BNB), muitas vezes apelidado de "algoritmo Murch" em homenagem ao seu inventor, substituiu o Knapsack Solver no Bitcoin Core a partir da versão 0.17. Este método mais avançado visa encontrar um conjunto de UTXOs que corresponda exatamente ao montante necessário para satisfazer os outputs de uma transação. O objetivo do BNB é minimizar o montante da troca, bem como as taxas, reduzindo o chamado critério de desperdício, que tem em conta tanto os custos imediatos como os custos futuros esperados da troca. Este método é derivado do conceito original de Branch-and-Bound, concebido em 1960 por Ailsa Land e Alison Harcourt, e oferece uma otimização mais precisa das taxas do que o Knapsack Solver.

Todos estes métodos de seleção automática de UTXOs podem ser eficazes na redução dos custos de transação, mas são frequentemente ineficazes na preservação da confidencialidade do utilizador. De facto, estes algoritmos podem fundir vários UTXOs em entradas, revelando assim uma propriedade comum destes UTXOs devido ao CIOH. Obviamente, estes métodos não podem ter em conta os rótulos afixados nos UTXOs, que são, no entanto, cruciais para escolher conscientemente quais as partes a revelar ao destinatário da transação. Atualmente, a única forma de otimizar a confidencialidade na seleção de moedas é fazê-lo manualmente.

Tutorial sobre etiquetagem UTXO

Se quiser saber como marcar os seus UTXOs, fizemos um tutorial completo sobre o principal software de carteira Bitcoin existente:

https://planb.network/tutorials/privacy/on-chain/utxo-labelling-d997f80f-8a96-45b5-8a4e-a3e1b7788c52

KYC e identificação de chaves

KYC significa "Know Your Customer" (Conheça o seu cliente). Trata-se de um procedimento regulamentar implementado por certas empresas que operam no sector do Bitcoin. O objetivo deste procedimento é verificar e registar a identidade dos seus clientes, com o objetivo declarado de combater o branqueamento de capitais e o financiamento do terrorismo.

Em termos práticos, o KYC envolve a recolha de vários dados pessoais do cliente, que podem variar consoante a jurisdição, mas geralmente incluem identificação, fotografia e comprovativo de morada. Esta informação é depois verificada e armazenada para utilização futura.

Este procedimento tornou-se obrigatório para todas as plataformas de câmbio regulamentadas na maioria dos países ocidentais. Isto significa que qualquer pessoa que pretenda trocar moedas estatais por bitcoin através destas plataformas deve cumprir os requisitos KYC.

Este procedimento não é isento de riscos para a privacidade e segurança dos utilizadores. Neste capítulo, examinaremos estes riscos em pormenor e analisaremos os impactos específicos do KYC e dos processos de identificação na privacidade dos utilizadores de Bitcoin.

Facilitar o rastreio onchain

O primeiro risco associado ao KYC é o facto de oferecer um ponto de entrada privilegiado para a análise da cadeia de blocos. Como vimos na secção anterior, os analistas podem agrupar e acompanhar a atividade na cadeia de blocos utilizando padrões de transação e heurística. Uma vez que tenham conseguido agrupar a atividade de um utilizador na cadeia, tudo o que precisam de fazer é encontrar um único ponto de entrada entre todas as suas transacções e chaves para comprometer totalmente a sua confidencialidade.

Quando realiza um KYC, fornece um ponto de entrada de alta qualidade para a análise da cadeia de blocos, uma vez que associa os seus endereços de receção utilizados quando retira os seus bitcoins de uma plataforma de troca à sua identidade completa e verificada. Em teoria, esta informação é conhecida apenas pela empresa à qual a forneceu, mas, como veremos abaixo, o risco de fuga de dados é real. Além disso, o simples facto de uma empresa possuir esta informação pode ser problemático, mesmo que não a partilhe.

Assim, se não tomar outras medidas para limitar a agregação das suas actividades na cadeia de blocos, qualquer pessoa com conhecimento deste ponto de entrada KYC pode potencialmente ligar toda a sua atividade na Bitcoin à sua identidade. Do ponto de vista dessa empresa, a sua utilização da Bitcoin perde toda a confidencialidade.

Para ilustrar isto com uma comparação, é como se o seu banqueiro no Banco X não só tivesse acesso a todas as suas transacções com o Banco X, mas também pudesse observar as suas transacções com o Banco Y e todas as suas transacções em numerário.

Lembre-se da primeira parte deste curso de formação: O modelo de confidencialidade do Bitcoin, tal como concebido por Satoshi Nakamoto, baseia-se na separação entre a identidade do utilizador e os seus pares de chaves. Embora esta camada de confidencialidade já não seja suficiente atualmente, continua a ser prudente limitar ao máximo a sua degradação.

Exposição à vigilância do Estado

O segundo grande problema do KYC é o facto de revelar ao Estado que o utilizador possuiu bitcoin em algum momento. Quando se compram bitcoins através de um ator regulamentado, é possível que o Estado tenha conhecimento dessa posse. De momento, isto pode parecer trivial, mas é importante lembrar que o futuro político e económico do seu país não está nas suas mãos.

Em primeiro lugar, o Estado pode adotar rapidamente uma posição autoritária. A história está cheia de exemplos em que as políticas mudaram abruptamente. Atualmente, na Europa, os bitcoiners podem escrever artigos sobre a Bitcoin, participar em conferências e gerir as suas carteiras em autocustódia. Mas quem pode dizer o que o futuro reserva? Se a Bitcoin se tornar subitamente o inimigo público número um, ser associado a ela nos ficheiros governamentais pode revelar-se problemático.

Depois, em caso de crise económica grave, o Estado poderá considerar a possibilidade de confiscar as bitcoins detidas pelos cidadãos. Talvez amanhã os bitcoiners sejam vistos como aproveitadores da crise e sejam excessivamente tributados pelas suas mais-valias face à desvalorização da moeda fiduciária.

Poderá pensar que isto não é um problema, uma vez que as suas bitcoins estão misturadas e, por isso, não são rastreáveis. No entanto, a rastreabilidade não é a questão aqui. O verdadeiro problema é o facto de o Estado saber que possui bitcoins. Só esta informação pode ser suficiente para o incriminar ou responsabilizar. Pode tentar alegar que gastou os seus bitcoins, mas isso teria de ser refletido na sua declaração de impostos e seria apanhado. Também poderia dizer que perdeu as suas chaves num acidente de barco, mas para além da piada no Twitter, acha mesmo que isso seria suficiente para o ilibar?

Por isso, é importante ter em conta o risco de o Estado saber que se possui BTC, por mais remoto que esse risco possa parecer atualmente.

Outro problema colocado pelo KYC em termos de supervisão estatal é a obrigatoriedade de comunicação por parte das plataformas regulamentadas. Embora eu não esteja familiarizado com os regulamentos de outras jurisdições, em França, os Prestataires de Services sur Actifs Numériques (PSAN) são obrigados a comunicar às autoridades de supervisão financeira qualquer movimento de fundos que considerem suspeito.

Em França, em 2023, foram comunicados 1 449 actos suspeitos pelas PSAN. Por enquanto, a maioria desses atos está relacionada ao crime. No entanto, as autoridades também pedem às plataformas regulamentadas que comuniquem quaisquer transacções suspeitas de Bitcoin apenas com base na sua estrutura. Se efetuar uma transação colaborativa, ou mesmo apenas uma transação com um padrão ligeiramente atípico, e esta transação ocorrer não muito longe da retirada das suas Bitcoins destas plataformas, poderá ser denunciado às autoridades. Mesmo na ausência de má-fé e no exercício legítimo dos seus direitos, essa denúncia pode levar a um aumento dos controlos e da vigilância, inconvenientes que teria evitado sem o KYC.

O risco de fuga de dados pessoais

Outro problema com o KYC é o facto de exigir que todos os seus dados pessoais sejam armazenados nos servidores de uma empresa privada.

Os acontecimentos recentes recordaram-nos que ninguém está imune a falhas financeiras ou informáticas. Em 2022, os clientes da Celsius sofreram as consequências. Na sequência da falência da empresa, os nomes dos credores e o montante dos seus activos foram tornados públicos pelos tribunais americanos durante o processo administrativo.

Há pouco mais de dois anos, foi um porta-estandarte da cibersegurança das criptomoedas que viu os dados pessoais dos seus clientes serem roubados. Embora este incidente não estivesse diretamente relacionado com a compra de bitcoins, este risco também se mantém para as plataformas de câmbio. Existe, por conseguinte, um risco concreto associado aos dados pessoais.

É verdade que já confiamos muitos dos nossos dados pessoais a empresas privadas. No entanto, o risco aqui é duplo, uma vez que estes dados não só o identificam, como também estão ligados à atividade no Bitcoin. De facto, quando um hacker tem acesso aos dados dos clientes de uma plataforma de troca, pode razoavelmente presumir que esses clientes possuem Bitcoins. Este risco é agravado pelo facto de a Bitcoin, como qualquer outro bem valioso, atrair a atenção dos ladrões.

No caso de uma fuga de dados, na melhor das hipóteses, poderá ser alvo de tentativas de phishing direcionadas. Na pior das hipóteses, pode encontrar-se no centro de ameaças físicas à sua casa.

Para além dos riscos específicos associados à Bitcoin, existem também os perigos associados à transmissão de documentos de identidade. De facto, em caso de fuga de dados, é possível ser vítima de roubo de identidade. Assim, o que está em jogo não é apenas a proteção da confidencialidade das transacções, mas também a segurança pessoal de cada indivíduo.

Algumas ideias preconcebidas sobre KYC

É importante desconstruir algumas das ideias preconcebidas sobre KYC com que nos deparamos frequentemente no Twitter ou nas nossas trocas de impressões entre bitcoiners.

Em primeiro lugar, é incorreto pensar que a proteção da privacidade das Bitcoins adquiridas através do KYC é inútil. As ferramentas e métodos de privacidade na Bitcoin são variados e servem diferentes objectivos. Utilizar transacções coinjoin em Bitcoins adquiridas via KYC, por exemplo, não é uma má ideia. É claro que é necessário ter cuidado com as plataformas de câmbio regulamentadas para evitar que a sua conta seja congelada ou banida, mas de um ponto de vista estritamente técnico, estas práticas não são incompatíveis. A Coinjoin tem o efeito de quebrar o historial de uma moeda, ajudando-o assim a impedir certos riscos de análise de cadeia associados ao KYC. Embora não elimine todos os riscos, representa um benefício significativo.

A confidencialidade na Bitcoin não deve ser vista de forma binária, como uma distinção entre bitcoins "anónimos" e outros que não o são. Possuir Bitcoins adquiridos através do KYC não significa que tudo está perdido; pelo contrário, a utilização de ferramentas de confidencialidade pode revelar-se ainda mais benéfica.

Por outro lado, a aquisição de bitcoin através de um método nãoKYC não garante uma confidencialidade perfeita, nem o isenta da necessidade de tomar outras medidas de proteção. Se detiver bitcoin nãoKYC mas reutilizar endereços de receção várias vezes, as suas transacções podem ser rastreadas e agregadas. A mais pequena ligação ao mundo fora da Bitcoin pode comprometer a única camada de confidencialidade de que dispõe. Por isso, é importante considerar todas as ferramentas e métodos de aumento de privacidade no Bitcoin como complementares. Cada técnica aborda um risco específico e pode adicionar uma camada extra de proteção. Assim, possuir uma Bitcoin sem KYC não significa que não seja necessário tomar outras precauções.

O KYC pode ser cancelado?

Por vezes, perguntam-me se é possível "voltar atrás" depois de efetuar um KYC e, como pode imaginar pelos parágrafos anteriores, a resposta tem nuances. A forma mais simples de evitar os riscos associados ao KYC é não o utilizar na aquisição de bitcoins. Analisaremos esse assunto com mais profundidade no próximo capítulo. No entanto, se o KYC já tiver sido efectuado e os bitcoins adquiridos, existem formas de mitigar os riscos envolvidos?

Quando se trata do risco de rastrear as suas transacções, a utilização de coinjoin é uma solução. Analisaremos esse método em detalhes mais adiante no curso, mas você deve saber que o coinjoin permite que você quebre o histórico de uma moeda e evite que ela seja rastreada no passado-presente e presente-passado. Mesmo para o BTC obtido através de uma plataforma regulamentada, esta técnica pode impedir a sua rastreabilidade.

No entanto, o coinjoin não elimina o segundo risco associado ao KYC: o facto de o Estado poder ser informado da sua posse de bitcoins. De facto, mesmo que as suas moedas já não sejam rastreáveis, o Estado, consoante a jurisdição, pode ter acesso às suas declarações de transferência de criptoativos. Uma vez que este risco não é técnico, mas administrativo, não existem soluções específicas para a Bitcoin para o eliminar, para além de não se expor ao KYC em primeiro lugar. A única abordagem legal para mitigar este risco é vender em plataformas regulamentadas as suas Bitcoins adquiridas através de plataformas regulamentadas e depois recomprá-las através de meios sem KYC. Ao vender e declarar a transferência, as autoridades devem ver que já não as possui.

Quanto ao risco de fuga dos seus dados pessoais e documentos de identidade, este é um perigo externo à Bitcoin, e não existe uma solução técnica para o evitar. Uma vez que os seus dados tenham sido revelados, é difícil desfazer a operação. Pode tentar fechar a sua conta na plataforma, mas isso não garante a eliminação dos seus dados KYC, especialmente quando a verificação de identidade é externalizada. A verificação da eliminação completa das suas informações é impossível. Por conseguinte, não existe uma solução para evitar completamente este risco e garantir que ele deixe de existir.

A diferença entre KYC e identificação de chaves

Por vezes, alguns bitcoiners tendem a alargar o termo "KYC" a qualquer troca de BTC que envolva uma transferência bancária ou um pagamento com cartão de crédito, uma vez que estes meios também podem revelar a origem do pagamento, tal como um KYC faria. No entanto, KYC não deve ser confundido com identificação de chaves. A título pessoal, devo admitir que a minha perceção deste assunto tem evoluído ao longo do tempo.

KYC refere-se especificamente a um procedimento regulamentar implementado por certas empresas para verificar e registar a identidade dos seus clientes. É uma coisa binária: ao adquirir bitcoins, ou se faz KYC ou não se faz. No entanto, a identificação-chave, que diz respeito à ligação entre uma faceta da identidade de um utilizador e a atividade onchain, não é tão binária, mas representa antes um continuum. De facto, no contexto da aquisição ou transferência de bitcoin, essa identificação é sempre possível em diferentes graus.

Por exemplo, se comprar bitcoins numa plataforma regulamentada na Suíça, o KYC não é necessário. No entanto, as suas chaves podem ser identificadas, uma vez que a compra foi efectuada através da sua conta bancária. É aqui que os dois primeiros riscos associados ao KYC - facilitação do rastreio onchain e exposição à vigilância estatal - também se podem manifestar numa troca sem KYC. Se a entidade suíça comunicar transacções suspeitas às autoridades do seu país, estas podem simplesmente verificar a conta bancária utilizada para a compra para descobrir a sua identidade. Assim, a compra sem KYC em plataformas regulamentadas é bastante elevada na escala de risco para a identificação de chaves.

No entanto, evitar plataformas regulamentadas e optar por métodos de aquisição P2P não elimina totalmente o risco de identificação de chaves, mas apenas o reduz. Vejamos o exemplo de uma compra no Bisq ou noutra plataforma P2P. Para pagar à sua contraparte, utilizará provavelmente a sua conta bancária. Se as autoridades interrogarem a pessoa com quem efectuou a transação e pedirem o seu nome, voltamos aos riscos 1 e 2. Embora estes riscos sejam muito mais reduzidos do que quando se compra numa plataforma sem KYC, e ainda mais reduzidos do que quando se compra com KYC, continuam a estar presentes em menor grau.

Por último, mesmo que adquira os seus bitcoins através de uma troca física por dinheiro, não é totalmente anónimo. A pessoa com quem fez a troca viu o seu rosto, que faz parte da sua identidade. Embora mínima neste exemplo, existe ainda uma possibilidade de identificação chave.

Em conclusão, quando os bitcoins são trocados por outros activos, quer se trate de uma compra em moeda nacional ou de uma venda contra um bem real, existe sempre uma forma de identificação da chave. Dependendo do método de troca escolhido, esta identificação pode variar em intensidade. É importante não confundir esta identificação com o KYC, que é um processo regulamentar bem definido. No entanto, existe uma ligação entre o KYC e o espetro de identificação, uma vez que o KYC está no extremo superior do espetro, pois facilita sistematicamente a identificação das chaves dos utilizadores pelas autoridades.

Métodos de venda e aquisição

Depois de ler o capítulo anterior, pode estar a perguntar-se como pode comprar ou vender bitcoin sem ter de se submeter a um procedimento de verificação de identidade, de modo a evitar os riscos associados ao KYC. Existem várias formas de transacionar bitcoin.

Trocas de dinheiro P2P

Como vimos, o melhor método em termos de confidencialidade continua a ser a troca P2P (pessoa a pessoa) com liquidação em dinheiro. Este método permite-lhe minimizar os vestígios deixados e reduz consideravelmente a possibilidade de identificação da chave, quer esteja a comprar ou a vender.

No entanto, existem riscos para a segurança pessoal. O principal perigo reside no facto de, durante a troca, a contraparte saber que tem na sua posse uma grande soma de dinheiro, quer em numerário quer em bitcoins. Esta informação pode atrair a atenção de pessoas mal-intencionadas. Com efeito, é geralmente aconselhável ser discreto em relação aos seus activos em bitcoins. Este conselho também se aplica ao dinheiro vivo. No entanto, quando se troca pessoalmente, é inevitável revelar que se possui bitcoins, o que pode atrair atenções indesejadas.

Para limitar este risco, aconselho-o a preferir transacções em dinheiro com pessoas de confiança, como familiares ou amigos próximos. Em alternativa, pode também considerar negociar em [encontros locais de Bitcoin] (https://btcmap.org/communities/map), depois de participar algumas vezes. Isto permitir-lhe-á conhecer melhor os outros participantes e não estar sozinho quando efectua trocas físicas. No entanto, é importante reconhecer que as trocas de dinheiro P2P implicam riscos para a sua segurança pessoal que não existem quando compra através de uma plataforma regulamentada e da sua conta bancária.

Além disso, dependendo do local onde se vive, transportar e armazenar grandes somas de dinheiro pode ser arriscado, quer se trate de bitcoin ou de dinheiro.

A troca de dinheiro líquido pode também representar um risco jurídico em caso de controlo policial ou outro. Embora na maior parte dos países não haja restrições quanto à quantidade de dinheiro líquido que se pode transportar, os montantes excessivos podem levantar suspeitas. Por isso, tenha cuidado, sobretudo se tiver de percorrer longas distâncias, e evite fazer muitas transacções importantes de uma só vez, para não ter de justificar a posse de grandes quantias.

Por último, outra desvantagem das compras P2P é o facto de o preço ser frequentemente mais elevado do que nas plataformas regulamentadas. Os vendedores cobram frequentemente uma margem de lucro que varia entre 1% e, por vezes, mais de 10%. Há várias razões para esta diferença de preços. Em primeiro lugar, trata-se de uma prática comum entre os vendedores P2P que se foi consolidando ao longo do tempo. Em segundo lugar, os vendedores têm taxas associadas à transação para enviar os fundos ao comprador. Existe também um risco acrescido de roubo nas vendas P2P em comparação com as transacções em plataformas, o que justifica uma compensação pelo risco assumido. Por último, o custo adicional pode estar relacionado com a procura e a qualidade da troca em termos de confidencialidade. Enquanto comprador, o ganho de confidencialidade tem um preço que se reflecte na margem de lucro aplicada pelo vendedor. Alguns bitcoiners consideram também que a margem de lucro do BTC comprado em P2P reflecte o seu verdadeiro preço e argumentam que os preços mais baixos nas plataformas regulamentadas são o resultado de um compromisso sobre a confidencialidade dos seus dados pessoais.

Trocas P2P através de uma plataforma de matchmaking

Uma alternativa menos arriscada em termos de segurança pessoal é efetuar trocas P2P exclusivamente online, através de métodos de pagamento electrónicos como o PayPal, transferências bancárias ou Revolut.

Esta abordagem evita muitos dos riscos associados às transacções em numerário. No entanto, o risco de incumprimento da contraparte numa troca em linha é maior. De facto, numa troca física, se entregar dinheiro ao vendedor que não lhe envia os bitcoins em troca, pode imediatamente pedir-lhe contas, uma vez que ele está à sua frente. Na Internet, por outro lado, é muitas vezes impossível encontrar alguém que nos tenha roubado.

Para atenuar este risco, é possível utilizar plataformas especializadas para trocas P2P. Estas plataformas utilizam mecanismos de resolução de conflitos para proteger os utilizadores lesados. Normalmente, oferecem um sistema de caução, onde os bitcoins são mantidos até que o pagamento em moeda fiduciária seja confirmado pelo vendedor.

Em termos de segurança pessoal, este método de compra é consideravelmente mais seguro do que uma troca física de dinheiro. No entanto, como mencionado acima, as trocas P2P online deixam mais rastos do que uma troca física, o que pode ser prejudicial para a privacidade na Bitcoin. Ao utilizar um método de pagamento fiduciário online, como um banco, expõe mais informações que podem facilitar a identificação de chaves.

Mais uma vez, não recomendo que se façam muitas transacções grandes numa única transação nestas plataformas. Ao dividir as suas transacções, está a repartir o risco de roubo da contraparte.

Mais uma vez, outra desvantagem das compras P2P é o facto de o preço ser frequentemente mais elevado do que o observado nas plataformas regulamentadas. Os vendedores cobram frequentemente uma margem de lucro que varia entre 1% e, por vezes, mais de 10%. Há várias razões para esta diferença de preços. Em primeiro lugar, trata-se de uma prática comum entre os vendedores de P2P que se foi estabelecendo ao longo do tempo. Em segundo lugar, os vendedores têm taxas associadas à transação para enviar os fundos ao comprador. Existe também um risco acrescido de roubo nas vendas P2P em comparação com as transacções em plataformas, o que justifica uma compensação pelo risco assumido. Por último, o custo adicional pode estar relacionado com a procura e a qualidade da troca em termos de confidencialidade. Enquanto comprador, o ganho de confidencialidade tem um preço que se reflecte na margem de lucro aplicada pelo vendedor. Alguns bitcoiners consideram também que a margem de lucro do BTC comprado em P2P reflecte o seu verdadeiro preço e argumentam que os preços mais baixos nas plataformas regulamentadas são o resultado de um compromisso sobre a confidencialidade dos seus dados pessoais.

No que diz respeito às soluções, pessoalmente sempre utilizei o [Bisq] (https://bisq.network/) e estou muito satisfeito com ele. O seu sistema foi testado e parece fiável. No entanto, o Bisq só está disponível para PC e a sua interface pode ser demasiado complexa para principiantes. Outra desvantagem é que o Bisq só funciona com transacções onchain, o que pode tornar-se dispendioso durante períodos de elevadas taxas de transação de Bitcoin.

-> Consulte o nosso tutorial Bisq.

https://planb.network/tutorials/exchange/peer-to-peer/bisq-fe244bfa-dcc4-4522-8ec7-92223373ed04

Para uma opção mais simples, pode experimentar Peach, uma aplicação móvel que liga compradores e vendedores com um sistema integrado de resolução de conflitos. O processo é mais intuitivo do que o do Bisq.

-> Ver o nosso tutorial Peach.

https://planb.network/tutorials/exchange/peer-to-peer/peach-c6143241-d900-4047-9b73-1caba5e1f874

Outra opção online é [HodlHodl] (https://hodlhodl.com/), uma plataforma bem estabelecida que oferece boa liquidez, embora eu não a tenha testado pessoalmente.

-> Veja o nosso tutorial HodlHodl.

https://planb.network/tutorials/exchange/peer-to-peer/hodlhodl-d7344cd5-6b18-40f5-8e78-2574a93a3879

Para soluções baseadas na Lightning Network, experimente RoboSats e LNP2PBot. O RoboSats é acessível através de um sítio Web e é relativamente simples de utilizar. O LNP2PBot é mais atípico, pois funciona através de um sistema de troca na aplicação de mensagens Telegram.

-> Ver o nosso tutorial RoboSats.

-> Ver o nosso tutorial LNP2PBot.

https://planb.network/tutorials/exchange/peer-to-peer/robosats-b60e4f7c-533a-4295-9f6d-5368152e8c06

https://planb.network/tutorials/exchange/peer-to-peer/lnp2pbot-v2-e6bcb210-610b-487d-970c-7cce85273e3c

Plataformas regulamentadas sem KYC

Dependendo do país onde vive, pode ter acesso a plataformas regulamentadas que não requerem procedimentos KYC para comprar ou vender bitcoins. Na Suíça, por exemplo, pode utilizar plataformas como Relai e MtPelerin.

-> Ver o nosso tutorial sobre Relai.

https://planb.network/tutorials/exchange/centralized/relai-v2-30a9671d-e407-459d-9203-4c3eae15b30e

Como vimos no capítulo anterior, este tipo de plataforma evita os riscos associados aos procedimentos KYC, mas apresenta um nível de risco mais elevado para a identificação das chaves. Assim, em termos de confidencialidade da Bitcoin, estas plataformas oferecem uma melhor proteção do que os métodos de compra com KYC, mas continuam a ser menos atractivas do que as bolsas P2P.

No entanto, em termos de segurança pessoal, a utilização destas plataformas é muito menos arriscada do que as trocas P2P. Além disso, são frequentemente mais simples de utilizar do que as plataformas P2P.

ATMs

Outra opção para comprar ou vender bitcoins sem KYC são os ATMs de criptomoeda. Pessoalmente, nunca tive a oportunidade de testar esta solução, uma vez que não existe nenhuma no meu país. Mas este método pode ser muito interessante, dependendo do sítio onde se vive.

O problema das caixas automáticas é que ou são proibidas em alguns países, ou altamente regulamentadas noutros. Se um ATM requer um procedimento de verificação de identidade, então está exposto aos mesmos riscos que os inerentes às plataformas reguladas pelo KYC. Por outro lado, se o ATM permitir transacções sem verificação de identidade para pequenos montantes, então a sua utilização pode oferecer um nível de confidencialidade comparável ao de uma troca de dinheiro P2P, evitando ao mesmo tempo a maioria dos riscos associados a este tipo de troca.

A principal desvantagem dos ATM é o facto de as comissões de câmbio serem frequentemente elevadas, variando entre alguns pontos percentuais e, por vezes, 15% do montante trocado.

Cartões de oferta

Por último, queria também apresentar-lhe uma solução que funciona bem para quem quer utilizar os seus bitcoins diariamente para fazer compras em vez de os vender contra moedas fiduciárias.

A melhor maneira de gastar BTC é, naturalmente, usar o Bitcoin ou a Lightning Network diretamente para comprar um bem ou serviço. No entanto, em muitos países, o número de comerciantes que aceitam Bitcoin ainda é limitado. Uma alternativa prática é usar cartões-presente.

Várias plataformas que não requerem procedimentos KYC oferecem a possibilidade de trocar bitcoins por cartões-presente que podem ser utilizados em grandes retalhistas. Estas incluem CoinsBee, The Bitcoin Company e Bitrefill. Estas plataformas tornam muito mais fácil a utilização diária dos seus bitcoins, dando-lhe acesso a uma vasta gama de produtos e serviços sem ter de os converter em moeda fiduciária.

https://planb.network/tutorials/exchange/centralized/bitrefill-8c588412-1bfc-465b-9bca-e647a647fbc1

Outros métodos de aquisição

Outras formas de adquirir bitcoins protegendo a sua privacidade incluem, obviamente, a extração. Para começar a minerar sats, não precisa de revelar a sua identidade; basta encontrar uma prova de trabalho válida e submetê-la à rede. Se optar pela mineração em pool, alguns pools exigem alguma forma de identificação, como um KYC, enquanto outros não.

Outro método consiste em trabalhar em troca de bitcoins. Este método de aquisição pode ser interessante, mas o grau de identificação exigido varia consideravelmente consoante as circunstâncias.

*Para escrever este capítulo, utilizei o curso de formação BTC205 dado por @pivi___ na rede Plan ₿ (disponível apenas em francês, de momento)

Consolidação, gestão UTXO e CIOH

Um dos aspectos mais complicados da gestão de uma carteira de autocustódia é a consolidação. Deve-se consolidar? Qual é o objetivo? Que tamanho de UTXO deve ser respeitado? Quais são os compromissos em termos de confidencialidade? É isso que vamos analisar nesta secção.

O que é a consolidação?

O Bitcoin funciona como um mercado de leilões, com os mineiros a darem preferência às transacções que oferecem as taxas mais baixas. No entanto, cada bloco tem um peso máximo, o que limita o número de transacções que podem ser incluídas. Como um bloco é produzido, em média, a cada 10 minutos, o espaço disponível em cada bloco é um recurso escasso.

Os mineiros, cujas actividades geram custos significativos em termos de eletricidade, activos fixos e manutenção, procuram naturalmente maximizar a sua rentabilidade. Por conseguinte, tendem a favorecer as transacções que geram as taxas mais elevadas em relação ao seu peso.

Nem todas as transacções Bitcoin têm o mesmo peso. Aquelas com mais entradas e saídas terão um peso maior. Por exemplo, vamos imaginar 2 transacções:

• A transação A inclui 1 entrada e 1 saída. Atribui 1.994 sats de taxas e tem um peso de 141 vB ;
• A transação B, uma transação mais complexa com 2 entradas e 2 saídas, atribui 2.640 sats em taxas para um peso de 220 vB.

Neste exemplo, embora a transação B ofereça uma taxa total mais elevada, os mineiros preferirão a transação A, uma vez que esta oferece uma melhor relação entre taxa e peso. Aqui está o cálculo para cada transação, expresso em sats por byte virtual (sat/vB):

TXA : 1994 / 141 = 14 sats/vB
TXB : 2640 / 220 = 12 sats / vB

Isto significa que, por cada unidade de peso, a transação A oferece mais custos do que a transação B, embora a transação B ofereça mais custos em termos absolutos.

Por conseguinte, é sempre mais interessante para o utilizador consumir o mínimo possível de entradas nas suas transacções. No entanto, é necessário consumir quantidades suficientes para poder satisfazer o pagamento de saída. Ao gerir a sua carteira, o utilizador precisa de ter UTXOs suficientemente grandes.

O princípio da consolidação é precisamente aproveitar os períodos em que as taxas são baixas no Bitcoin para fundir os seus UTXOs mais pequenos num único maior. Desta forma, quando as comissões aumentarem no Bitcoin, será possível efetuar transacções com um mínimo de inputs e, portanto, gastar menos em comissões em termos absolutos. O objetivo é, portanto, antecipar as transacções obrigatórias a efetuar durante os períodos de taxas elevadas.

Para além de poupar nos custos de transação, a consolidação de UTXOs ajuda a evitar a formação de "pó". A "poeira" refere-se a UTXOs cujo valor em sats é tão baixo que é insuficiente para cobrir os custos de transação necessários para os gastar. Isto faz com que estes UTXOs sejam economicamente irracionais de usar enquanto os custos de transação se mantiverem elevados. Ao juntar proactivamente os seus UTXOs, evita que se transformem em pó, assegurando que todos os seus fundos permanecem utilizáveis.

Qual é o tamanho mínimo dos vossos UTXOs?

Por vezes, perguntam-me qual é o valor mínimo recomendado para um UTXO. Infelizmente, não existe uma resposta universal, uma vez que depende das suas preferências e das condições do mercado de taxas. No entanto, aqui está uma fórmula que pode ajudá-lo a determinar um limite adequado às suas necessidades:

\frac {P \times F}T = M

Onde:

• p$ é o peso da transação;
• F representa a taxa de débito máxima em satoshis por vbyte (sats/vB) contra a qual se protege;
• t$ é a percentagem da taxa de transação que está disposto a pagar em relação ao valor total do UTXO ;
• m$ é o montante mínimo em satoshis para cada UTXO.

Vamos assumir que planeia cobrir as taxas de uma transação SegWit padrão com 1 entrada e 2 saídas, pesando 141 vB. Se estiver a cobrir até 800 sats/vB, e estiver disposto a gastar até 12% do valor UTXO em taxas, no máximo, então o cálculo seria:

\frac{141 \times 800}{0.12} = 940\ 000

Neste exemplo, seria portanto sensato manter um valor mínimo de 940.000 sats para UTXOs na sua carteira.

Consolidação e CIOH

Uma das heurísticas mais utilizadas na análise de blockchain é a CIOH (Common Input Ownership Heuristic), que assume que todos os inputs de uma transação Bitcoin pertencem à mesma entidade. O próprio princípio da consolidação é consumir vários UTXOs como inputs e criar um único UTXO como output. A consolidação permite assim a aplicação da ICOH.

Na prática, isso significa que um observador externo pode deduzir que todas as UTXOs consolidadas provavelmente pertencem à mesma pessoa e que a saída única gerada também pertence a ela. Esta situação pode pôr em causa a sua confidencialidade ao associar diferentes históricos de transacções. Por exemplo, digamos que eu consolide 3 UTXOs adquiridos através de P2P com um UTXO obtido através de uma plataforma que requer KYC :

Ao fazê-lo, qualquer entidade com acesso aos dados da plataforma de troca, potencialmente incluindo agências governamentais, poderá identificar que possuo outras quantidades de BTC. Anteriormente, estes UTXOs não estavam diretamente ligados à minha identidade; agora estão. Além disso, revela a todas as fontes que estou na posse de uma determinada quantidade de bitcoins.

No que diz respeito à gestão dos UTXO, as considerações económicas, que levam à consolidação para reduzir os custos, entram em conflito com as boas práticas em matéria de privacidade, que recomendariam nunca fundir UTXO. A escolha entre economia e confidencialidade depende, portanto, das prioridades de cada utilizador.

Se for possível evitar a consolidação mantendo UTXOs substanciais, isso é o ideal. Para tal, optimize os seus métodos de aquisição. Se comprar bitcoins em DCA, tente espaçar o mais possível as suas compras pontuais para consolidar o valor em menos UTXOs. Será mais fácil gerir uma compra única de 1000 euros a cada 2 meses do que uma compra de 120 euros todas as semanas. Isto minimiza o número de UTXOs gerados e simplifica a gestão da sua carteira, preservando a sua confidencialidade.

Se tiver de consolidar os seus bitcoins, dê preferência primeiro à consolidação de UTXOs da mesma fonte. Por exemplo, a fusão de 10 UTXOs de uma única plataforma afectará menos a sua confidencialidade do que a mistura de 5 UTXOs da plataforma A com 5 UTXOs da plataforma B. Se a consolidação de várias fontes for inevitável, tente separá-las de acordo com as suas caraterísticas. Por exemplo, agrupe os UTXOs adquiridos através de KYC numa transação e os obtidos através de P2P noutra.

Em qualquer caso, não se esqueça de que qualquer consolidação implica inevitavelmente uma perda de confidencialidade. Por isso, avalie cuidadosamente a necessidade desta operação e o impacto potencial na sua privacidade, tendo em conta o CIOH.

Outras boas práticas

Vejamos algumas outras práticas recomendadas para otimizar a sua privacidade na Bitcoin.

O nó completo

Possuir seus bitcoins em auto-custódia é ótimo, mas usar seu próprio nó completo é ainda melhor! Aqui está o porquê de ter seu próprio nó é crucial para o uso totalmente soberano do Bitcoin:

• Resistência à censura**: As suas transacções não podem ser bloqueadas por ninguém;
• Independência em relação a terceiros**: Já não depende de nenhum serviço externo para verificar os dados da cadeia de blocos;
• Participação ativa**: O utilizador pode definir as suas próprias regras de validação e participar diretamente no consenso;
• Contribuição para a rede**: Ao gerir um nó, ajuda a fortalecer e distribuir a rede Bitcoin;
• Educação técnica**: Gerir um nó completo é uma óptima forma de aprofundar os seus conhecimentos técnicos sobre Bitcoin.

Para além destes benefícios, a utilização de um nó completo também melhora a sua confidencialidade ao transmitir as suas transacções. Quando você emite uma transação, ela é primeiramente criada e assinada através de sua carteira. Para transmiti-la na rede Bitcoin, ela deve ser conhecida por pelo menos um nó. Ao usar seu próprio nó, você tem controle direto sobre essa distribuição, reforçando assim a sua confidencialidade e limitando o risco de vazamento de dados.

Se não tiver o seu próprio nó Bitcoin, será forçado a utilizar um nó de terceiros, como o oferecido pelo seu fornecedor de software de carteira. Para além da transmissão de transacções, a sua carteira requer acesso a várias informações, tais como transacções pendentes, saldos associados aos seus endereços e o número de confirmações das suas transacções. Para aceder a todos estes dados, é necessário consultar um nó.

O principal risco quando não se está a utilizar o seu próprio nó Bitcoin é que o operador do nó de terceiros possa observar as suas actividades na blockchain, ou mesmo partilhar esta informação com outras entidades. Para limitar esse risco, uma solução intermediária é usar um software de carteira que oculte suas conexões via Tor. Isto pode reduzir a exposição dos seus dados. No entanto, a solução ideal é ter o seu próprio nó Bitcoin e usá-lo para transmitir as suas transacções. Claro que também é preciso ter cuidado para não vazar nenhuma informação através do seu nó, mas esse é outro assunto que veremos em secções posteriores.

Para além da vantagem óbvia para a sua privacidade, ter o seu próprio nó completo também lhe garante a veracidade dos dados na blockchain, protege-o contra a censura e permite-lhe participar ativamente na governação da Bitcoin. Ao utilizar o seu próprio nó, contribui com o seu peso económico para a cadeia da sua escolha, o que é importante durante os conflitos no seio da comunidade, como por exemplo durante a Guerra dos Blocos de 2015 a 2017. No caso de uma bifurcação, a utilização de um nó de terceiros pode levá-lo a apoiar uma cadeia que não quer favorecer, uma vez que o operador do nó faz a escolha por si.

Como vê, por razões de confidencialidade e de soberania individual, é essencial gerir e utilizar o seu próprio nó completo!

Heurística de análise enganadora

De um modo mais geral, é importante compreender as heurísticas de que falámos na secção anterior, de modo a melhor as evitar ou enganar. A adoção de uma série de boas práticas pode ser benéfica, mesmo que não sejam essenciais. Elas oferecem uma camada extra de proteção que pode ser importante para manter a confidencialidade ao usar o Bitcoin.

O primeiro conselho que eu poderia dar é misturar-se com a multidão mais densa. No Bitcoin, isso significa usar os modelos de script mais amplamente adoptados. Por exemplo, os scripts P2WSH, frequentemente utilizados para configurações SegWit V0 multisig, são muito pouco comuns. Não permitem que se esconda num grande conjunto de anonimato. O mesmo se aplica a modelos mais antigos, como P2PKH ou P2SH. Embora estejam amplamente presentes no conjunto UTXO, são cada vez menos utilizados para novas transacções.

De um modo geral, é mais sensato optar pela norma de scripting mais recente, desde que tenha sido suficientemente adoptada. Assim, se em 2022, eu teria desaconselhado a utilização do P2TR (Taproot) devido à sua fraca adoção, em 2024, recomendaria que se optasse por este tipo de script ou, na sua falta, pelo script SegWit V0, uma vez que o número de transacções que utilizam o P2TR começa a representar uma proporção muito significativa.

Fonte : txstats.com

Outra dica para preservar a sua confidencialidade é tentar contornar a heurística interna da transação. Por exemplo, ao efetuar um pagamento, pode tentar evitar criar uma saída com um montante redondo, pois isso poderia indicar que a outra saída representa moeda estrangeira. Se precisar de enviar 100 k sats a um amigo, considere transferir um montante ligeiramente superior para escapar a esta heurística. Da mesma forma, tente não criar saídas de moeda estrangeira que sejam desproporcionadamente elevadas em relação ao pagamento efectuado, pois isso também pode revelar qual das saídas representa moeda estrangeira.

Finalmente, se realizar transacções de Bitcoin regularmente, certifique-se de que não as transmite sempre às mesmas horas. Ao distribuir a difusão das suas transacções ao longo do dia e da semana, evita dar aos observadores externos a oportunidade de detetar um padrão temporal baseado na zona horária que poderia reforçar a sua análise.

Além de todas essas boas práticas a serem adotadas diariamente, existem métodos ainda mais eficazes para quebrar completamente a rastreabilidade de seus bitcoins. Estes incluem, obviamente, as transacções coinjoin, que analisaremos em profundidade na próxima secção.

Compreender as transacções coinjoin

O que é uma transação coinjoin?

Depois de termos estudado os fundamentos da proteção da privacidade, vamos agora analisar técnicas mais sofisticadas destinadas a defender ativamente a sua confidencialidade, em particular através da separação do seu histórico de bitcoins. Na próxima parte, vamos analisar uma série de pequenas técnicas, mas primeiro, gostaria de vos falar sobre coinjoin.

O Coinjoin é frequentemente considerado o método mais eficaz de proteger a privacidade dos utilizadores de Bitcoin. Mas o que é exatamente uma transação coinjoin? Vamos descobrir.

Os princípios básicos do coinjoin

Coinjoin é uma técnica para quebrar o rastreamento de bitcoin no blockchain. Baseia-se numa transação colaborativa com uma estrutura específica com o mesmo nome: a transação coinjoin.

Como vimos nas primeiras partes deste curso, as transacções Bitcoin são conhecidas por todos os utilizadores através do seu nó. Portanto, é fácil verificar a cadeia de assinatura eletrónica de cada moeda e observar o seu histórico. Isto significa que todos os utilizadores podem tentar analisar as transacções de outros utilizadores. Consequentemente, o anonimato ao nível da transação é impossível. No entanto, o anonimato é preservado ao nível da identificação individual. Ao contrário do sistema bancário convencional, onde cada conta está ligada a uma identidade pessoal, na Bitcoin, os fundos estão associados a pares de chaves criptográficas (ou scripts), oferecendo aos utilizadores uma forma de pseudonimato por detrás de identificadores criptográficos.

A confidencialidade do Bitcoin é prejudicada quando observadores externos são capazes de associar UTXOs específicos a utilizadores identificados. Uma vez estabelecida esta associação, torna-se possível rastrear as suas transacções e analisar o seu historial Bitcoin. A Coinjoin é precisamente uma técnica desenvolvida para quebrar a rastreabilidade dos UTXOs, de modo a oferecer aos utilizadores de Bitcoin uma certa camada de confidencialidade ao nível das transacções.

Os Coinjoins reforçam a confidencialidade dos utilizadores de Bitcoin, tornando a análise da cadeia mais complexa para observadores externos. A sua estrutura permite que várias moedas de diferentes utilizadores sejam fundidas numa única transação, esbatendo as linhas e tornando difícil determinar as ligações entre os endereços de entrada e de saída.

É importante compreender que o objetivo de uma transação coinjoin é quebrar a história de uma moeda. Esta técnica não confere anonimato permanente ou bloqueia definitivamente o rastreio de bitcoins, ao contrário do que se possa pensar. A Coinjoin apenas pretende quebrar o histórico no momento em que a transação coinjoin é efectuada. No entanto, antes e depois desta operação, a moeda continua sujeita aos mesmos riscos em termos de confidencialidade.

Como é que os coinjoins funcionam?

O princípio coinjoin baseia-se numa abordagem colaborativa: vários utilizadores que desejam misturar as suas bitcoins depositam montantes idênticos como entradas na mesma transação. Estes montantes são depois redistribuídos em outputs de igual valor para cada utilizador.

No final da transação, torna-se impossível associar uma determinada saída a um utilizador conhecido como entrada. Não existe uma ligação direta entre entradas e saídas, o que quebra a associação entre os utilizadores e os seus UTXOs, bem como o histórico de cada peça.

Vejamos o exemplo da Alice. Ela quer enviar cerca de 100.000 sats à sua irmã Eva pelo seu aniversário. No entanto, Alice não quer que Eva possa rastrear o seu histórico de transacções, uma vez que não quer revelar quantos bitcoins tem ou como os obteve. Para isso, Alice decide quebrar o seu histórico UTXO com uma transação coinjoin. Organiza-se com Bob, Charles, David e Frank para realizar uma transação colaborativa:

• Alice, Bob, Charles, David e Frank comprometem, cada um, um UTXO de 105.000 sats (com 5.000 sats para taxas de mineração) como entradas para a transação:

• Em troca do consumo destes inputs, cada um gera um endereço em branco para criar cinco outputs idênticos de 100.000 sats cada. Cada um recupera uma saída:

• Alice encontra-se com um UTXO de 100.000 sats cujo historial está baralhado. Ela utiliza este UTXO numa nova transação para enviar o montante para a Eva pelo seu aniversário:

• Se Eve tentar analisar esta transação para extrair informação, será confrontada com a transação coinjoin envolvendo Alice, Bob, Charles, David e Frank. Incapaz de distinguir que entrada pertence a quem devido à uniformidade dos montantes, Eve não pode traçar o historial de UTXO de Alice, nem determinar quantos bitcoins a sua irmã possui ou como os adquiriu:

Neste caso, Alice utilizou a técnica coinjoin para aumentar a confidencialidade no que respeita à análise retrospetiva. Com efeito, Alice está a proteger-se contra uma possível análise por parte de Eve, que começaria a partir de uma transação específica e trabalharia para trás através da história do UTXO. Esta proteção contra a análise do presente para o passado é conhecida como anonset retrospetivo. Analisaremos este conceito com mais pormenor nos últimos capítulos desta secção.

No entanto, o coinjoin também oferece a possibilidade de reforçar a confidencialidade face a uma análise do passado para o presente, conhecida como anonset prospetivo. Voltemos ao nosso exemplo em que a Alice enviou à Eva 98.000 sats no seu aniversário, mas com os papéis invertidos. Agora imaginemos que é a Eva que está preocupada com a sua privacidade. De facto, a Alice pode sentir-se tentada a seguir a moeda que enviou à Eva para extrair informação dela. A Eva poderia muito bem consolidar este UTXO que acabou de receber com todos os seus outros UTXOs, o que poderia revelar à Alice a quantidade de bitcoins que tem na sua carteira. Para evitar isto, a Eve pode também quebrar o histórico da moeda que acabou de receber:

• Eve, Grace, Mallory, Oscar e Victor colocaram cada um um UTXO de 98.000 sats como entrada para uma transação Bitcoin:

• Em troca do consumo destes inputs, cada utilizador fornece um endereço em branco que será utilizado para criar 5 outputs de 97.500 sats perfeitamente iguais. Cada utilizador recebe um output:

• Eve tem agora um UTXO de 97.500 sats cujo historial foi quebrado. Ela pode usá-lo sem medo para efetuar futuras transacções. De facto, se Alice tentar rastrear os bitcoins que enviou a Eva, será confrontada com uma transação coinjoin. Ela não conseguirá determinar que UTXO de saída pertence a Eva. A análise torna-se impossível:

No primeiro exemplo, vimos como a junção de moedas pode proteger a privacidade de uma sala em relação ao seu passado e, no segundo exemplo, como pode também proteger a história de uma sala em relação ao seu futuro. Foi por isso que mencionei que a junção de moedas deve ser vista como um evento único que segmenta uma parte da história em ambas as direcções:

Misturador, coinjoin, misturador... Qual é a diferença?

As coinjoins são por vezes descritas como "mixers", um termo que alguns bitcoiners rejeitam, receando que possa ser confundido com os custodial mixers. Creio, no entanto, que esta apreensão é infundada, uma vez que, num contexto matemático, a coinjoin incorpora precisamente o conceito de mistura.

No domínio geral da matemática, a mistura refere-se à propriedade de um sistema dinâmico em que, após um determinado período de tempo, todas as porções do espaço inicial podem teoricamente misturar-se com qualquer outra porção. A mistura implica que a posição de uma partícula ou o estado de um sistema evolui de tal forma que a sua distribuição futura é independente da sua distribuição inicial, atingindo assim um estado em que as caraterísticas do estado inicial estão uniformemente distribuídas pelo espaço do sistema. É exatamente isto que acontece numa união de moedas com bitcoins. Por isso, na minha opinião, o coinjoin é verdadeiramente um método de mistura de moedas.

Por outro lado, é importante distinguir a coinjoin dos shufflers. Um shuffler é um serviço em que os utilizadores enviam os seus bitcoins para serem baralhados. Estes serviços foram populares durante a década de 2010, mas a sua utilização diminuiu devido a dois grandes inconvenientes em comparação com a coinjoin:

• Exigem que os utilizadores abdiquem da custódia dos seus fundos durante o processo de mistura, o que os expõe ao risco de roubo;
• Não existe qualquer garantia de que a misturadora não registe os detalhes da transação, ou mesmo que não venda esta informação a empresas de análise de cadeias.

Por conseguinte, os utilizadores actuais preferem a coinjoin, uma vez que lhes permite manter um controlo total sobre os seus fundos durante todo o processo. Os participantes na Coinjoin não correm o risco de verem os seus bitcoins roubados pelas outras partes envolvidas. Vamos ver como tudo isto é possível no próximo capítulo.

Zerolink e junções chaumianas

A privacidade proporcionada por um coinjoin é obtida pelo tamanho do grupo no qual a nossa peça está escondida. Isto significa encontrar o maior número possível de participantes. É perfeitamente possível criar uma coinjoin manualmente, com utilizadores que nós próprios encontrámos, mas este é um processo complexo e não lhe trará grandes ganhos.

É por isso que os coordenadores de coinjoin se desenvolveram na Bitcoin. O seu papel é colocar os vários utilizadores em contacto uns com os outros e transmitir a informação necessária para completar a transação colaborativa.

Mas como podemos garantir que o coordenador nunca tem acesso às bitcoins dos utilizadores e, apesar de ser ele a pessoa que constrói a transação coinjoin, como podemos garantir que não consegue ligar as entradas e saídas dos utilizadores, o que poderia constituir uma fuga de confidencialidade?

Assinaturas cegas de Chaum

As implementações modernas de coinjoin usam as assinaturas cegas de David Chaum para evitar vazamento de informações. Vamos dar uma olhada rápida em como essas assinaturas cegas funcionam.

As assinaturas cegas de Chaum são uma forma de assinatura digital em que o emissor de uma assinatura não conhece o conteúdo da mensagem que está a assinar. Mas a assinatura pode então ser verificada em relação à mensagem original. Esta técnica foi desenvolvida pelo criptógrafo David Chaum em 1983.

Vejamos o exemplo de uma empresa que pretende autenticar um documento confidencial, como um contrato, sem revelar o seu conteúdo. A empresa aplica um processo de mascaramento que transforma criptograficamente o documento original de forma reversível. Este documento modificado é enviado a uma autoridade de certificação, que apõe uma assinatura cega sem conhecer o conteúdo subjacente. Depois de receber o documento assinado, a empresa desmascara a assinatura. O resultado é um documento original autenticado pela assinatura da autoridade, sem que esta tenha visto o conteúdo original.

As assinaturas cegas de Chaum podem, portanto, certificar a autenticidade de um documento sem conhecer o seu conteúdo, garantindo assim a confidencialidade dos dados do utilizador e a integridade do documento assinado.

Chaumian junta-se a nós

Os chamados "Chaumian" coinjoins combinam a utilização do Tor e as assinaturas cegas de David Chaum para garantir que o coordenador não pode saber que output pertence a que utilizador.

O processo de construção da transação coinjoin envolve 3 fases principais: registo de entrada, registo de saída e assinatura da transação. Vejamos este processo através do exemplo de Alice, um dos participantes da coinjoin. Todos os outros participantes seguem os mesmos passos que Alice, cada um por si.

**Passo 1: Registo de entrada

• Alice transmite ao coordenador o UTXO que deseja utilizar como entrada para a transação, bem como o endereço de receção mascarado que deseja utilizar como saída para receber as suas bitcoins. O coordenador não tem, portanto, qualquer forma de conhecer o endereço de Alice. Apenas vê a sua versão mascarada:

• O coordenador verifica a validade das entradas e, em seguida, assina o endereço mascarado de Alice com a sua chave privada. Devolve a assinatura cega à Alice:

**Passo 2: Registo das saídas

• Alice pode desmascarar seu endereço, agora assinado pela chave privada do coordenador. Ela estabelecerá uma nova ligação com uma identidade Tor diferente. O coordenador não consegue identificar que é Alice que se está a ligar sob esta nova identidade:

• Alice envia o endereço desmascarado e a assinatura para o coordenador (que ainda não sabe que é Alice):

**Etapa 3: Assinatura da transação

• Da mesma forma, o coordenador obtém os resultados não identificados de todos os participantes. Graças às assinaturas associadas, ele pode verificar que cada resultado submetido anonimamente foi previamente assinado pela sua chave privada, garantindo assim a sua legitimidade. Está então pronto para criar a transação coinjoin e enviá-la aos participantes para assinatura:

• A Alice, tal como os outros participantes, verifica se o seu input e output estão corretamente incluídos na transação construída pelo coordenador. Se tudo for satisfatório, envia ao coordenador a assinatura que desbloqueia o seu guião de entrada:

• Depois de recolher as assinaturas de todos os participantes da coinjoin, o coordenador pode transmitir a transação na rede Bitcoin, para que possa ser adicionada a um bloco.

Neste sistema, o coordenador é incapaz de ligar uma entrada a uma saída específica. Além disso, não pode apropriar-se dos fundos dos participantes, pois nunca tem acesso às chaves privadas necessárias para desbloquear os seus UTXOs. Durante todo o processo, até ao final do passo 3, ele também não tem acesso às assinaturas. Quando Alice e os outros participantes assinam a transação global, depois de verificar que tudo está correto, o coordenador já não pode modificar a transação, incluindo os outputs, sem a invalidar. Isto impede o coordenador de roubar bitcoins.

Por último, ao registar a sua produção na transação, o utilizador da coinjoin pretende ter garantias semelhantes às de um cidadão que vota numa eleição. Existe uma dualidade entre os aspectos públicos e privados destas acções. Por um lado, há o que se quer manter privado: para o eleitor, ele não quer que o seu boletim de voto seja associado à sua identidade; para o utilizador do coinjoin, ele não quer que o seu output seja associado ao seu input. De facto, se o coordenador, ou qualquer outra parte, conseguir estabelecer uma ligação entre uma entrada e uma saída, o coinjoin perde todo o interesse. Como explicado acima, o coinjoin deve funcionar como uma paragem na história de uma moeda. Esta paragem ocorre precisamente devido à impossibilidade de associar um input específico a um output específico na transação coinjoin (anonset prospetivo) e vice-versa (anonset retrospetivo).

Por outro lado, há o aspeto público: o eleitor quer ter a certeza de que o seu boletim de voto está incluído na urna; da mesma forma, o utilizador da coinjoin quer ter a certeza de que a sua produção está incluída na transação da coinjoin. De facto, os participantes da coinjoin devem poder verificar a presença do seu output antes de assinarem a transação, caso contrário o coordenador poderia roubar os fundos.

São precisamente estes dois aspectos públicos e privados, possibilitados pela utilização das assinaturas cegas de David Chaum, que garantem aos participantes nos coinjoins chaumianos que as suas bitcoins não serão roubadas e que os seus fundos não podem ser rastreados.

Quem inventou o conceito de coinjoin?

É difícil dizer com certeza quem foi o primeiro a introduzir a ideia de coinjoin no Bitcoin, e quem teve a ideia de usar as assinaturas cegas de David Chaum neste contexto. Pensa-se frequentemente que foi Gregory Maxwell quem a mencionou pela primeira vez em uma mensagem no BitcoinTalk em 2013 :

*"Utilizando as assinaturas cegas de Chaum: Os utilizadores iniciam a sessão e fornecem entradas (e trocam endereços), bem como uma versão criptograficamente oculta do endereço para o qual pretendem enviar as suas partes privadas; o servidor assina os tokens e envia-os de volta. Os utilizadores voltam a ligar-se anonimamente, desmascaram os seus endereços de saída e enviam-nos de volta para o servidor. O servidor pode ver que todas as saídas foram assinadas por ele e que, consequentemente, todas as saídas provêm de participantes válidos. Mais tarde, as pessoas voltam a ligar-se e a registar-se Maxwell, G. (2013, 22 de agosto). CoinJoin: Privacidade Bitcoin para o mundo real. Fórum BitcoinTalk. https://bitcointalk.org/index.php?topic=279249.0

No entanto, há outras menções anteriores, tanto para assinaturas Chaum como parte da mistura, mas também para coinjoins. Em junho de 2011, Duncan Townsend apresentou no BitcoinTalk um misturador que usa assinaturas Chaum de uma forma bastante semelhante aos modernos Chaumian coinjoins.

No mesmo tópico, podemos encontrar uma mensagem de hashcoin em resposta a Duncan Townsend para melhorar o seu misturador. O processo descrito nesta mensagem é exatamente o que as coinjoins são. A menção a um sistema semelhante também pode ser encontrada em uma mensagem de Alex Mizrahi em 2012, quando ele estava a aconselhar os criadores da Tenebrix, uma das primeiras altcoins que serviu de base para a posterior criação da Litecoin. Até o próprio termo "coinjoin" não terá sido cunhado por Greg Maxwell, mas terá surgido de uma ideia de Peter Todd.

Zerolink

O Zerolink é um protocolo de mistura abrangente que incorpora coinjoins Chaumian e várias estratégias para proteger o anonimato dos utilizadores contra várias formas de análise em cadeia, em particular minimizando os erros associados à gestão de carteiras. Este protocolo [foi introduzido por nopara73 e TDevD em 2017] (https://github.com/nopara73/ZeroLink/blob/master/README.md).

Tal como o nome sugere, o princípio subjacente ao Zerolink é criar transacções coinjoin que garantam que as ligações entre entradas e saídas não podem ser rastreadas. Isto é conseguido assegurando que todos os outputs têm montantes perfeitamente idênticos.

Uma importante medida preventiva adoptada pela Zerolink consiste em manter os UTXOs não misturados completamente separados dos UTXOs misturados, utilizando conjuntos de chaves criptográficas separados, ou mesmo carteiras separadas. Isto diferencia a carteira "pre-mix", destinada a peças antes da mistura, da carteira "post-mix", reservada a peças que foram misturadas.

Esta separação rigorosa dos UTXOs serve sobretudo para evitar associações acidentais entre um UTXO misto e um UTXO não misto. Com efeito, se essas ligações ocorrerem, a eficácia da coinjoin no UTXO misto é anulada sem que o utilizador se aperceba, comprometendo assim a confidencialidade de um UTXO cujo historial pensava ter quebrado. Estas ligações podem ocorrer quer através da reutilização de endereços na fixação de um UTXO misto com um não misto, quer através da aplicação da CIOH (Common-Input-Ownership Heuristic), se o utilizador consumir UTXOs mistos e não mistos como entradas para a mesma transação. Ao separar as carteiras pré-mistura e pós-mistura, evitamos essas associações acidentais e protegemos o utilizador contra erros não intencionais.

Esta separação também oferece a possibilidade de aplicar regras distintas entre as carteiras pré-mistura e pós-mistura ao nível do software da carteira. Por exemplo, na carteira pós-mixing, o software pode proibir a fusão de UTXOs em inputs para evitar a aplicação de CIOH, o que comprometeria o anonset do utilizador. Também é possível normalizar a utilização de scripts e opções de transação (como o relatório RBF, por exemplo) para evitar a identificação por impressões digitais da carteira.

Atualmente, o Whirlpool é a única implementação de coinjoin que aplica rigorosamente o protocolo Zerolink. No próximo capítulo, veremos as várias implementações de coinjoin que existem, e as vantagens e desvantagens de cada uma.

Implementações Coinjoin

*Em 2024, estamos a assistir a grandes mudanças nas ferramentas disponíveis para os utilizadores que desejam fazer coinjoins em Bitcoin. Estamos atualmente num ponto de viragem e o mercado de coinjoins está a passar por uma grande reestruturação. Este capítulo será certamente atualizado ao longo do tempo

De momento, existem principalmente 3 implementações diferentes de coinjoin no Bitcoin:

• Hidromassagem;
• Wabisabi;
• JoinMarket.

Cada uma destas implementações visa quebrar a história dos UTXOs através de transacções coinjoin. No entanto, os seus mecanismos variam consideravelmente. Por conseguinte, é essencial compreender o funcionamento de cada uma delas, para que possa escolher a opção mais adequada às suas necessidades.

JoinMarket

A JoinMarket, fundada em 2015 por Adam Gibson e Chris Belcher, destaca-se claramente de outras implementações de coinjoin graças ao seu modelo único de ligação entre utilizadores. O sistema baseia-se num mercado de trocas P2P em que alguns utilizadores, os "makers", disponibilizam os seus bitcoins para serem misturados, enquanto outros, os "takers", utilizam esse dinheiro para fazer coinjoins em troca de uma taxa.

Neste modelo, os "criadores" disponibilizam os seus bitcoins aos "tomadores" e recebem uma taxa pelo seu serviço. Os takers, por sua vez, pagam para utilizar os bitcoins dos makers para efetuar as suas próprias transacções coinjoin. As taxas de serviço variam de acordo com a função ocupada: os "makers" acumulam taxas por oferecerem liquidez, enquanto os "takers" pagam as taxas. O mercado funciona livremente, sem condições de utilização.

Um dos principais inconvenientes do JoinMarket é a sua complexidade de utilização, que exige um certo grau de conforto com os terminais para o operar eficazmente. Embora esta complexidade não seja um obstáculo para o utilizador experiente, pode limitar o acesso ao público em geral. No entanto, a recente introdução de uma interface web denominada JAM tornou a sua utilização um pouco mais fácil.

Fonte : JAM

No entanto, a barreira técnica continua a ser um grande obstáculo. No ecossistema das coinjoins, onde a confidencialidade é reforçada pelo número de participantes, qualquer limitação que reduza a acessibilidade afecta diretamente a liquidez disponível, que é um fator crucial para a eficiência da mistura. A Bitcoin, sendo já um nicho nas transacções financeiras, vê a sua utilização de coinjoins como um sub-nicho, e a JoinMarket representa uma fração ainda mais especializada do mesmo, o que restringe o seu potencial para aumentar os anonsets dos seus utilizadores.

Apesar do seu modelo inovador de ligação P2P para coinjoiners, o JoinMarket tem algumas desvantagens significativas, particularmente em termos de estrutura transacional. Ao contrário de outras implementações como a Whirlpool, o JoinMarket não garante uma igualdade perfeita entre as saídas, e é possível traçar ligações determinísticas entre entradas e saídas. Além disso, não dispõe de ferramentas para impedir que peças já misturadas sejam novamente misturadas, o que poderia comprometer a confidencialidade pretendida pelos utilizadores.

Finalmente, embora o conceito JoinMarket seja interessante, especialmente para os interessados num mercado de liquidez dinâmico, as suas fraquezas estruturais e complexidade técnica tornam-no, na minha opinião, menos interessante tanto para os principiantes como para os especialistas que procuram uma implementação coinjoin.

Wabisabi

Wabisabi é outra implementação de coinjoin, com uma abordagem que centraliza a coordenação das transacções. Este modelo foi concebido Ádám Ficsór (nopara73), Yuval Kogman, Lucas Ontivero e István András Seres em 2021, e foi integrado ao software Wasabi 2.0 no ano seguinte. Wabisabi é precisamente uma evolução do modelo de coinjoin do software Wasabi lançado em 2018.

No final da década de 2010, a Wasabi adoptou uma estrutura de transação de moedas radicalmente diferente da Whirlpool. A Wasabi utilizou transacções coinjoin muito grandes, envolvendo dezenas de participantes, para aumentar os anonsets dos seus participantes. Em contrapartida, a Whirlpool optou por múltiplas transacções pequenas, permitindo que os anonsets crescessem exponencialmente em cada ciclo.

Os métodos de gestão de câmbios também distinguem as duas implementações. Com a Whirlpool, as divisas eram excluídas e isoladas dos UTXOs antes dos ciclos de coinjoin graças ao TX0, um conceito que explicarei mais pormenorizadamente no próximo capítulo. Com a Wasabi, por outro lado, as divisas constituíam um dos outputs da transação coinjoin, mantendo ligações determinísticas entre certos inputs e outputs.

Com o Wabisabi, a versão 2.0 do Wasabi adaptou a sua abordagem aos coinjoins para corresponder à do Whirlpool. Embora as transacções coinjoin continuem a ser muito grandes, é agora possível encadear vários ciclos sucessivos, seguindo o modelo Whirlpool. Foi também dada especial atenção à gestão da taxa de câmbio: ao contrário do Wasabi 1.0, em que a taxa de câmbio estava diretamente ligada às entradas dos utilizadores, o Wabisabi procura subdividir a taxa de câmbio em várias pequenas somas, divididas em denominações iguais para todos os participantes.

Vamos ilustrar isto com um exemplo simplificado envolvendo apenas 2 utilizadores: Alice deseja misturar 115.000 sats e Bob, 210.000 sats. Ignorando as taxas, com o Wasabi 1.0, uma transação coinjoin teria gerado 3 saídas de 100.000 sats, mais 1 troca de 15.000 sats para Alice e 1 troca de 10.000 sats para Bob. As saídas de troca continuariam a estar ligadas às entradas:

No âmbito do Wabisabi, a mesma transação teria produzido 3 saídas de 100 000 sats e 5 saídas de 5 000 sats, dispersando assim a troca de modo a que não pudesse ser diretamente ligada a um input específico:

Pessoalmente, considero que a gestão de divisas da Wabisabi apresenta vários riscos que podem comprometer a sua eficácia em termos de confidencialidade:

• Quando um utilizador contribui com uma UTXO significativamente maior do que a dos outros participantes, acaba inevitavelmente por ter um montante de troca que estará ligado à sua contribuição. Isto vai contra o objetivo original do protocolo, que é eliminar todas as trocas identificáveis;
• A multiplicação das denominações com o objetivo de fragmentar a troca pode, paradoxalmente, ser prejudicial à eficácia da mistura. Este processo pode levar a uma redução dos anonsets para certos produtos, uma vez que estes se tornam mais facilmente identificáveis;
• Este método também gera UTXOs de baixo valor que colocam um problema de gestão para o utilizador. Estes pequenos UTXOs, se se tornarem demasiado dispendiosos em relação ao seu valor, podem tornar-se "pó". Este fenómeno leva o utilizador a fundir vários UTXO em entradas para futuras transacções, ou a consolidá-los. Em ambos os casos, devido ao CIOH, isto pode reduzir os anonsets obtidos ou anular completamente os benefícios de confidencialidade adquiridos pela união inicial de moedas.

Contrariamente à Whirlpool, que aplica o protocolo ZeroLink que assegura uma separação rigorosa entre os UTXOs pré-misturados e pós-misturados, a Wabisabi não mantém esta separação rigorosa. Além disso, alguns clientes da Wasabi tiveram problemas de reutilização de endereços, o que é obviamente muito prejudicial para o utilizador.

Na versão 2.0 do Wasabi, foi implementada uma nova política de taxas de junção de moedas. A partir de agora, as taxas de coordenação são fixadas em 0,3% para UTXOs acima de 0,01 bitcoin, enquanto que para UTXOs mais pequenos, estas taxas são oferecidas na totalidade. Além disso, as remisturas para estes UTXOs mais pequenos são gratuitas, embora as taxas de mineração continuem a ser pagas pelo utilizador para todas as transacções, incluindo as remisturas.

Isto contrasta com a política da Whirlpool, onde as taxas permanecem fixas, independentemente do tamanho dos anonsets obtidos. Com a Wasabi 2.0, embora as taxas de coordenação sejam dispensadas para pequenos UTXOs, o utilizador continua a ter de pagar taxas de mineração em todas as transacções, incluindo remixes.

No momento em que escrevo estas linhas, a utilização do Wabisabi tornou-se significativamente mais complexa em resultado de acontecimentos recentes. Na sequência da detenção dos fundadores da Samourai Wallet, a zkSNACKs, a empresa que financia e gere o desenvolvimento do Wasabi, anunciou que o seu serviço de coordenação de coinjoin seria descontinuado a 1 de junho de 2024. Este coordenador, que foi criado por defeito no Wasabi, foi responsável pela grande maioria da liquidez.

Com a descontinuidade deste coordenador principal, os utilizadores devem agora ligar-se a novos coordenadores independentes. Esta alteração suscita uma série de preocupações: por um lado, os novos coordenadores podem não ter liquidez suficiente, reduzindo a eficácia dos coinjoins em termos de confidencialidade. Por outro lado, existe o risco de se deparar com um coordenador mal-intencionado. Esta situação acrescenta novos riscos significativos para aqueles que pretendem utilizar o Wabisabi.

Para além das questões técnicas, a decisão da zkSNACKs, a empresa por detrás do Wasabi, de utilizar os serviços de uma empresa de análise de cadeias de caracteres para filtrar os participantes em coinjoins levanta sérias questões éticas e estratégicas. A ideia inicial era impedir a utilização de coinjoins no Wasabi por criminosos, uma medida que pode parecer legítima. No entanto, levanta um paradoxo: pagar taxas a um coordenador cuja principal missão é reforçar a confidencialidade do utilizador, para que este financie uma empresa cujo objetivo é comprometer essa mesma confidencialidade.

Mais preocupante ainda é o princípio da filtragem, que contrasta radicalmente com a filosofia do Bitcoin de oferecer um sistema financeiro aberto e sem censura. Embora possa parecer justificado querer excluir actividades criminosas, esta filtragem pode também afetar indivíduos cujas acções, embora classificadas como ilegais em certos contextos, podem ser moralmente justificáveis ou socialmente benéficas. O exemplo de Edward Snowden ilustra na perfeição esta dicotomia: considerado criminoso por alguns governos devido às suas revelações, é visto por outros como um delator que agiu no interesse público. Esta complexidade sublinha o perigo potencial da filtragem que, embora bem intencionada, pode acabar por prejudicar os direitos e a segurança dos utilizadores legítimos. Poderia também ter mencionado activistas e jornalistas que são perseguidos em certos regimes autoritários.

Como já devem ter percebido, a minha preferência vai definitivamente para o modelo Whirlpool para as junções de moedas em Bitcoin. Este sistema destaca-se pelo seu rigor e oferece garantias superiores de confidencialidade. É também o único a oferecer uma mistura considerada perfeita num contexto matemático. Na minha opinião, este modelo representa o futuro dos coinjoins em Bitcoin. Convido-vos a aprofundar este modelo no próximo capítulo.

Como funciona a Whirlpool

O que distingue a Whirlpool de outros métodos de junção de moedas é a utilização de transacções "ZeroLink", que asseguram que não existe rigorosamente nenhuma ligação técnica possível entre todas as entradas e saídas. Esta combinação perfeita é conseguida através de uma estrutura em que cada participante contribui com uma quantidade idêntica de entradas (com exceção das taxas de exploração mineira), gerando saídas de quantidades perfeitamente iguais.

Esta abordagem restritiva dos inputs confere às transacções conjuntas da Whirlpool uma caraterística única: a ausência total de ligações determinísticas entre inputs e outputs. Por outras palavras, cada output tem a mesma probabilidade de ser atribuído a qualquer participante, relativamente a todos os outros outputs da transação.

Como funciona a Whirlpool

Inicialmente, o número de participantes em cada coinjoin da Whirlpool era limitado a 5, com 2 novos participantes e 3 remixers (explicaremos estes conceitos mais tarde). No entanto, o aumento das taxas de transação na cadeia observado em 2023 levou as equipas de Samourai a repensar o seu modelo para melhorar a confidencialidade e reduzir os custos. Assim, tendo em conta a situação do mercado de taxas e o número de participantes, o coordenador pode agora organizar coinjoins incluindo 6, 7 ou 8 participantes. Estas sessões melhoradas são conhecidas como "Surge Cycles". É importante notar que, qualquer que seja a configuração, há sempre apenas 2 novos participantes nos coinjoins da Whirlpool.

Assim, as transacções da Whirlpool são caracterizadas por um número idêntico de entradas e saídas, que podem ser :

• 5 entradas e 5 saídas ;

• 6 entradas e 6 saídas ;

• 7 entradas e 7 saídas ;

• 8 entradas e 8 saídas.

O modelo da Whirlpool baseia-se em pequenas transacções de coinjoin. Ao contrário do Wabisabi e do JoinMarket, onde a robustez dos anonsets se baseia no volume de participantes num único ciclo (ou em alguns ciclos), a Whirlpool baseia-se na sequência de vários pequenos ciclos.

Neste modelo, os utilizadores pagam taxas apenas quando se juntam pela primeira vez a uma pool, permitindo-lhes participar numa multiplicidade de remixes sem custos adicionais. Os novos participantes pagam as taxas de extração dos remisturadores.

Com cada coinjoin adicional em que uma peça participe, bem como com os seus pares encontrados no passado, os anonsets crescerão exponencialmente. O objetivo é tirar partido destas remisturas gratuitas, que, de cada vez que ocorrem, contribuem para reforçar a densidade dos anonsets associados a cada peça misturada.

A Whirlpool foi concebida com dois requisitos importantes em mente:

• A acessibilidade da aplicação nos dispositivos móveis, uma vez que a Samourai Wallet é, antes de mais, uma aplicação para smartphone;
• Ciclos de remistura rápidos para promover um aumento significativo de anonsets.

Estes imperativos orientaram as escolhas feitas pelos criadores da Samourai Wallet na conceção da Whirlpool, levando-os a restringir os participantes a um número limitado por ciclo. Um número demasiado pequeno teria comprometido a eficiência da junção de moedas, reduzindo drasticamente os anonsets gerados por ciclo, enquanto um número demasiado elevado teria colocado problemas de gestão nas aplicações móveis e dificultado o fluxo do ciclo.

Finalmente, não é necessário ter um elevado número de participantes por coinjoin na Whirlpool, uma vez que os anonsets são efectuados com base na acumulação de vários ciclos de coinjoin. O princípio mais importante neste caso é a homogeneidade dos UTXOs de todos os participantes, uma vez que tal garante uma mistura perfeita e, por conseguinte, o pleno benefício dos ciclos de mistura e remistura.

Piscinas e taxas Coinjoin

Para que estes ciclos múltiplos aumentem os anonsets das peças misturadas, é necessário um determinado quadro para restringir as quantidades de UTXOs utilizadas. A Whirlpool define diferentes pools.

Uma pool representa um grupo de utilizadores que desejam misturar-se, que concordam com a quantidade de UTXOs a serem utilizados para otimizar o processo de coinjoin, mantendo a perfeita homogeneidade das peças. Cada pool especifica um montante fixo de UTXO, que o utilizador deve respeitar para poder participar. Assim, para fazer coinjoins com a Whirlpool, é necessário selecionar um pool. Atualmente, estão disponíveis os seguintes pools:

• 0.5 bitcoins ;
• 0.05 bitcoin ;
• 0.01 bitcoin ;
• 0.001 bitcoin (= 100.000 sats).

Quando entra numa pool com os seus bitcoins, estes serão divididos para gerar UTXOs perfeitamente homogéneos com os dos outros participantes na pool. Cada pool tem um limite máximo, pelo que, para montantes que excedam este limite, terá de efetuar duas entradas separadas no mesmo pool ou passar para outro pool com um montante superior:

| Pool (bitcoin) | Montante máximo por entrada (bitcoin)

|----------------|--------------------------------------|

| 0,5 | 35 |

| 0,05 | 3,5 |

| 0,01 | 0,7 |

| 0,001 | 0,025 |

Considera-se que um UTXO pertence a uma pool quando está pronto para ser integrado numa coinjoin. No entanto, isto não significa que o utilizador perca a sua posse. Como vimos nos primeiros capítulos desta secção, através dos vários ciclos de mistura, o utilizador mantém o controlo total das suas chaves e, consequentemente, dos seus bitcoins. Isto é o que diferencia a técnica coinjoin de outras técnicas de mistura centralizadas.

Para aderir a um pool de moedas, é necessário pagar uma taxa de serviço e uma taxa de mineração. As taxas de serviço são fixas para cada pool e destinam-se a remunerar as equipas responsáveis pelo desenvolvimento e manutenção da Whirlpool.

A taxa de serviço para a utilização do Whirlpool é paga apenas uma vez quando se junta à piscina. Uma vez inscrito, pode participar num número ilimitado de remixes sem qualquer custo adicional. Eis as taxas fixas actuais para cada pool:

| Pool (bitcoin) | Taxa de entrada (bitcoin)

|----------------|---------------------------------|

| 0,5 | 0,0175 |

| 0,05 | 0,00175 |

| 0,01 | 0,0005 (50.000 sats) |

| 0,001 | 0,00005 (5.000 sats) |

Essas taxas funcionam essencialmente como um bilhete de entrada para o pool escolhido, independentemente do valor que você coloca no coinjoin. Assim, quer entre no grupo 0.01 com exatamente 0.01 BTC ou 0.5 BTC, as taxas permanecerão as mesmas em termos absolutos.

Antes de proceder às junções da Whirlpool, o utilizador pode escolher entre 2 estratégias:

• Optar por uma piscina mais pequena para minimizar os custos de serviço, sabendo que receberá em troca vários UTXOs mais pequenos;
• Ou optar por um grupo maior, disposto a pagar taxas mais elevadas, para acabar com um número menor de UTXOs de maior valor.

Geralmente não é aconselhável fundir vários UTXOs mistos após ciclos de coinjoin, pois isso poderia comprometer a confidencialidade adquirida, particularmente devido à heurística de propriedade de entrada comum (CIOH: Common-Input-Ownership-Heuristic). Consequentemente, pode fazer sentido escolher uma pool maior, mesmo que isso signifique pagar mais, para evitar ter demasiados UTXOs de pequeno valor na saída. O utilizador deve avaliar estes compromissos para escolher o conjunto que prefere.

Para além da taxa de serviço, a taxa de mineração específica para qualquer transação Bitcoin também deve ser tida em conta. Como utilizador da Whirlpool, terá de pagar a taxa de mineração para a transação de preparação (Tx0), bem como para a primeira junção de moedas. Todas as remisturas subsequentes serão gratuitas, graças ao modelo da Whirlpool baseado no pagamento de novos participantes.

De facto, em cada Whirlpool coinjoin, 2 utilizadores entre os inputs são novos participantes. As outras entradas provêm de remixers. Consequentemente, os custos de extração para todos os participantes na transação são suportados por estes dois novos participantes, que podem também beneficiar de remisturas gratuitas:

Graças a este sistema de taxas, a Whirlpool destaca-se realmente de outras implementações de coinjoin, uma vez que os anonimatos dos UTXOs não são proporcionais ao preço pago pelo utilizador. Como resultado, é possível atingir níveis consideravelmente mais elevados de anonimato pagando apenas a taxa de entrada na pool e a taxa de mineração para 2 transacções (o Tx0 e o mix inicial).

É importante notar que o usuário também terá que pagar as taxas de mineração para retirar seus UTXOs do pool após completar seus múltiplos coinjoins, a menos que ele tenha selecionado a opção mix to, que fornece um endereço externo que receberá os fundos diretamente do coinjoin, sem qualquer transação adicional.

Contas de carteira HD

Para criar um coinjoin via Whirlpool, a carteira deve gerar várias contas separadas. Este é o princípio subjacente ao protocolo ZeroLink. Uma conta, no contexto de uma carteira HD (Hierarchical Deterministic), constitui uma secção totalmente isolada das outras, sendo que esta separação ocorre ao nível da terceira profundidade da hierarquia da carteira, ou seja, ao nível xpub.

Uma carteira HD pode, teoricamente, derivar até 2^(31) contas diferentes. A conta inicial, usada por padrão em todas as carteiras Bitcoin, corresponde ao índice 0'.

Para as carteiras adaptadas à Whirlpool, são utilizadas 4 contas para responder às necessidades do processo ZeroLink:

• A conta de depósito, identificada pelo índice 0' ;
• A conta do bad bank (ou "doxxic change"), identificada pelo índice 2.147.483.644' ;
• A conta premix, identificada pelo índice 2 147 483 645' ;
• A conta postmix, identificada pelo índice 2 147 483 646'.

Cada uma destas contas desempenha uma função específica no processo de coinjoin, que iremos explorar nas secções seguintes.

Todas estas contas estão ligadas a uma única semente, o que permite ao utilizador recuperar o acesso a todos os seus bitcoins utilizando a sua frase de recuperação e, se for caso disso, a sua frase-chave. No entanto, durante a operação de recuperação, o software deve ser informado dos diferentes índices de contas utilizados.

Vejamos as diferentes fases de uma junção da Whirlpool nestas contas.

O TX0

O ponto de partida de qualquer coinjoin da Whirlpool é a conta deposit. Esta é a conta que utiliza automaticamente quando cria uma nova carteira Bitcoin. Esta conta terá de ser creditada com os bitcoins que pretende misturar.

O "Tx0" é o primeiro passo do processo de mistura da Whirlpool. O seu objetivo é preparar e equalizar os UTXOs para o coinjoin, dividindo-os em unidades correspondentes à quantidade do pool selecionado, para garantir uma mistura homogénea. As UTXOs assim equalizadas são então enviadas para a conta premix. Quanto à diferença que não pode entrar no pool, é separada numa conta específica: o bad bank (ou "doxxic change").

Esta transação inicial Tx0 é também utilizada para pagar a taxa de serviço devida ao coordenador da coinjoin. Ao contrário dos passos seguintes, esta transação não é colaborativa, pelo que o utilizador deve suportar o custo total da exploração mineira:

Neste exemplo de transação Tx0, uma entrada de 372.000 sats da nossa conta de depósito é dividida em vários UTXOs de saída, que se dividem da seguinte forma:

• Um montante de 5.000 sats para o coordenador a título de taxas de serviço, correspondente à entrada no agrupamento de 100.000 sats;
• 3 UTXOs preparados para mistura, redireccionados para a nossa conta premix e registados no coordenador. Estes UTXOs são equalizados em 108.000 sats cada, para cobrir os custos de mineração para a sua futura mistura inicial;
• O excedente, que não pode entrar na reserva por ser demasiado pequeno, é considerado como moeda estrangeira tóxica. É enviado para a sua conta específica. Neste caso, esta troca ascende a 40 000 sats ;
• Finalmente, restam 3.000 sats, que não constituem uma produção, mas são os custos de extração necessários para confirmar Tx0.

Por exemplo, aqui está um verdadeiro Whirlpool Tx0 (não é meu): edef60744f539483d868caff49d4848e5cc6e805d6cdc8d0f9bdbbaedcb5fc46

As alterações tóxicas

O excedente que não pôde ser integrado na pool, aqui equivalente a 40.000 sats, é redireccionado para a conta bad bank, também conhecida como "doxxic exchange", para garantir uma separação rigorosa dos outros UTXOs da carteira.

Este UTXO é perigoso para a confidencialidade do utilizador, porque não só ainda está ligado ao seu passado e, por conseguinte, possivelmente à identidade do seu proprietário, como também é registado como pertencente a um utilizador que fez uma coinjoin.

Se este UTXO for fundido com saídas mistas, estas últimas perderão toda a confidencialidade obtida durante os ciclos de coinjoin, nomeadamente devido à CIOH (Common-Input-Ownership-Heuristic). Se for fundida com outras alterações tóxicas, o utilizador arrisca-se a perder a confidencialidade, uma vez que ligará as várias entradas do ciclo coinjoin. Por conseguinte, deve ser tratada com precaução. Entraremos em mais detalhes sobre a gestão destes UTXOs doxxic na última secção deste capítulo.

A mistura inicial

Após o Tx0, os UTXOs equalizados são enviados para a conta premix do nosso portfolio, prontos para serem introduzidos no seu primeiro ciclo de coinjoin, também conhecido como "initial mix". Se, como no nosso exemplo, o Tx0 gerar vários UTXOs para mistura, cada um deles será integrado numa mistura inicial separada.

No final destas primeiras misturas, a conta premix estará vazia, enquanto as nossas moedas, tendo pago as taxas de mineração para esta primeira junção de moedas, serão ajustadas exatamente ao montante definido pela pool escolhida. No nosso exemplo, os nossos UTXOs iniciais de 108,000 sats terão sido reduzidos para exatamente 100,000 sats.

Remixes

Após a mistura inicial, os UTXOs são transferidos para a conta postmix. Esta conta recolhe os UTXOs já misturados e os que aguardam remistura. Quando o cliente Whirlpool está ativo, os UTXOs localizados na conta postmix estão automaticamente disponíveis para remisturas e serão selecionados aleatoriamente para participar nestes novos ciclos.

Como lembrete, as remisturas são então 100% gratuitas: não são necessárias taxas de serviço adicionais ou taxas de mineração. Manter as UTXOs na conta postmix mantém, portanto, o seu valor intacto e melhora os seus anonsets ao mesmo tempo. É por isso que é importante permitir que estas moedas participem em vários ciclos de coinjoin. Não lhe custa absolutamente nada e aumenta os seus níveis de anonimato.

Quando decidir gastar UTXOs mistos, pode fazê-lo diretamente a partir desta conta postmix. Aconselhamo-lo a manter os UTXOs mistos nesta conta para beneficiar de remisturas gratuitas e para evitar que saiam do circuito Whirlpool, o que poderia reduzir a sua confidencialidade.

Como é que gere as suas pós-misturas?

Depois de executar ciclos de coinjoin, a melhor estratégia é manter os seus UTXOs na conta postmix, à espera de utilização futura. É mesmo aconselhável deixá-los remixar indefinidamente até precisar de os gastar.

Alguns utilizadores podem considerar a transferência dos seus bitcoins mistos para uma carteira protegida por uma carteira de hardware. Isto é possível, mas é importante seguir escrupulosamente as recomendações da Samourai Wallet para não comprometer a confidencialidade adquirida.

A fusão de UTXOs é o erro mais comum. Para evitar o CIOH (Common-Input-Ownership-Heuristic), deve evitar combinar UTXOs mistos com UTXOs não mistos na mesma transação. Isto requer uma gestão cuidadosa dos seus UTXOs dentro da sua carteira, particularmente em termos de rotulagem.

Também é necessário ter cuidado ao consolidar UTXOs mistos. É possível uma consolidação moderada se os seus UTXOs mistos tiverem anonsets significativos, mas isso reduzirá inevitavelmente a confidencialidade das suas partes. Certifique-se de que as consolidações não são demasiado extensas, nem efectuadas após um número insuficiente de remisturas, correndo o risco de estabelecer ligações dedutíveis entre os seus UTXOs antes e depois dos ciclos de coinjoin. Em caso de dúvida sobre estas manipulações, a melhor prática é não consolidar os UTXOs pós-mistura, mas transferi-los um a um para a sua carteira de hardware, gerando um novo endereço em branco de cada vez. Mais uma vez, lembre-se de etiquetar cada UTXO que receber.

Também não é aconselhável transferir seus UTXOs postmix para uma carteira usando scripts que não são muito usados. Por exemplo, se entrar na Whirlpool a partir de uma carteira multisig usando scripts P2WSH, há poucas hipóteses de ser misturado com outros utilizadores que originalmente tinham o mesmo tipo de carteira. Se você re-misturar seus postmixes para esta mesma carteira multisig, o nível de confidencialidade de seus bitcoins misturados será bastante reduzido. Para além dos scripts, existem muitas outras impressões digitais de carteiras que podem pregar-lhe partidas.

Como em qualquer transação Bitcoin, também é importante não reutilizar o endereço de receção. Cada nova transação deve ser recebida num endereço novo e em branco.

A solução mais simples e segura é deixar os seus UTXOs misturados em repouso na sua conta postmix, deixando-os remisturar e tocando-lhes apenas para gastar. As carteiras Samurai e Sparrow apresentam protecções adicionais contra todos estes riscos de análise da cadeia. Estas protecções ajudam-no a evitar cometer erros.

Como é que se gerem as trocas tóxicas?

De seguida, terá de ter cuidado com a sua gestão da troca tóxica, a troca que não entrou na pool do coinjoin. Estes UTXOs tóxicos, resultantes da utilização do Whirlpool, representam um risco para a sua privacidade, uma vez que estabelecem uma ligação entre si e o utilizador do coinjoin. Por conseguinte, é imperativo geri-los com cuidado e não os combinar com outros UTXOs, especialmente UTXOs mistos.

Eis algumas estratégias para os utilizar:

• Misture-os em piscinas mais pequenas:** Se o seu UTXO tóxico for suficientemente grande para caber sozinho numa piscina mais pequena, considere misturá-lo. Esta é muitas vezes a melhor opção. No entanto, não é aconselhável juntar vários UTXOs tóxicos para aceder a uma piscina, uma vez que isso poderia ligar as suas diferentes entradas;
• Marcá-los como "não gastáveis":** Outra abordagem consiste em deixar de os utilizar, marcá-los como "não gastáveis" na sua conta dedicada e simplesmente guardá-los. Isto garante que não as gasta acidentalmente. Se o valor do bitcoin subir, podem surgir novos pools mais adequados aos seus UTXOs tóxicos;
• Fazer donativos:** Considerar fazer donativos, mesmo que modestos, aos programadores que trabalham com Bitcoin e software relacionado. Você também pode doar para associações que aceitam BTC. Se a gestão dos seus UTXOs tóxicos parecer demasiado complicada, pode simplesmente livrar-se deles e fazer uma doação;
• Comprar cartões-presente:** Plataformas como a [Bitrefill] (https://www.bitrefill.com/) permitem trocar bitcoins por cartões-presente que podem ser usados em vários estabelecimentos comerciais. Esta pode ser uma forma de se desfazer dos seus UTXOs tóxicos sem perder o valor associado;
• Consolide-os no Monero:** A Samourai Wallet oferece um serviço de troca atómica entre BTC e XMR. Isso é ideal para gerenciar UTXOs tóxicos, consolidando-os no Monero, sem comprometer sua confidencialidade via CIOH, antes de enviá-los de volta ao Bitcoin. No entanto, esta opção pode ser dispendiosa em termos de taxas de mineração e prémio devido a restrições de liquidez;
• Envie-os para a Lightning Network:** Transferir estes UTXOs para a Lightning Network para beneficiar de taxas de transação reduzidas pode ser uma opção atractiva. No entanto, este método pode revelar determinadas informações, dependendo da forma como utiliza o Lightning, pelo que deve ser utilizado com precaução.

Como é que utilizo a Whirlpool?

Na sequência da detenção dos fundadores da Samourai Wallet e da apreensão dos seus servidores a 24 de abril de 2024, a ferramenta Whirlpool deixou de funcionar, mesmo para quem tem o seu próprio Dojo. Anteriormente, estava disponível na Samourai Wallet e na Sparrow Wallet.

No entanto, continua a ser possível que esta ferramenta seja reactivada nas próximas semanas, dependendo do resultado dos ensaios, ou relançada de uma forma diferente. Em todo o caso, não creio que o mercado de coinjoin Bitcoin fique sem oferta durante muito tempo, uma vez que existe procura. Para além disso, como o modelo da Whirlpool é o mais avançado em termos de confidencialidade, será certamente o modelo de eleição para outras implementações no futuro.

Estamos a acompanhar de perto este caso e a evolução das ferramentas associadas. Pode ter a certeza de que iremos atualizar este curso de formação à medida que forem surgindo novas informações.

No próximo capítulo, vamos descobrir o que são "anonsets", como é que estes indicadores são calculados e como é que nos podem ajudar a estimar a eficiência dos ciclos coinjoin.

https://planb.network/tutorials/privacy/on-chain/coinjoin-sparrow-wallet-84def86d-faf5-4589-807a-83be60720c8b

https://planb.network/tutorials/privacy/on-chain/coinjoin-samourai-wallet-e566803d-ab3f-4d98-9136-5462009262ef

https://planb.network/tutorials/privacy/on-chain/coinjoin-dojo-c4b20263-5b30-4c74-ae59-dc8d0f8715c2

Conjuntos de anonimato

Depois de termos estudado como funcionam as junções conjuntas e os problemas envolvidos numa mistura eficaz, vamos agora descobrir como medir a sua eficácia. Como podemos determinar se um processo de coinjoining foi eficaz e qual o grau de anonimato que uma parte adquiriu? É isso que vamos descobrir neste capítulo com os conjuntos de anonimato ou "anonsets".

Uma chamada de atenção para a utilidade do coinjoin

A utilidade do coinjoin reside na sua capacidade de produzir uma negação plausível, ao inserir a sua parte num grupo de partes indistinguíveis. O objetivo desta ação é quebrar as ligações de rastreabilidade, tanto do passado para o presente como do presente para o passado.

Por outras palavras, um analista que conheça a sua transação inicial (Tx0) à entrada dos ciclos de coinjoin não deve ser capaz de identificar com certeza o seu UTXO à saída dos ciclos de remix (análise da entrada do ciclo à saída do ciclo).

Por outro lado, um analista que conheça o seu UTXO à saída dos ciclos de coinjoin deve ser incapaz de determinar a transação original à entrada dos ciclos (análise da saída do ciclo à entrada do ciclo).

Para avaliar a dificuldade de um analista em ligar o passado ao presente e vice-versa, é necessário quantificar a dimensão dos grupos de partes homogéneas em que a sua parte está escondida. Esta medida diz-nos quantas análises têm a mesma probabilidade. Assim, se a análise correta estiver afogada entre 3 outras análises de igual probabilidade, o seu nível de ocultação é muito baixo. Por outro lado, se a análise correta for encontrada num conjunto de 20.000 análises igualmente prováveis, a sua parte está muito bem escondida. A dimensão destes grupos representa indicadores conhecidos como "anonsets".

Compreender os anonsets

Os anonsets são utilizados como indicadores para avaliar o grau de confidencialidade de um determinado UTXO. Mais especificamente, medem o número de UTXOs indistinguíveis dentro do conjunto que inclui a parte em estudo. A exigência de um conjunto homogéneo de UTXOs significa que os anonsets são normalmente calculados em ciclos coinjoin. A utilização destes indicadores é particularmente relevante para os coinjoints Whirlpool, devido à sua uniformidade.

Se necessário, os anonsets podem ser utilizados para avaliar a qualidade dos coinjoins. Um anonset grande significa um elevado nível de anonimato, uma vez que se torna difícil distinguir um UTXO específico dentro do conjunto homogéneo.

existem 2 tipos de anonsets:

• A perspetiva de anonimato ;**
• Retrospetiva anonset.**

O início prospetivo

O anonset prospetivo indica a dimensão do grupo entre o qual se esconde o UTXO estudado no final do ciclo, tendo em conta o UTXO no início, ou seja, o número de partes indistinguíveis presentes neste grupo. O nome deste indicador é "métrica prospetiva".

Este indicador mede a resistência da confidencialidade da divisão a uma análise do passado para o presente (input-to-output).

Esta métrica é utilizada para estimar até que ponto o seu UTXO está protegido contra tentativas de reconstrução do seu historial desde o ponto de entrada até ao ponto de saída no processo de coinjoin.

Por exemplo, se a sua transação tiver participado no primeiro ciclo de junção de moedas e tiverem sido concluídos mais dois ciclos descendentes, o anonset prospetivo da sua moeda será 13 :

Por exemplo, imaginemos que a nossa moeda no início do ciclo de coinjoin tem um anonset prospetivo de 86,871. Em termos práticos, isto significa que está escondida entre 86,871 partes indistinguíveis. Para um observador externo que conheça esta moeda no início do ciclo de junção de moedas e tente localizar a sua saída, será confrontado com 86,871 UTXOs possíveis, cada um com uma probabilidade idêntica de ser a moeda que procura.

A anonset retrospetiva

O anonset retrospetivo indica o número de fontes possíveis para uma determinada peça, conhecendo o UTXO no final do ciclo. Este indicador mede a resistência da confidencialidade da peça a uma análise do presente para o passado (output-to-input), ou seja, a dificuldade que um analista tem em rastrear a sua peça até à origem, antes dos ciclos de coinjoin. O nome deste indicador é "backward anonset", ou "backward-looking metrics".

Conhecendo o seu UTXO à saída dos ciclos, o anonset retrospetivo determina o número de potenciais transacções Tx0 que poderiam ter constituído a sua entrada nos ciclos de coinjoin. No diagrama abaixo, isto corresponde à soma de todas as bolhas cor de laranja.

Por exemplo, imaginemos que a nossa parte coinjoin tem um anonset retrospetivo de 42,185. Em termos práticos, isto significa que existem 42,185 fontes potenciais para este UTXO. Se um observador externo identificar esta moeda no final dos ciclos e procurar a sua origem, deparar-se-á com 42,185 fontes possíveis, todas com igual probabilidade de serem a origem procurada.

Como é que se calculam os anonsets?

É possível calcular anonsets manualmente utilizando um explorador de blocos para pequenos conjuntos. No entanto, para anonsets maiores, o uso de uma ferramenta especializada torna-se imperativo. Tanto quanto sei, o único software capaz de realizar esta tarefa é o Whirlpool Stats Tool, uma ferramenta Python desenvolvida pelas equipas Samourai e OXT. Infelizmente, esta ferramenta está atualmente fora de serviço na sequência da detenção dos fundadores da Samourai e da interrupção da OXT, que era utilizada para extrair dados da cadeia de blocos.

Como vimos neste capítulo, os anonsets só podem ser calculados se houver uma certa homogeneidade na estrutura da coinjoin. No próximo capítulo, descobriremos como quantificar essa homogeneidade numa transação Bitcoin, quer seja uma coinjoin ou uma transação mais tradicional.

https://planb.network/tutorials/privacy/analysis/wst-anonsets-0354b793-c301-48af-af75-f87569756375

Entropia

Como vimos nesta secção sobre coinjoins, a homogeneidade dos UTXOs na entrada e na saída desempenha um papel importante na melhoria da confidencialidade de uma transação Bitcoin. Este parâmetro cria uma negação plausível face à análise da cadeia de blocos. Vários métodos podem ser utilizados para medir esta homogeneidade, mas um dos mais eficazes, na minha opinião, é a utilização dos indicadores fornecidos pela ferramenta Boltzmann, desenvolvida pelas equipas OXT e Samourai Wallet, e em particular a entropia da transação. É isto que iremos analisar em pormenor neste capítulo.

Ao contrário dos anonsets, que são calculados com base num conjunto de transacções, os indicadores aqui apresentados centram-se numa única transação, quer se trate de uma coinjoin ou de uma transação mais tradicional.

O número de interpretações

O primeiro indicador que pode ser observado numa transação de Bitcoin é o número total de interpretações possíveis face a uma análise de um observador externo. Tendo em conta os valores dos UTXOs envolvidos na transação, este indicador mostra o número de formas em que os inputs podem ser associados aos outputs. Por outras palavras, determina o número de interpretações possíveis que uma transação pode suscitar nos fluxos de bitcoin do ponto de vista de um observador externo que a analisa.

Por exemplo, uma simples operação de pagamento com 1 entrada e 2 saídas terá apenas uma interpretação, nomeadamente que a entrada #0 financiou a saída #0 e a saída #1. Não há outra interpretação possível:

Por outro lado, um canto 5x5 da Whirlpool tem 1\,496 combinações possíveis:

Um Whirlpool Surge Cycle 8x8 coinjoin tem 9\,934\,563 interpretações possíveis:

Entropia

A partir do número de interpretações de uma transação Bitcoin, podemos calcular a sua entropia.

No contexto geral da criptografia e da informação, a entropia é uma medida quantitativa da incerteza ou imprevisibilidade associada a uma fonte de dados ou a um processo aleatório. Por outras palavras, a entropia é uma forma de medir a dificuldade de prever ou adivinhar uma informação.

No contexto específico da análise da cadeia de blocos, entropia é também o nome de um indicador, derivado da entropia de Shannon e [inventado por LaurentMT] (https://gist.github.com/LaurentMT/e758767ca4038ac40aaf), que pode ser calculado numa transação Bitcoin.

Quando uma transação apresenta um grande número de interpretações possíveis, é muitas vezes mais relevante referir a sua entropia. Este indicador mede a falta de conhecimento dos analistas sobre a configuração exacta da transação. Por outras palavras, quanto maior for a entropia, mais difícil se torna para os analistas identificar o fluxo de bitcoins entre entradas e saídas.

Na prática, a entropia revela se, do ponto de vista de um observador externo, uma transação apresenta múltiplas interpretações possíveis, baseadas apenas nos montantes de entrada e saída, sem ter em conta outros padrões e heurísticas externos ou internos. Uma entropia elevada é, portanto, sinónimo de maior confidencialidade da transação.

A entropia é definida como o logaritmo binário do número de combinações possíveis. Eis a fórmula utilizada com E a entropia da transação e C o número de interpretações possíveis:

E = \log_2(C)

Em matemática, o logaritmo binário (logaritmo de base 2) é a operação inversa da exponenciação de 2. Por outras palavras, o logaritmo binário de x é o expoente ao qual 2 deve ser elevado para obter x. Este indicador é, portanto, expresso em bits.

Vejamos o exemplo do cálculo da entropia para uma transação coinjoin estruturada de acordo com o modelo Whirlpool 5x5, que, como referido na secção anterior, tem um número de interpretações possíveis de 1\,496 :

\begin{align*}
C &= 1\,496 \\
E &= \log_2(1\,496) \\
E &= 10.5469 \text{ bits}
\end{align*}

Assim, esta transação coinjoin tem uma entropia de 10,5469 bits, o que é considerado muito satisfatório. Quanto maior for este valor, mais interpretações diferentes a transação admite, reforçando assim o seu nível de confidencialidade.

Para uma transação coinjoin 8x8 com 9\,934\,563 interpretações, a entropia seria :

\begin{align*}
C &= 9\,934\,563 \\
E &= \log_2(9\,934\,563) \\
E &= 23.244 \text{ bits}
\end{align*}

Vejamos outro exemplo com uma transação de pagamento clássica, com 1 entrada e 2 saídas: 1b1b0c3f0883a99f1161c64da19471841ed12a1f78e77fab128c69a5f578ccce

No caso desta transação, a única interpretação possível é: (In.0) > (Out.0 ; Out.1). Consequentemente, a sua entropia é 0 :

\begin{align*}
C &= 1 \\
E &= \log_2(1) \\
E &= 0 \text{ bits}
\end{align*}

Eficiência

Com base na entropia da transação, podemos também calcular a sua eficiência em termos de confidencialidade. Este indicador avalia a eficiência da transação comparando-a com a transação óptima que poderia ser prevista numa configuração idêntica.

Isto leva-nos ao conceito de entropia máxima, que corresponde à entropia mais elevada que uma estrutura de transação específica pode teoricamente atingir. A eficiência da transação é então calculada comparando esta entropia máxima com a entropia real da transação em análise.

A fórmula utilizada é a seguinte, com :

• e_R$: a entropia real da transação expressa em bits;
• e_M$: a entropia máxima possível para uma estrutura de transação, também expressa em bits;
• Ef: eficiência da transação em bits :

Ef = E_R - E_M

Por exemplo, para uma estrutura coinjoin Whirlpool 5x5, a entropia máxima é de 10,5469 :

\begin{align*}
E_R &= 10.5469 \\
E_M &= 10.5469 \\
Ef &= E_R - E_M \\
Ef &= 10.5469 - 10.5469 \\
Ef &= 0 \text{ bits}
\end{align*}

Este indicador é igualmente expresso em percentagem. A fórmula utilizada é a seguinte: :

• c_R$ : o número de interpretações reais possíveis ;
• c_M$: o número máximo de interpretações possíveis da mesma estrutura;
• Ef: eficiência expressa em percentagem:

\begin{align*}
E_f &= \frac{C_R}{C_M} \\
E_f &= \frac{1\,496}{1\,496} \\
E_f &= 100 \%
\end{align*}

Uma eficiência de 100 dólares indica que a transação está a tirar o máximo partido do seu potencial de confidencialidade, dependendo da sua estrutura.

Densidade de entropia

A entropia é um bom indicador para medir a confidencialidade de uma transação, mas depende em parte do número de entradas e saídas na transação. Para comparar a entropia de duas transacções diferentes com números diferentes de entradas e saídas, podemos calcular a densidade de entropia. Este indicador fornece uma perspetiva sobre a entropia relativa a cada entrada ou saída da transação. A densidade é útil para avaliar e comparar a eficiência de transacções de diferentes dimensões.

Para a calcular, basta dividir a entropia total da transação pelo número total de entradas e saídas envolvidas na transação:

• e_D$: densidade de entropia expressa em bits;
• e$: a entropia da transação expressa em bits;
• t$: número total de entradas e saídas na transação:

E_D = \frac{E}{T}

Vejamos o exemplo de uma junção 5x5 da Whirlpool:

\begin{align*}
T &= 5 + 5 = 10 \\
E &= 10.5469 \\
E_D &= \frac{E}{T} \\
E_D &= \frac{10.5469}{10} \\
E_D &= 1.054 \text{ bits}
\end{align*}

Vamos também calcular a densidade de entropia de uma união de 8x8 Whirlpool:

\begin{align*}
T &= 8 + 8 = 16 \\
E &= 23.244 \\
E_D &= \frac{E}{T} \\
E_D &= \frac{23.244}{16} \\
E_D &= 1.453 \text{ bits}
\end{align*}

Ao analisar a densidade de entropia destes dois tipos de junção, torna-se claro que, mesmo quando se normaliza a entropia pelo número de elementos, a junção "Surge Cycle 8x8" gera mais incerteza para a análise.

O índice de Boltzmann

Outra informação analisada numa transação é a pontuação de Boltzmann de cada elemento em relação a outro. Trata-se da tabela de probabilidades de correspondência entre inputs e outputs. Esta tabela indica, através do índice de Boltzmann, a probabilidade condicional de um input específico estar ligado a um determinado output. Trata-se, portanto, de uma medida quantitativa da probabilidade condicional de ocorrência de uma associação entre um input e um output numa transação, com base no rácio entre o número de ocorrências favoráveis deste evento e o número total de ocorrências possíveis, num conjunto de interpretações.

Utilizando o exemplo de um coinjoin da Whirlpool, a tabela de probabilidade condicional destacaria as hipóteses de uma ligação entre cada entrada e saída, oferecendo uma medida quantitativa da ambiguidade das associações na transação:

| % | Saída 0 | Saída 1 | Saída 2 | Saída 3 | Saída 4 |

| ------- | -------- | -------- | -------- | -------- | -------- |

| Entrada 0 | 34% | 34% | 34% | 34% | 34% | 34% | 34%

| Entrada 1 | 34% | 34% | 34% | 34% | 34% | 34% | 34% | Entrada 1

| Entrada 2 | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34

| Entrada 3 | 34% | 34% | 34% | 34% | 34% | 34% | 34% | Entrada 3

| Entrada 4 | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34

Claramente, cada entrada tem a mesma probabilidade de ser associada a qualquer saída, o que reforça a confidencialidade da transação.

A pontuação de Boltzmann é calculada dividindo o número de interpretações em que um determinado evento ocorre pelo número total de interpretações disponíveis. Assim, para determinar a pontuação que associa a entrada #0 à saída #3 (evento presente em 512 interpretações), procedemos da seguinte forma:

\begin{align*}
\text{Interpretations (IN.0 > OUT.3)} &= 512 \\
\text{Interpretations totales} &= 1496 \\
\text{Score} &= \frac{512}{1496} \\
\text{Score} &= 34 \%
\end{align*}

Se tomarmos o exemplo de uma junção de um ciclo de pico 8x8 da Whirlpool, a tabela de Boltzmann teria o seguinte aspeto:

| OUT.0 | OUT.1 | OUT.2 | OUT.3 | OUT.4 | OUT.5 | OUT.6 | OUT.7 |

|-------|-------|-------|-------|-------|-------|-------|-------|-------|

| IN.0 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23%

| IN.1 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23%

| IN.2 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23%

| IN.3 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23%

| IN.4 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23%

| IN.5 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23%

| IN.6 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23%

| IN.7 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23%

No entanto, no caso de uma transação simples com uma única entrada e duas saídas, a situação é diferente:

| Saída 0 | Saída 1 |

|---------|----------|----------|

| Entrada 0 | 100% | 100% |

Aqui, vemos que a probabilidade de cada output ter origem no input #0 é de 100%. Uma probabilidade mais baixa reflecte assim uma maior confidencialidade, diluindo as ligações diretas entre entradas e saídas.

Ligações determinísticas

Também podemos calcular o número de ligações determinísticas numa transação. Este indicador revela quantas das ligações entre entradas e saídas na transação analisada são inquestionáveis, com uma probabilidade de 100%. Este indicador pode depois ser completado com o cálculo do rácio de ligações determinísticas. O rácio fornece uma perspetiva do peso destas ligações determinísticas no total de ligações da transação.

Por exemplo, uma transação coinjoin da Whirlpool não tem ligações determinísticas entre entradas e saídas, pelo que apresenta um indicador de 0 ligações e um rácio de 0%. Pelo contrário, na segunda operação de pagamento simples analisada (com uma entrada e duas saídas), o indicador indica-nos que existem duas ligações determinísticas e o rácio atinge 100%. Por outras palavras, um indicador zero indica uma excelente confidencialidade, graças à ausência de ligações diretas e indiscutíveis entre os inputs e os outputs.

Como é que se calculam estes indicadores?

O cálculo manual destes indicadores, utilizando as equações que forneci, é relativamente simples. A dificuldade reside sobretudo em determinar o número de interpretações possíveis de uma transação. Para uma transação clássica, este cálculo pode ser feito à mão. No entanto, para uma coinjoin, a tarefa é muito mais complexa.

Anteriormente, existia uma ferramenta Python chamada Boltzmann Calculator, desenvolvida pelas equipas OXT e Samourai, que calculava automaticamente todos estes indicadores para uma transação Bitcoin :

Também foi possível utilizar o sítio Web KYCP.org para estas análises:

Infelizmente, após a detenção dos fundadores do Samourai, estas ferramentas deixaram de estar operacionais.

Agora que já abordámos as coinjoins em detalhe, vamos analisar as outras técnicas de privacidade disponíveis na Bitcoin na secção final do nosso curso. Iremos analisar payjoins, tipos específicos de transacções pseudo-coinjoin, protocolos de endereços estáticos, bem como medidas para reforçar a confidencialidade não ao nível das transacções em si, mas ao nível da rede de nós.

https://planb.network/tutorials/privacy/analysis/boltzmann-entropy-738e45af-18a6-4ce6-af1a-1bf58e15f1fe

Compreender os desafios de outras técnicas avançadas de confidencialidade

Transacções Payjoin

O Coinjoin é atualmente o método mais eficaz de introduzir incerteza no rastreio de peças numa análise em cadeia. Como vimos nos capítulos anteriores, para obter uma mistura de elevado desempenho, as entradas e saídas devem ser tão homogéneas quanto possível. Além disso, é importante que as peças sejam integradas num grupo tão grande quanto possível para maximizar os anonsets. Assim, para que os coinjoins sejam eficazes, devem envolver um grande número de peças uniformes. Esta multiplicidade de requisitos significa que as transacções de coinjoin têm uma estrutura muito rígida: os montantes são fixados antecipadamente e todos os participantes devem aderir aos mesmos para garantir a uniformidade do processo. Além disso, as coinjoins requerem sincronização entre todos os participantes e o coordenador durante a construção da transação.

Estes requisitos fazem com que a coinjoin não seja adequada para pagamentos diretos. Por exemplo, se tiver uma moeda de 1 milhão de sats numa pool coinjoin, utilizá-la diretamente como pagamento seria complexo. Seria necessária a sincronização com os outros participantes e o coordenador para construir a transação colaborativa precisamente no momento em que é necessário efetuar um pagamento, e o montante da compra teria de corresponder exatamente ao valor da sua moeda, o que é praticamente inviável. A transação coinjoin é, portanto, pela sua própria natureza, uma transação colaborativa de varrimento, ou seja, são normalmente os mesmos proprietários dos inputs que encontramos nos outputs.

No entanto, seria interessante dispor de estruturas de transação que permitissem efetuar pagamentos de forma prática, introduzindo ao mesmo tempo a dúvida na análise da cadeia. É precisamente isso que vamos analisar neste capítulo e no próximo.

O que é uma transação payjoin?

O payjoin é uma estrutura de transação Bitcoin específica que aumenta a privacidade do utilizador quando gasta, colaborando com o destinatário do pagamento.

Foi em 2015 que LaurentMT mencionou pela primeira vez este método sob a designação de "steganographic transactions", segundo um documento acessível aqui. Esta técnica foi posteriormente adotada pela carteira Samourai Wallet, que em 2018 se tornou o primeiro cliente a implementá-la com a ferramenta Stowaway. O conceito de payjoin também pode ser encontrado no BIP79, BIP78 e BIP77. Vários termos são utilizados para designar um payjoin:

• Pagamento ;
• Passageiro clandestino;
• P2EP (Pay-to-End-Point) ;
• Transação esteganográfica.

A caraterística especial do payjoin reside na sua capacidade de gerar uma transação que parece normal à primeira vista, mas que é, de facto, uma mini Coinjoin entre duas pessoas. Para tal, a estrutura da transação envolve o destinatário do pagamento nas entradas ao lado do remetente real. O destinatário inclui assim um pagamento a si próprio no meio da transação, o que lhe permite ser pago.

Vejamos um exemplo para compreender melhor este processo. Alice compra uma baguete por 4.000 sats usando um UTXO de 10.000 sats e opta por um payjoin. O seu padeiro, Bob, adiciona um UTXO de 15.000 sats que lhe pertence como entrada, que ele recupera na totalidade como saída, para além dos 4.000 sats da Alice.

Neste exemplo, Bob, o padeiro, entra com 15.000 sats e sai com 19.000 sats, sendo a diferença exatamente 4.000 sats, ou seja, o preço da baguete. Do lado da Alice, ela entra com 10.000 sats e acaba com 6.000 sats na saída, o que representa um saldo de -4.000 sats, ou seja, o preço da baguete. Para simplificar o exemplo, omiti deliberadamente os custos de extração nesta transação.

Para que é que serve o payjoin?

A operação payjoin cumpre dois objectivos, permitindo aos utilizadores aumentar a confidencialidade do seu pagamento.

Em primeiro lugar, a payjoin tem como objetivo enganar um observador externo, criando um engodo na análise da cadeia. Isto é possível graças à heurística CIOH (Common Input Ownership Heuristic). Como vimos na parte 3, normalmente, quando uma transação na cadeia de blocos tem vários inputs, presume-se que todos estes inputs pertencem à mesma entidade ou utilizador.

Assim, quando um analista examina uma transação de junção de pagamentos, é levado a crer que todos os dados provêm da mesma pessoa. No entanto, esta perceção é incorrecta, porque o beneficiário também contribui para os inputs juntamente com o pagador real. A análise da cadeia é, portanto, desviada para uma interpretação que se revela incorrecta.

Vejamos o nosso exemplo de uma transação payjoin para o pagamento de uma baguete:

Ao ver esta transação na blockchain, um observador externo, seguindo as heurísticas habituais da análise da blockchain, faria a seguinte interpretação: "Alice fundiu 2 UTXOs como inputs da transação para pagar 19.000 sats ao Bob".

Esta interpretação é obviamente incorrecta, porque, como já sabe, os dois UTXOs nas entradas não pertencem à mesma pessoa. Um vem de Alice, a compradora de baguetes, e o outro de Bob, o padeiro.

Desta forma, a análise do observador externo é orientada para uma conclusão errónea, garantindo a confidencialidade das partes interessadas.

A transação esteganográfica

O segundo objetivo do payjoin é induzir em erro um observador externo sobre o montante real do pagamento que foi efectuado. Ao examinar a estrutura da transação, o analista pode acreditar que o pagamento é equivalente ao montante de uma das saídas.

Se voltarmos ao nosso exemplo da compra de uma baguete, o analista pensará que o montante do pagamento corresponde ou ao UTXO de 6.000 sats, ou ao UTXO de 19.000 sats. Neste caso, o analista pensará antes que o montante do pagamento é de 19.000 sats, porque há 2 UTXOs em outputs, dos quais pelo menos um é superior a 6.000 sats (não há nenhuma razão lógica para utilizar 2 UTXOs para pagar 6.000 sats quando um único UTXO teria sido suficiente para satisfazer este pagamento).

Mas, na realidade, esta análise é incorrecta. O montante do pagamento não corresponde a nenhuma das realizações. É, de facto, a diferença entre o UTXO do destinatário em output e o UTXO do destinatário em input.

Neste aspeto, a transação payjoin cai no domínio da esteganografia. Permite que o montante real de uma transação seja escondido dentro de uma transação falsa que funciona como chamariz.

A esteganografia é uma técnica para esconder informação dentro de outros dados ou objectos, de modo a que a presença da informação escondida não seja percetível. Por exemplo, uma mensagem secreta pode ser escondida dentro de um ponto num texto não relacionado, tornando-a indetetável a olho nu (esta é a técnica do microponto).

Ao contrário da encriptação, que torna a informação incompreensível sem a chave de desencriptação, a esteganografia não modifica a informação. Esta continua a ser apresentada em texto claro. Pelo contrário, o seu objetivo é ocultar a própria existência da mensagem secreta, enquanto a encriptação revela claramente a presença de informação oculta, embora inacessível sem a chave. É por esta razão que o nome original do payjoin era "transacções esteganográficas".

É possível estabelecer uma analogia entre a criptografia e o coinjoin, e entre a esteganografia e o payjoin. O coinjoin tem atributos semelhantes aos da encriptação: o método é reconhecível, mas a informação é indecifrável. Por outro lado, o payjoin é semelhante à esteganografia: a informação é teoricamente acessível, mas como o método de ocultação não é reconhecível, torna-se inacessível.

Como é que utilizo o payjoin?

Os programas de software bem conhecidos que suportam payjoin incluem Sparrow Wallet, Wasabi Wallet, Mutiny, BitMask, BlueWallet e JoinMarket, bem como o processador de pagamentos BTCPay.

A implementação mais avançada do payjoin era apenas o Stowaway na Samourai Wallet. No entanto, desde a prisão dos fundadores do software, esta ferramenta está agora apenas parcialmente funcional. A vantagem do Stowaway é o facto de ser um protocolo abrangente e fácil de utilizar, que suporta tanto a receção como o envio de payjoins. As transacções parcialmente assinadas podem ser trocadas manualmente através da leitura de vários códigos QR, ou automaticamente pelo Tor via Soroban. Esta última opção de comunicação está atualmente fora de serviço.

A dificuldade em utilizar o payjoin reside na sua dependência da participação do comerciante. Como cliente, não pode utilizar um payjoin se o comerciante não o apoiar. Este facto acrescenta uma dificuldade adicional ao processo de compra: não só é difícil encontrar comerciantes que aceitem bitcoin, mas se também procurar aqueles que suportam payjoins, torna-se ainda mais complicado.

Uma solução consistiria em utilizar estruturas de transação que introduzissem ambiguidade na análise da cadeia sem exigir a cooperação do destinatário. Isto permitir-nos-ia melhorar a confidencialidade dos nossos pagamentos sem depender da participação ativa dos comerciantes. É precisamente o que veremos no próximo capítulo.

https://planb.network/tutorials/privacy/on-chain/payjoin-sparrow-wallet-087a0e49-61cd-41f5-8440-ac7b157bdd62

https://planb.network/tutorials/privacy/on-chain/payjoin-samourai-wallet-48a5c711-ee3d-44db-b812-c55913080eab

Pagamento mini-coinjoin

Quando se pretende efetuar uma transação de pagamento mantendo um certo grau de confidencialidade, o payjoin é uma boa opção. Mas, como acabámos de ver, o payjoin requer o envolvimento do destinatário. Então, o que fazer se o destinatário se recusar a participar num payjoin, ou se simplesmente preferir não o envolver? Uma alternativa é utilizar uma transação Stonewall ou Stonewall x2. Vamos analisar mais detalhadamente estes dois tipos de transação.

A transação Stonewall

A Stonewall é uma forma específica de transação Bitcoin concebida para aumentar a confidencialidade do utilizador quando gasta, imitando uma pseudo-coinjoin entre duas pessoas, sem que na realidade o sejam. De facto, esta transação não é colaborativa. Um utilizador pode construí-la sozinho, utilizando apenas os UTXOs que possui como inputs. Assim, é possível criar uma transação Stonewall para qualquer ocasião, sem necessidade de sincronização com outro utilizador ou com o destinatário.

A transação Stonewall funciona da seguinte forma: como entrada para a transação, o emitente utiliza 2 UTXOs que lhe pertencem. Na saída, a transação produz 4 UTXOs, 2 das quais são exatamente do mesmo montante. As outras 2 UTXOs constituirão moeda estrangeira. Das 2 saídas do mesmo montante, apenas uma irá efetivamente para o beneficiário.

Assim, existem apenas 2 papéis numa transação Stonewall:

• O emitente, que efectua o pagamento ;
• O destinatário, que pode não ter conhecimento da natureza específica da transação e espera simplesmente o pagamento do remetente.

Vejamos um exemplo para compreender esta estrutura de transação. Alice vai a Bob, o padeiro, para comprar a sua baguete, que custa 4.000 sats. Ela quer pagar em bitcoins, mantendo alguma forma de confidencialidade relativamente ao seu pagamento. Por isso, decide criar uma transação Stonewall para o pagamento.

Analisando esta transação, podemos ver que o Bob, o padeiro, recebeu 4.000 sats como pagamento pela baguete. A Alice usou 2 UTXOs como inputs: um de 10.000 sats e outro de 15.000 sats. Nas saídas, ela recuperou 3 UTXOs: uma de 4.000 sats, uma de 6.000 sats e uma de 11.000 sats. Alice tem, portanto, um saldo líquido de -4 000 sats nesta transação, o que corresponde ao preço da baguete.

Neste exemplo, negligenciei intencionalmente as taxas de extração para facilitar a compreensão. Na realidade, os custos de transação são inteiramente suportados pelo emissor.

Quais são os objectivos de uma transação Stonewall?

A estrutura de Stonewall acrescenta uma enorme quantidade de entropia à transação, confundindo as linhas de análise da cadeia. Vista de fora, uma transação deste tipo pode ser interpretada como uma mini-união de moedas entre duas pessoas. Mas, na realidade, trata-se de um pagamento. Este método cria, por conseguinte, incertezas na análise da cadeia, ou conduz mesmo a falsas pistas.

Vejamos o exemplo de Alice na padaria de Bob. A transação na cadeia de blocos teria o seguinte aspeto:

Um observador externo que se baseie na heurística da análise da cadeia comum poderá concluir erradamente que "duas pessoas efectuaram uma pequena coinjoin, com um UTXO cada na entrada e dois UTXOs cada na saída". Analisar esta transação do exterior não conduz à aplicação do CIOH, uma vez que a presença de duas saídas do mesmo montante sugere um padrão de coinjoin. De um ponto de vista externo, o CIOH não é, portanto, aplicável neste caso específico.

Esta interpretação é incorrecta, porque, como sabe, um UTXO foi enviado para Bob, o padeiro, as 2 entradas UTXO vieram de Alice, e ela recuperou 3 saídas de troca.

E o que é particularmente interessante na estrutura da transação da Stonewall é que, do ponto de vista de um observador externo, se assemelha em todos os aspectos a uma transação da Stonewall x2.

A transação Stonewall x2

O Stonewall x2 é outra forma específica de transação Bitcoin que também visa aumentar a confidencialidade do utilizador ao efetuar uma despesa, mas desta vez colaborando com uma terceira pessoa não envolvida nessa despesa. Este método funciona como uma pseudo-coinjoin entre dois participantes, ao mesmo tempo que efectua um pagamento a uma terceira pessoa.

O funcionamento da transação Stonewall x2 é relativamente simples: utilizamos um UTXO na nossa posse para efetuar o pagamento, e recorremos à ajuda de um terceiro que também contribui com um UTXO que lhe pertence. A transação termina com quatro outputs: dois deles em quantidades iguais, um destinado ao endereço do beneficiário, o outro a um endereço pertencente ao colaborador. Um terceiro UTXO é devolvido a um outro endereço pertencente ao colaborador, permitindo-lhe recuperar o montante inicial (uma ação neutra para ele, modulo os custos de mineração), e um último UTXO retorna a um endereço pertencente a nós, que constitui a troca de pagamento.

Assim, são definidos três papéis diferentes nas transacções Stonewall x2:

• O emitente, que efectua o pagamento efetivo ;
• O destinatário, que pode não ter conhecimento da natureza específica da transação e espera simplesmente o pagamento do remetente;
• O colaborador, que disponibiliza bitcoins para pôr em causa a análise da transação, recuperando a totalidade dos seus fundos no final (uma ação neutra para ele, modulo os custos de mineração).

Voltemos ao nosso exemplo com Alice, que está na padaria de Bob para comprar a sua baguete, que custa 4.000 sats. Ela quer pagar em bitcoins, mantendo um certo nível de confidencialidade relativamente ao seu pagamento. Por isso, chama o seu amigo Charles, que a vai ajudar neste processo.

Analisando esta transação, podemos ver que o Bob, o padeiro, recebeu efetivamente 4.000 sats como pagamento pela baguete. A Alice utilizou 10.000 sats como entrada e recuperou 6.000 sats como saída, ou seja, um saldo líquido de -4.000 sats, que corresponde ao preço da baguete. Quanto ao Carlos, deu 15.000 sats como entrada e recebeu duas saídas: uma de 4.000 sats e outra de 11.000 sats, o que dá um saldo de 0.

Neste exemplo, deixei intencionalmente de fora as taxas para facilitar a compreensão. Na realidade, as taxas de exploração mineira são geralmente partilhadas em partes iguais entre o emissor do pagamento e o contribuinte.

Quais são os objectivos de uma transação Stonewall x2?

Tal como a estrutura Stonewall, a estrutura Stonewall x2 acrescenta uma grande quantidade de entropia à transação e confunde a análise da cadeia. Vista de fora, esta transação pode ser interpretada como uma pequena união entre duas pessoas. Mas, na realidade, trata-se de um pagamento. Este método cria, por conseguinte, incertezas na análise da cadeia, ou conduz mesmo a falsas pistas.

Vejamos o exemplo de Alice, Bob, o padeiro, e Charles. A transação na cadeia de blocos teria o seguinte aspeto:

Um observador externo que se baseie na heurística da análise da cadeia comum poderá concluir erradamente que "Alice e Carlos efectuaram uma pequena coinjoin, com um UTXO cada na entrada e dois UTXOs cada na saída". Mais uma vez, analisar esta transação do exterior não leva à aplicação do ICOH, uma vez que a presença de duas saídas do mesmo montante sugere um padrão de coinjoin. De um ponto de vista externo, o CIOH não é, portanto, aplicável neste caso específico.

Esta interpretação é incorrecta, porque, como sabe, foi enviado um UTXO ao Bob padeiro, a Alice tem apenas uma saída de troca e o Carlos tem duas.

E, mais uma vez, o que é particularmente interessante na estrutura da transação Stonewall x2 é que, do ponto de vista de um observador externo, se assemelha em tudo a uma transação Stonewall.

Qual é a diferença entre Stonewall e Stonewall x2?

Uma transação StonewallX2 funciona exatamente como uma transação Stonewall, exceto que a primeira é colaborativa, enquanto a segunda não é. Como vimos, uma transação Stonewall x2 envolve a participação de um terceiro (Charles), que é externo ao pagamento, e que disponibilizará os seus bitcoins para aumentar a confidencialidade da transação. Numa transação Stonewall clássica, o papel do colaborador é assumido pelo remetente.

De um ponto de vista externo, o padrão de transação é exatamente o mesmo.

O facto de estas duas estruturas de transação partilharem exatamente o mesmo padrão significa que, mesmo que um observador externo consiga identificar um padrão "Stonewall(x2)", não terá toda a informação. Não será capaz de determinar qual dos dois UTXOs dos mesmos montantes corresponde ao pagamento. Além disso, não poderá determinar se as duas UTXOs com entradas provêm de duas pessoas diferentes (Stonewall x2) ou se pertencem a uma única pessoa que as fundiu (Stonewall).

Este último ponto deve-se ao facto de as transacções da Stonewall x2 seguirem exatamente o mesmo padrão das transacções da Stonewall. Visto de fora, e sem informação contextual adicional, é impossível diferenciar uma transação Stonewall de uma transação Stonewall x2. As primeiras não são transacções de colaboração, enquanto as segundas o são. Este facto acrescenta ainda mais dúvidas à análise de uma destas transacções.

Quando devem ser utilizadas as transacções Stonewall e Stonewall x2?

A lógica deve ser a seguinte quando se pretende utilizar uma ferramenta de confidencialidade para uma despesa:

• Como prioridade, podemos optar por fazer um payjoin;
• Se o comerciante não suportar payjoins, pode ser efectuada uma transação de colaboração com outra pessoa fora do pagamento utilizando a estrutura x2 da Stonewall;
• Se não conseguir encontrar ninguém para fazer uma transação Stonewall x2, pode fazer uma transação apenas Stonewall, que imitará o comportamento de uma transação Stonewall x2.

Como é que utilizo as transacções Stonewall e Stonewall x2?

As transacções Stonewall e Stonewall x2 estão disponíveis tanto na aplicação Samourai Wallet como no software Sparrow Wallet.

No entanto, tal como acontece com os payjoins, após a detenção dos fundadores da Samourai, as transacções Stonewall x2 só funcionam agora através da troca manual de PSBTs entre as partes envolvidas. Infelizmente, a troca automática via Soroban já não está disponível.

Também é possível efetuar este tipo de transação manualmente a partir de qualquer software de carteira Bitcoin.

No próximo capítulo, veremos outra técnica de confidencialidade relativamente desconhecida, mas que é muito útil como complemento ao que já estudámos.

https://planb.network/tutorials/privacy/on-chain/stonewall-033daa45-d42c-40e1-9511-cea89751c3d4

https://planb.network/tutorials/privacy/on-chain/stonewall-x2-05120280-f6f9-4e14-9fb8-c9e603f73e5b

Os ricochetes

A utilização de estruturas de transação Bitcoin que acrescentam ambiguidade à análise da cadeia, como a coinjoin, é particularmente benéfica para a proteção da privacidade. No entanto, como discutimos no capítulo sobre payjoins, as transacções coinjoin são naturalmente identificáveis na cadeia. Lembre-se da analogia que fizemos entre encriptação e coinjoins: quando um ficheiro é encriptado, um terceiro que descubra o ficheiro encriptado não pode aceder ao seu conteúdo, mas pode identificar claramente que o ficheiro foi modificado para esconder o seu conteúdo. O mesmo se aplica ao coinjoin: quando um analista examina uma transação coinjoin, embora não possa estabelecer ligações diretas entre inputs e outputs (e vice-versa), pode, no entanto, reconhecer que a transação observada é um coinjoin.

Dependendo da forma como pretende utilizar a sua peça após os ciclos de coinjoin, o facto de ter sido submetida a este processo pode ser problemático. Por exemplo, se tenciona vender a sua moeda numa plataforma de troca regulamentada, mas esta foi recentemente submetida a um coinjoin, a ferramenta de análise da cadeia da plataforma detectará este facto. A plataforma pode então recusar-se a aceitar o seu UTXO coinjoined, ou mesmo exigir-lhe uma explicação, com o risco de a sua conta ser suspensa ou os seus fundos congelados. Em certos casos, a plataforma pode também denunciar o seu comportamento às autoridades públicas (é, por exemplo, o que a TRACFIN exige às PSAN em França).

O que precisamos para evitar isso é de uma ferramenta capaz de apagar os traços do passado de uma moeda Bitcoin, a fim de restaurar alguma forma de fungibilidade. É precisamente este o objetivo do ricochete.

O que é um ricochete?

O ricochete é uma técnica que consiste em realizar várias transacções fictícias em relação a si próprio (sweep) para simular uma transferência de propriedade de bitcoin. Esta ferramenta difere das outras estruturas de transação que discutimos, na medida em que não ganha anonimato prospetivo, mas sim uma forma de anonimato retrospetivo. De facto, o ricochete esbate as especificidades que podem comprometer a fungibilidade de uma moeda Bitcoin devido ao seu passado.

Para suavizar a marca deixada por um evento passado numa moeda, como os ciclos de junção de moedas, o ricochete executa quatro transacções sucessivas em que o utilizador transfere fundos para si próprio em endereços diferentes.

Após esta sequência de transacções, a ferramenta de ricochete encaminha finalmente os bitcoins para o seu destino final, como uma plataforma de troca.

O objetivo é criar uma distância que afecte a fungibilidade da moeda, como uma transação de junção de moedas, e o ato final de despesa, que poderia rejeitar esta moeda devido ao seu passado. Assim, as ferramentas de análise em cadeia podem concluir que houve provavelmente uma mudança de propriedade após o evento e considerar esta moeda como fungível. No caso de um coinjoin, as ferramentas de análise da cadeia de blocos poderiam então assumir que não foi a mesma pessoa que enviou os bitcoins e efectuou o coinjoin e que, por conseguinte, não vale a pena tomar medidas contra o remetente.

Porque é que funciona?

Perante este método de ricochete, poder-se-ia imaginar que o software de análise de cadeias aprofundaria o seu exame para além de quatro ricochetes. No entanto, estas plataformas enfrentam um dilema na otimização do limiar de deteção. Têm de estabelecer um limite para o número de saltos após o qual aceitam que provavelmente ocorreu uma alteração de propriedade e que a ligação com um evento anterior (como uma coinjoin) deve ser ignorada.

No entanto, a fixação deste limiar é arriscada: cada extensão do número de saltos observados aumenta exponencialmente o volume de falsos positivos, ou seja, indivíduos erradamente marcados como participantes num evento, quando na realidade a operação foi efectuada por outra pessoa. Este cenário representa um grande risco para estas empresas, uma vez que os falsos positivos conduzem à insatisfação, o que pode levar os clientes afectados a procurar a concorrência. A longo prazo, um limiar de deteção demasiado elevado leva uma plataforma a perder mais clientes do que os seus concorrentes, o que pode ameaçar a sua viabilidade. Por conseguinte, é complicado para estas plataformas aumentar o número de devoluções observadas, sendo que 4 é frequentemente um número suficiente para contrariar as suas análises.

O fenómeno aqui observado é, de certa forma, análogo à teoria dos seis graus de separação.

A teoria dos seis graus de separação sugere que cada pessoa na Terra está ligada a qualquer outra por uma cadeia de relações que inclui, no máximo, seis intermediários. Bastaria, portanto, passar por uma série de seis pessoas, cada uma conhecendo pessoalmente a outra, para chegar a qualquer indivíduo no mundo.

No caso das transacções Bitcoin, encontramos um fenómeno semelhante. Ao rastrear um número suficiente de transacções de Bitcoin, deparamo-nos inevitavelmente com uma coinjoin. O método de ricochete tira partido deste princípio, utilizando um número de saltos superior ao que as plataformas de troca podem razoavelmente seguir. Se as plataformas decidirem rastrear mais transacções, é então possível simplesmente adicionar um salto extra para contornar esta medida.

Quando e como utilizar o ricochete?

O caso de utilização mais comum para o ricochete ocorre quando é necessário ocultar uma participação anterior numa coinjoin num UTXO de que é proprietário. Idealmente, é melhor evitar a transferência de bitcoins que tenham sido objeto de uma coinjoin para entidades regulamentadas. No entanto, no caso de não ter outra opção, particularmente na necessidade urgente de liquidar bitcoins em moeda estatal, o ricochete oferece uma solução eficaz.

Este método é eficaz não só para coinjoins, mas também para qualquer outra marca que possa comprometer a fungibilidade de uma peça.

A ideia deste método de ricochete partiu originalmente das equipas da Samourai Wallet, que o integraram na sua aplicação para automatizar o processo. O serviço não é gratuito na Samourai, uma vez que um ricochete envolve uma taxa de serviço de 100.000 sats, mais os custos de mineração. A sua utilização é, portanto, recomendada para transferências de montantes significativos.

A aplicação Samurai oferece duas variantes de ricochete:

• Ricochete reforçado, ou "entrega escalonada", que oferece a vantagem de repartir a taxa de serviço Samurai pelas cinco transacções sucessivas. Esta opção também garante que cada transação é transmitida num momento distinto e registada num bloco diferente, imitando o mais possível o comportamento de uma mudança de proprietário. Embora mais lento, este método é preferível para quem não tem pressa, pois maximiza a eficiência do ricochete reforçando a sua resistência à análise da cadeia;

• O método clássico de ricochete, que se destina a executar a operação com rapidez, difunde todas as transacções num intervalo de tempo reduzido. Este método oferece, por conseguinte, menos confidencialidade e menos resistência à análise do que o método reforçado. Só deve ser utilizado para envios urgentes.

Ricochetear significa simplesmente enviar bitcoins para si próprio. É perfeitamente possível fazer ricochete de bitcoins manualmente em qualquer software de carteira, sem usar uma ferramenta especializada. Tudo o que tem de fazer é transferir sucessivamente a mesma moeda para si próprio, usando um endereço novo e em branco de cada vez.

No próximo capítulo, analisamos diferentes técnicas de transferências secretas de propriedade. Estes métodos diferem radicalmente dos que analisámos até agora, tanto em termos de funcionamento como de resultados.

https://planb.network/tutorials/privacy/on-chain/ricochet-e0bb1afe-becd-44a6-a940-88a463756589

Transferências secretas de propriedade

Outra das técnicas de confidencialidade da Bitcoin é a transferência secreta de propriedade. Este método visa transferir a propriedade de Bitcoins de uma pessoa para outra, e vice-versa, sem que a transação seja explicitamente visível na cadeia de blocos. Vamos dar uma olhada nas diferentes técnicas disponíveis, juntamente com suas vantagens e desvantagens.

A troca de moedas

O Coinwap baseia-se num conceito relativamente simples: utiliza contratos inteligentes para facilitar a transferência de propriedade de bitcoin entre dois utilizadores, sem necessidade de confiança e sem que esta transferência seja explicitamente visível na cadeia de blocos.

Imaginemos um exemplo ingénuo com Alice e Bob. Alice possui 1 BTC protegido com uma chave privada A e Bob também possui 1 BTC protegido com uma chave privada B. Teoricamente, poderiam trocar as suas chaves privadas através de um canal de comunicação externo para efetuar uma transferência secreta.

No entanto, este método ingénuo apresenta um risco elevado em termos de confiança. Nada impede que Alice guarde uma cópia da chave privada de A após a troca e a utilize mais tarde para roubar os bitcoins, quando a chave estiver nas mãos de Bob.

Além disso, não existe qualquer garantia de que Alice não receba a chave privada de Bob B e nunca transmita a sua chave privada A em troca. Esta troca depende, portanto, de uma confiança excessiva entre as partes e é ineficaz para garantir uma transferência secreta segura de propriedade.

Para resolver estes problemas e permitir trocas entre partes que não confiam umas nas outras, vamos utilizar sistemas de contratos inteligentes. Um contrato inteligente é um programa que é executado automaticamente quando são cumpridas condições predefinidas. No nosso caso, isto garante que a troca de propriedade é efectuada automaticamente, sem necessidade de confiança mútua.

Isto pode ser conseguido utilizando HTLC (Hash Time-Locked Contracts) ou PTLC (Point Time-Locked Contracts). Estes dois protocolos funcionam de forma semelhante, utilizando um sistema de bloqueio de tempo que assegura que a troca é concluída com êxito ou cancelada na totalidade, protegendo assim a integridade dos fundos de ambas as partes. A principal diferença entre o HTLC e o PTLC é que o HTLC utiliza hashes e pré-imagens para proteger a transação, enquanto o PTLC utiliza assinaturas de adaptadores.

Num cenário de troca de moedas utilizando HTLC ou PTLC entre Alice e Bob, a troca tem lugar de forma segura: ou é bem sucedida e cada um recebe as BTC do outro, ou falha e cada um mantém as suas próprias BTC. Isto torna impossível que uma das partes faça batota ou roube as BTC da outra.

O HTLC é também o mecanismo utilizado para encaminhar de forma segura os pagamentos através dos canais bidireccionais da Lightning Network A utilização de assinaturas de adaptadores é particularmente interessante neste contexto, pois permite dispensar os scripts tradicionais (um mecanismo por vezes designado por "scripts sem scripts"). Esta caraterística permite reduzir os custos associados ao intercâmbio. Outra grande vantagem das Assinaturas de Adaptadores é que não requerem a utilização de um hash comum para ambas as partes da transação, evitando assim a necessidade de revelar uma ligação direta entre elas em certos tipos de trocas.

Assinaturas de adaptadores

As assinaturas adaptadoras são um método criptográfico que integra uma assinatura válida com uma assinatura adicional, designada por "assinatura adaptadora", para revelar dados secretos. Este mecanismo foi concebido de forma a que o conhecimento de 2 dos 3 elementos seguintes: a assinatura válida, a assinatura adaptadora e o segredo, nos permita deduzir o terceiro elemento em falta. Uma propriedade interessante deste método é que, se conhecermos a assinatura do adaptador do nosso par e o ponto específico na curva elíptica associado ao segredo utilizado para calcular essa assinatura do adaptador, podemos derivar a nossa própria assinatura do adaptador que será compatível com esse mesmo segredo, sem nunca ter acesso direto ao próprio segredo.

Numa troca de moedas, a utilização de assinaturas de adaptador permite a divulgação simultânea de duas informações sensíveis entre os participantes, evitando assim a necessidade de confiança mútua. Vamos dar um exemplo para ilustrar este processo com Alice e Bob, que desejam trocar a posse de 1 BTC cada, mas não confiam um no outro. Utilizam Assinaturas de Adaptador para eliminar a necessidade de confiarem um no outro nesta troca. Eis como o fazem:

• Alice inicia a troca criando uma transação m_A que envia 1 BTC a Bob. Ela gera uma assinatura s_A, que valida esta transação, utilizando a sua chave privada p_A (P_A = p_A \cdot G), um nonce n_A (N_A = n_A \cdot G) e um segredo t (T = t \cdot G) :

s_A = n_A + t + H(N_A + T \paralelo P_A \paralelo m_A) \cdot p_A

• Alice calcula a assinatura do adaptador s_A' subtraindo o segredo t da sua assinatura verdadeira s_A :

s_A' = s_A - t

• Alice envia a Bob o seu adaptador de assinatura s'_A, a sua transação não assinada m_A, o ponto correspondente ao segredo (T) e o ponto correspondente ao nonce (N_A). Estes elementos constituem aquilo a que se chama um "adaptador". É importante notar que, apenas com esta informação, Bob não consegue recuperar o BTC de Alice.
• No entanto, Bob pode verificar se Alice não o está a tentar roubar. Para isso, ele verifica se a assinatura do adaptador de Alice s_A' corresponde realmente à transação proposta m_A. Se a seguinte equação estiver correta, então ele pode ter a certeza de que o adaptador de assinatura de Alice é válido:

s_A' \cdot G = N_A + H(N_A + T \paralelo P_A \paralelo m_A) \cdot P_A

• Esta verificação dá a Bob garantias suficientes de que pode prosseguir a troca com toda a confiança. Em seguida, cria a sua própria transação m_B, destinada a enviar 1 BTC a Alice, e gera a sua assinatura adaptadora s_B', que também estará ligada ao mesmo segredo t. Nesta fase, apenas Alice conhece o valor de t; Bob apenas conhece o ponto correspondente T que Alice lhe transmitiu:

s_B' = n_B + H(N_B + T \paralelo P_B \paralelo m_B) \cdot p_B

• Bob envia a Alice a sua assinatura de adaptador s_B', a sua transação não assinada m_B, bem como o ponto correspondente ao segredo (T) e o ponto correspondente ao nonce (N_B). Alice, que conhece o segredo t, pode agora combinar a assinatura adaptadora de Bob s_B' com este segredo para gerar uma assinatura válida s_B para a transação m_B que lhe transferirá as BTC de Bob:

s_B = s_B' + t

(s_B' + t) \cdot G = N_B + T + H(N_B + T \paralelo P_B \paralelo m_B) \cdot P_B

• Alice transmite esta transação assinada m_B na blockchain da Bitcoin para recuperar as BTC prometidas por Bob. Quando Bob vê esta transação na cadeia de blocos, pode extrair a assinatura s_B = s_B' + t. Com esta informação, Bob consegue então isolar o famoso segredo t de que precisava:

t = (s_B' + t) - s_B' = s_B - s_B'

• E este segredo t era o único elemento que faltava para Bob gerar a assinatura válida s_A a partir da assinatura adaptadora de Alice s_A'. Esta assinatura valida a transação m_A, que envia um BTC da Alice para o Bob. Bob calcula então s_A e transmite a transação m_A na cadeia de blocos:

s_A = s_A' + t

(s_A' + t) \cdot G = N_A + T + H(N_A + T \paralelo P_A \paralelo m_A) \cdot P_A

Vamos resumir como funciona uma assinatura de adaptador num coinswap. Inicialmente, Alice envia a Bob uma transação não assinada acompanhada de um adaptador, permitindo a Bob verificar que o segredo revelado mais tarde lhe dará acesso a bitcoins. Em troca, Bob envia a Alice a sua própria transação não assinada e o seu adaptador. Alice pode então finalizar a transação de Bob e recuperar os bitcoins transmitindo uma transação válida graças ao segredo. Quando esta transação é publicada na cadeia de blocos, Bob tem a capacidade de extrair o segredo e, assim, desbloquear a transação de Alice. Consequentemente, se Alice iniciar uma transferência da bitcoin de Bob, Bob pode, por sua vez, aceder à bitcoin de Alice sem necessidade de confiança mútua.

Note-se que as trocas de moedas foram propostas pela primeira vez por [Gregory Maxwell em outubro de 2013 no BitcoinTalk] (https://bitcointalk.org/index.php?topic=321228.0).

Troca atómica

De forma semelhante ao coinswap, e utilizando os mesmos tipos de contratos inteligentes, é também possível realizar atomic swaps. Um atomic swap permite uma troca direta de diferentes criptomoedas, como o BTC e o XMR, entre dois utilizadores sem necessidade de confiança ou de intervenção de um intermediário. Estas trocas são designadas "atómicas" porque têm apenas dois resultados possíveis: ou a troca é bem sucedida e ambas as partes ficam satisfeitas, ou falha e cada uma mantém as suas criptomoedas originais, eliminando a necessidade de confiar na outra parte.

O atomic swap e o coinswap partilham um método de funcionamento semelhante e oferecem as mesmas vantagens e desvantagens em termos de confidencialidade. Com efeito, do ponto de vista da Bitcoin, um atomic swap é comparável a um coinswap realizado em duas fases. Primeiro, trocamos as nossas BTC por outra criptomoeda, depois esta criptomoeda pode ser trocada por outras BTC. No final, recuperamos as BTC de outro utilizador. É por isso que, na análise das questões de confidencialidade, agrupo estes dois protocolos na categoria de trocas secretas proprietárias.

No entanto, tenha em atenção que, ao contrário do coinswap, o atomic swap pode ter desequilíbrios em termos de liquidez disponível, particularmente nas bolsas BTC/XMR. Geralmente é mais fácil trocar bitcoins por altcoins, uma vez que existe uma forte procura de bitcoins, o que mantém os prémios baixos para esta direção de conversão. No entanto, a troca de altcoins por BTC pode ser mais complexa devido à menor procura, resultando frequentemente em prémios muito elevados.

Finalmente, quando uma troca atómica envolve bitcoins onchain e bitcoins na rede Lightning, falamos de uma "troca submarina".

É realmente útil?

As transferências secretas de propriedade, como as trocas de moedas e as trocas atómicas, têm a vantagem de enganar a heurística da análise em cadeia. Estes métodos podem sugerir que as transacções envolvem o mesmo utilizador, quando a propriedade real mudou de mãos. No entanto, a principal desvantagem destes métodos é o facto de serem muito arriscados sem a utilização de uma técnica adicional para quebrar o histórico da moeda.

Com efeito, quando Alice realiza uma troca de moedas ou uma troca atómica com Bob, troca a posse das suas bitcoins com as de Bob. No caso de uma troca atómica, a troca inclui uma altcoin, mas o princípio permanece o mesmo. Assim, a Alice acaba por ficar com a moeda B e o Bob com a moeda A. Isto acrescenta dúvidas à análise da cadeia, mas o historial das moedas continua a ser rastreável. Se um analista examinar a parte A, pode rastrear as actividades anteriores de Alice, e vice-versa para a parte B.

Do ponto de vista da Alice, o risco é que o historial da moeda B possa ser considerado suspeito por certas entidades. Se, por exemplo, Bob tivesse adquirido a moeda B através de um ato criminoso como a pirataria informática, a moeda permaneceria ligada às suas actividades ilegais. Alice poderia então encontrar-se na posse de uma moeda que não poderia transferir para plataformas de câmbio regulamentadas sem correr o risco de ver os seus fundos congelados, ou mesmo de ser acusada dos crimes de Bob, apesar de não ter nada a ver com eles.

Inevitavelmente, métodos de confidencialidade como o coinswap ou o atomic swap são preferidos pelos criminosos cujos fundos estão sob vigilância das autoridades. Estes protocolos permitem-lhes dispor dos seus bitcoins sob vigilância em troca de bitcoins perfeitamente fungíveis. Permitem-lhes também criar uma manobra de diversão, orientando as autoridades para outros utilizadores. Portanto, há um duplo objetivo para estas pessoas.

Com o coinjoin, mesmo que a sua moeda seja misturada com bitcoins monitorizadas, o histórico da moeda é quebrado, proporcionando uma forma de negação plausível que não existe em protocolos de transferência de propriedade secretos como o coinswap ou o atomic swap.

Se Alice quiser evitar qualquer risco, terá necessariamente de utilizar um método para quebrar o historial da moeda B, tal como passá-la através de coinjoins. Isto levanta uma questão sobre a utilidade de combinar a transferência secreta de propriedade e o coinjoin. O coinjoin, ao quebrar o historial de uma moeda, já oferece um nível suficiente de confidencialidade à Alice. Assim, a minha opinião é que, se Alice pretende proteger a sua privacidade, seria mais sensato proceder diretamente a uma coinjoin em vez de efetuar um coinswap seguido de uma coinjoin.

Para que os métodos secretos de transferência de propriedade sejam verdadeiramente eficazes e evitem o risco de associar o historial de um utilizador A a um utilizador B, seria paradoxalmente necessário que a sua utilização fosse amplamente conhecida. Se o coinswap for utilizado maciçamente e as autoridades tiverem conhecimento desta prática comum, então poderá ser estabelecida uma forma plausível de negação. No entanto, enquanto a utilização destas transferências for marginal, penso que estes métodos continuarão a ser demasiado arriscados para os utilizadores.

Até agora, estudámos principalmente os métodos de confidencialidade ao nível das próprias transacções. No próximo capítulo, analisaremos as questões ao nível da rede e da disseminação das transacções.

Privacidade na rede P2P

Na Parte 4, discutimos a importância de utilizar um nó completo para proteger a confidencialidade das suas transacções. No entanto, é importante entender que seu nó pode estar sujeito a ataques que buscam extrair informações sobre suas atividades. Neste capítulo, portanto, veremos as várias medidas que podem ser tomadas para proteger sua privacidade, não no nível das transações em si ou dos fluxos de bitcoin, mas no nível da rede.

Dente-de-leão

Uma forma de evitar os vários ataques de desanonimização é usar a proposta Dandelion. Esse protocolo de broadcast foi formalizado no BIP156, mas nunca foi implementado no Bitcoin.

A ideia por detrás do Dandelion é melhorar a confidencialidade do encaminhamento de transacções na rede Bitcoin para combater várias formas de ataque. O seu principal objetivo é ocultar o nó de origem que inicialmente difunde uma transação na rede. A revelação deste nó pode tornar possível ligar uma transação Bitcoin a um endereço IP específico (se o nó operar na clearnet), o que pode constituir um ponto de entrada para a análise da cadeia.

Esta associação entre a atividade na Bitcoin e um endereço IP representa um risco considerável para a confidencialidade do utilizador. De facto, muitas entidades estão em posição de associar facilmente um endereço IP a uma identidade pessoal. Isso inclui governos e provedores de serviços de Internet. Além disso, esta informação pode tornar-se acessível ao público, por exemplo, se o seu endereço IP e dados pessoais forem divulgados quando a base de dados de um sítio Web for pirateada.

No funcionamento clássico do Bitcoin, as transacções criadas por um utilizador no seu software de carteira são transmitidas ao seu nó pessoal. Este nó transmitirá imediatamente a nova transação a todos os pares aos quais está ligado.

Estes pares verificam então a transação para garantir que está em conformidade com as regras de consenso e de normalização local. Uma vez validada, cada par, por sua vez, reencaminha a transação para os seus pares, e assim sucessivamente.

Esta distribuição das transacções que aguardam integração num bloco é bastante equilibrada e estatisticamente previsível. Esta fraqueza pode ser explorada por nós espiões cúmplices, que colaboram para monitorizar e analisar a rede, de modo a identificar o primeiro nó a transmitir uma transação. Se um observador conseguir localizar o nó de origem, pode assumir que a transação teve origem no operador desse nó. Este tipo de observação pode ser utilizado para associar transacções normalmente anónimas a endereços IP específicos.

O objetivo da BIP156 é resolver este problema. Para tal, introduz uma fase adicional na disseminação de uma nova transação para preservar o anonimato antes de uma propagação pública alargada. O Dandelion utiliza primeiro uma fase de "caule" em que a transação é enviada através de um caminho aleatório de nós.

A transação é então transmitida para toda a rede durante a fase de "Fluff".

O caule e a fase "Fluff" são referências ao comportamento da propagação da transação na rede, que se assemelha à forma e à evolução de um dente-de-leão ("Dandelion" em inglês).

Assim, os nós espiões podem potencialmente rastrear a transação até ao nó que iniciou a fase de "Fluff" (a difusão massiva), mas esse nó não é o que transmitiu a transação primeiro, pois a recebeu do último nó do caule. Se os nós espiões não conseguirem rastrear o caule, também não poderão identificar o nó de origem.

Mesmo na presença de nós espiões durante a fase de caule, permanece sempre uma dúvida, porque assim que encontram um nó honesto no grafo de difusão, os espiões não conseguem determinar se esse nó é a fonte original ou simplesmente um intermediário.

Este método de encaminhamento desfoca o rasto que conduz ao nó de origem, dificultando o rastreio de uma transação através da rede até à sua origem. O Dandelion melhora assim a confidencialidade, limitando a capacidade dos adversários de desanonimizarem a rede. Este método é ainda mais eficaz quando, durante a fase de "stemming", a transação atravessa um nó que encripta as suas comunicações de rede, como acontece com o Tor ou o P2P Transport V2.

O BIP156 não foi integrado no Bitcoin Core e está atualmente classificado como "rejeitado". Uma das principais preocupações com este protocolo é que, durante a fase de haste, as transacções devem ser retransmitidas através de nós intermediários antes de serem verificadas. Como vimos, no modelo normal do Bitcoin, cada nó verifica primeiro a transação antes de a transmitir aos seus pares. Se uma transação não estiver de acordo com as regras de consenso do nó ou com as regras de padronização local, o nó a ignora e não a distribui. Este processo é importante para combater os ataques DoS, uma vez que apenas as transacções válidas são transmitidas para toda a rede. As transacções inválidas, potencialmente geradas em massa para sobrecarregar a rede, são paradas no primeiro nó encontrado e não se propagam. O principal risco do Dandelion é que este novo protocolo possa introduzir novos vectores de ataques DoS, permitindo que transacções inválidas sejam difundidas em parte da rede.

Transporte P2P V2

O transporte P2P V2 é outro protocolo de rede apresentado no BIP324. É uma nova versão do protocolo de transporte P2P da Bitcoin que incorpora encriptação oportunista para melhorar a confidencialidade e a segurança das comunicações entre nós.

Esta melhoria foi concebida para resolver vários problemas da versão de base do protocolo P2P. Por um lado, torna os dados trocados indistinguíveis de outros tipos de dados que circulam na Internet para um observador passivo. O principal objetivo é evitar que governos, ISPs e fornecedores de VPN monitorizem massivamente os utilizadores de Bitcoin. Isto também torna mais difícil para estas entidades determinar se um utilizador da Internet é também um utilizador de Bitcoin, ou seja, se ele ou ela está a operar um nó completo.

O P2P V2 também ajuda a reduzir o risco de censura e de ataques, detectando padrões específicos nos pacotes de dados. Complica e torna mais dispendiosa a execução de vários tipos de ataques Sybil a nível da rede. Um ataque Sybil ocorre quando um ator cria várias identidades falsas para obter uma vantagem injusta. No contexto da rede Bitcoin, isto manifesta-se frequentemente quando um ator controla um grande número de nós completos e os utiliza de forma agressiva para multiplicar as ligações. Os ataques Sybil podem ser passivos, para recolher informações e comprometer a confidencialidade do utilizador, ou activos, sob a forma de ataques Eclipse. Estes últimos isolam um nó específico do resto da rede, censurando o utilizador ou alterando os dados que este recebe. Por último, o P2P V2 também torna os ataques Man-In-The-Middle (MITM) mais dispendiosos e mais fáceis de detetar.

A encriptação implementada pelo P2P V2 não inclui autenticação, de modo a não acrescentar complexidade desnecessária ou comprometer o facto de a ligação à rede permanecer sem permissão. No entanto, este novo protocolo de transporte P2P oferece uma melhor segurança contra ataques passivos e torna os ataques activos consideravelmente mais dispendiosos e detectáveis. A introdução de um fluxo de dados pseudo-aleatório nas mensagens da rede torna mais difícil para os atacantes censurar ou manipular as comunicações.

O transporte P2P V2 foi incluído como uma opção (desativado por defeito) na versão 26.0 do Bitcoin Core, implementada em dezembro de 2023. Ele foi então habilitado por padrão na versão 27.0 de abril de 2024. Ele pode ser modificado com a opção v2transport= no arquivo de configuração.

Tor

Outra solução simples para evitar o risco de perda de confidencialidade de um nó de rede é executá-lo inteiramente sob o Tor.

Tor é uma rede de servidores de retransmissão (nós) que torna anónima a origem das ligações TCP na Internet. Funciona através do encapsulamento de dados em várias camadas de encriptação. Cada nó de retransmissão remove uma camada para revelar o endereço do nó seguinte, até chegar ao destino final. A rede Tor garante o anonimato ao impedir que os nós intermediários conheçam a origem e o destino dos dados, tornando muito difícil para um observador rastrear a atividade de um utilizador.

Tor não só encripta dados, mas também mascara a origem e o destino das comunicações. Ao usar Tor para comunicações a partir de seu nó pessoal, você reforça a confidencialidade de suas transações: seu ISP não pode descriptografar comunicações, e outros nós na rede Bitcoin não podem identificar o endereço IP do nó de origem. Além disso, Tor também esconde o seu próprio uso de Bitcoin do seu ISP.

O principal risco com este método é que o Tor é um protocolo independente do Bitcoin. Se você tem um nó Bitcoin rodando sob Tor e Tor pára de funcionar, então seu nó Bitcoin não será mais capaz de se comunicar.

Além disso, é importante notar que as comunicações no Tor são mais lentas. Essa latência é particularmente irritante durante o lançamento inicial de um nó, já que o IBD (Initial Block Download) requer muita comunicação. Como resultado, sua sincronização inicial com a rede Bitcoin pode levar muito mais tempo usando Tor. Também é possível executar o IBD na clearnet e depois ativar o Tor como um segundo passo. Embora este método revele a existência do seu nó Bitcoin ao seu ISP, ele protege suas informações pessoais de transação uma vez que você mude para o Tor.

Depois de explorar os vários métodos de confidencialidade ao nível da rede, nos próximos capítulos gostaria também de vos apresentar duas soluções elegantes para evitar a reutilização de endereços: BIP47 e Silent Payments.

BIP47 e códigos de pagamento reutilizáveis

Como vimos na parte 3, a reutilização de endereços é um sério obstáculo à confidencialidade do utilizador no protocolo Bitcoin. Para mitigar esses riscos, é altamente recomendável gerar um endereço de recebimento em branco para cada novo pagamento recebido em uma carteira. Embora a geração de um novo endereço seja agora simplificada pelo uso de software moderno e carteiras hierárquicas determinísticas, esta prática pode parecer contra-intuitiva.

No sistema bancário tradicional, por exemplo, estamos habituados a partilhar o nosso IBAN, que permanece sempre o mesmo. Depois de o darmos a alguém, essa pessoa pode enviar-nos vários pagamentos sem ter de voltar a interagir connosco. Os neobancos também oferecem possibilidades mais modernas, como a utilização de endereços de correio eletrónico únicos no PayPal ou RevTags no Revolut. Mesmo fora da esfera financeira, os nossos identificadores quotidianos, como o endereço postal, o número de telefone e o endereço de correio eletrónico, também são únicos e permanentes. Não temos de os renovar para cada nova interação.

No entanto, a Bitcoin funciona de forma diferente: deve ser gerado um novo endereço de receção para cada transação recebida. Este compromisso entre facilidade de utilização e confidencialidade remonta às próprias origens do Livro Branco da Bitcoin. Desde a publicação da primeira versão do seu documento, no final de 2008, Satoshi Nakamoto já nos alertava para este risco:

**Como firewall adicional, pode ser utilizado um novo par de chaves para cada transação para as manter desvinculadas de um proprietário comum

Há muitas formas de receber vários pagamentos num único identificador sem ter de reutilizar um endereço. Cada uma delas tem as suas próprias vantagens e desvantagens. Entre esses métodos está o BIP47, uma proposta desenvolvida por Justus Ranvier e publicada em 2015. Esta proposta visa criar códigos de pagamento reutilizáveis que permitam efetuar várias transacções contra a mesma pessoa, evitando a reutilização de endereços. Em suma, o BIP47 visa oferecer um sistema de pagamento tão intuitivo como um identificador único, preservando a confidencialidade das transacções.

O BIP47 não melhora diretamente a confidencialidade do utilizador, uma vez que um pagamento BIP47 oferece o mesmo nível de confidencialidade que uma transação Bitcoin clássica utilizando endereços em branco. No entanto, torna a utilização da Bitcoin mais cómoda e intuitiva, uma facilidade que normalmente comprometeria a confidencialidade. Graças ao BIP47, esta facilidade de utilização atinge o mesmo nível de confidencialidade que uma transação clássica. É por isso que a BIP47 é uma ferramenta tão valiosa para preservar a privacidade.

Inicialmente, o BIP47 foi proposto para integração no Bitcoin Core, mas nunca chegou a ser implementado. No entanto, alguns aplicativos de software optaram por implementá-lo por conta própria. Por exemplo, as equipas da Samourai Wallet desenvolveram a sua própria implementação do BIP47 chamada "PayNym".

Princípio geral do BIP47 e PayNym

O objetivo do BIP47 é permitir receber um grande número de pagamentos sem reutilizar endereços. Baseia-se na utilização de um código de pagamento reutilizável, que permite a diferentes emissores enviar vários pagamentos para um único código pertencente a outro utilizador. Assim, o destinatário não tem de fornecer um novo endereço em branco para cada transação, o que facilita muito as trocas, preservando a confidencialidade.

Assim, um utilizador pode partilhar o seu código de pagamento com toda a liberdade, seja nas redes sociais ou no seu sítio Web, sem correr o risco de perder a confidencialidade, ao contrário do que acontece com um endereço de destinatário ou uma chave pública convencionais.

Para efetuar uma transação, ambas as partes necessitam de uma carteira Bitcoin com uma implementação BIP47, como a PayNym na Samurai Wallet ou na Sparrow Wallet. A utilização conjunta dos seus códigos de pagamento cria um canal secreto entre eles. Para estabelecer este canal de forma eficaz, o emissor deve realizar uma transação específica na cadeia de blocos Bitcoin, conhecida como "transação de notificação" (mais sobre isto adiante).

A combinação dos códigos de pagamento dos dois utilizadores gera segredos partilhados, que por sua vez criam um grande número de endereços de receção Bitcoin únicos (exatamente 2^32, ou seja, cerca de 4 mil milhões). Desta forma, os pagamentos efectuados através do BIP47 não são realmente endereçados ao código de pagamento em si, mas sim a endereços de receção clássicos derivados dos códigos de pagamento dos utilizadores envolvidos.

O código de pagamento funciona assim como um identificador virtual derivado da semente da carteira. Na estrutura de derivação hierárquica da carteira, o código de pagamento está posicionado no nível 3, ou seja, no nível da conta.

O objetivo de derivação para o BIP47 é identificado pelo índice 47' (0x8000002F), referindo-se ao BIP47. Um exemplo de um caminho de derivação para um código de pagamento reutilizável seria o seguinte:

m/47'/0'/0'/

Para dar uma ideia de como é um código de pagamento, eis o meu:

PM8TJSBiQmNQDwTogMAbyqJe2PE2kQXjtgh88MRTxsrnHC8zpEtJ8j7Aj628oUFk8X6P5rJ7P5qDudE4Hwq9JXSRzGcZJbdJAjM9oVQ1UKU5j2nr7VR5

Este código também pode ser codificado como um código QR, para facilitar a comunicação, tal como um endereço de receção convencional.

Quanto aos PayNym Bots, os robots por vezes vistos no Twitter, são representações visuais do código de pagamento, criados pela Samourai Wallet. São gerados através de uma função hash, o que lhes confere um carácter quase único. Têm a forma de uma pequena sequência de caracteres que começa por + :

+throbbingpond8B1
+twilightresonance487
+billowingfire340

Estes avatares também podem ser representados como imagens:

Embora estes robôs não tenham qualquer funcionalidade técnica específica no âmbito da estrutura BIP47, desempenham um papel na facilitação da interação com o utilizador, oferecendo uma identidade visual facilmente reconhecível.

Nas secções seguintes deste capítulo dedicadas ao BIP47, analisaremos em pormenor o seu funcionamento, com especial ênfase nos métodos criptográficos utilizados. Para compreender estas explicações algo técnicas, é essencial compreender primeiro a estrutura das carteiras HD, os procedimentos de derivação de chaves e os fundamentos da criptografia de curva elíptica. Se quiser aprofundar estes conceitos, está disponível outro curso de formação gratuito na Rede Plan ₿ :

https://planb.network/courses/46b0ced2-9028-4a61-8fbc-3b005ee8d70f

Aconselho-o a segui-las, porque a compreensão do funcionamento técnico do BIP47 facilitará muito a compreensão de outras propostas semelhantes, que discutiremos nos capítulos seguintes

O código de pagamento reutilizável

Como mencionado anteriormente, o código de pagamento reutilizável está localizado na profundidade 3 da carteira HD, o que o torna comparável a um xpub, tanto em termos da sua posição na estrutura da carteira como do seu papel.

O código de pagamento de 80 bytes decompõe-se da seguinte forma:

• Byte 0: A versão**. Para a primeira versão da BIP47, este byte é definido como 0x01 ;
• Byte 1: O campo dos bits**. Este espaço é reservado para integrar indicações adicionais para utilizações específicas. Para uma utilização clássica do PayNym, este byte é definido como 0x00 ;
• O byte 2: A paridade de y**. Este byte é 0x02 ou 0x03, indicando se a ordenada da chave pública é par ou ímpar, uma vez que é utilizada uma chave pública comprimida;
• Do byte 3 ao byte 34: O valor de x**. Estes bytes representam a abscissa da chave pública. A concatenação de x e a paridade de y formam a chave pública comprimida completa;
• Do byte 35 ao byte 66: O código da cadeia**. Este espaço contém o código da cadeia de caracteres associado à chave pública;
• Do byte 67 ao byte 79: O preenchimento**. Este espaço é destinado a possíveis evoluções futuras. Para a versão atual, simplesmente colocamos zeros aqui para atingir o tamanho de 80 bytes necessário para a saída OP_RETURN.

Eis a representação hexadecimal do meu código de pagamento reutilizável já apresentado na secção anterior:

0x010002a0716529bae6b36c5c9aa518a52f9c828b46ad8d907747f0d09dcd4d9a39e97c3c5f37c470c390d842f364086362f6122f412e2b0c7e7fc6e32287e364a7a36a00000000000000000000000000

Em seguida, o byte de prefixo P deve ser acrescentado no início para indicar claramente que se trata de um código de pagamento. Este byte é representado por 0x47 :

0x47010002a0716529bae6b36c5c9aa518a52f9c828b46ad8d907747f0d09dcd4d9a39e97c3c5f37c470c390d842f364086362f6122f412e2b0c7e7fc6e32287e364a7a36a00000000000000000000000000

Por último, para garantir a integridade do código de pagamento, é efectuado um cálculo da soma de controlo utilizando o HASH256, que consiste num duplo hash utilizando a função SHA256. Os quatro primeiros bytes deste hash são depois concatenados no final do código de pagamento:

0x47010002a0716529bae6b36c5c9aa518a52f9c828b46ad8d907747f0d09dcd4d9a39e97c3c5f37c470c390d842f364086362f6122f412e2b0c7e7fc6e32287e364a7a36a00000000000000000000000000567080c4

Uma vez concluídos estes passos, o código de pagamento está pronto. Só falta convertê-lo para a base 58 para obter a versão final:

PM8TJSBiQmNQDwTogMAbyqJe2PE2kQXjtgh88MRTxsrnHC8zpEtJ8j7Aj628oUFk8X6P5rJ7P5qDudE4Hwq9JXSRzGcZJbdJAjM9oVQ1UKU5j2nr7VR5

No processo de criação do código de pagamento, utilizamos uma chave pública comprimida e um código de cadeia. Ambos são derivados de forma determinística e hierárquica a partir da semente da carteira. O caminho de derivação utilizado para o efeito é :

m/47'/0'/0'/

Em termos concretos, para gerar a chave pública comprimida e o código string associado ao código de pagamento reutilizável, começamos por calcular a chave privada mestra a partir da semente da carteira. De seguida, derivamos um par de chaves filhas utilizando o índice 47 + 2^31 (derivação reforçada). Seguem-se mais duas derivações sucessivas de pares de chaves filhas, cada uma usando o índice 2^31 (derivação reforçada).

Troca de chaves Diffie-Hellman em curvas elípticas (ECDH)

O protocolo criptográfico que está no centro da BIP47 é conhecido pelo acrónimo ECDH, que significa Elliptic-Curve Diffie-Hellman. Este método é uma variante do método original de troca de chaves Diffie-Hellman.

Introduzido em 1976, Diffie-Hellman é um protocolo de acordo de chaves que permite que duas partes, cada uma equipada com um par de chaves (pública e privada), cheguem a acordo sobre um segredo comum, mesmo quando comunicam apenas através de um canal público e não seguro.

Este segredo partilhado (neste caso, a chave azul) pode então ser utilizado para outras operações. Normalmente, este segredo partilhado pode ser utilizado para encriptar e desencriptar uma comunicação numa rede não segura:

Para o conseguir, Diffie-Hellman utiliza aritmética modular para calcular o segredo partilhado. Eis como funciona em termos leigos:

• Alice e Bob chegam a acordo sobre uma cor comum, neste caso o amarelo, que é um dado público (os atacantes conhecem esta cor);
• A Alice seleciona uma cor secreta, neste caso o vermelho, e mistura as duas para obter o laranja;
• O Bob também escolhe uma cor secreta, neste caso o azul, e mistura-a com o amarelo para obter o verde;
• De seguida, trocam as cores resultantes, laranja e verde. Esta troca pode ter lugar numa rede insegura e ser observada por atacantes;
• Ao misturar o verde do Bob com a sua própria cor secreta, a Alice produz o castanho;
• O Bob, fazendo o mesmo com o laranja e o azul secreto da Alice, também obtém o castanho.

Nesta popularização, a cor castanha representa o segredo partilhado por Alice e Bob. Imagine que, na realidade, é impossível para o atacante separar as cores laranja e verde, de modo a encontrar as cores secretas de Alice ou Bob.

Agora vamos ver como é que este protocolo funciona na realidade, não com analogias de cores, mas utilizando números reais e aritmética modular!

Antes de entrarmos nos mecanismos de Diffie-Hellman, deixem-me recordar-vos brevemente dois conceitos matemáticos essenciais de que vamos precisar:

• Um número primo é um número natural que tem apenas dois divisores: 1 e ele próprio. Por exemplo, 7 é um número primo porque só pode ser dividido por 1 e 7. Por outro lado, 8 não é um número primo, pois é divisível por 1, 2, 4 e 8. Tem, portanto, quatro divisores inteiros positivos em vez de dois;
• O módulo (conhecido por mod ou \%) é uma operação matemática que, entre dois números inteiros, devolve o resto da divisão euclidiana do primeiro pelo segundo. Por exemplo, 16\bmod 5 =1$.

A troca de chaves Diffie-Hellman entre Alice e Bob ocorre da seguinte forma:

• Alice e Bob concordam em dois números comuns: p e g. p é um número primo, e quanto maior o número, mais seguro será o Diffie-Hellman. g é uma raiz primitiva de p. Estes dois números podem ser comunicados de forma clara numa rede não segura. Representam o equivalente à cor amarela na popularização anterior. Por isso, é importante que Alice e Bob usem exatamente os mesmos valores para p e g.
• Uma vez definidos estes parâmetros, a Alice e o Bob escolhem um número aleatório secreto. A Alice chama ao seu número aleatório secreto a (equivalente à cor vermelha) e o Bob chama ao seu b (equivalente à cor azul). Estes números devem permanecer secretos.
• Em vez de trocar diretamente os números a e b, cada parte calcula A e B da seguinte forma:

A é igual a g elevado à potência a modulo p :

A = g^a \bmod p

B é igual a g elevado à potência b modulo p :

B = g^b \bmod p

• Os valores A (equivalente a a cor laranja) e B (equivalente a a cor verde) são trocados entre as duas partes. Esta troca pode ter lugar em texto claro numa rede não segura;
• A Alice, tendo recebido B, calcula o valor de z da seguinte forma:

z é igual a B elevado à potência a modulo p :

z = B^a \bmod p

Um lembrete:

B = g^b \bmod p

O resultado é :

z = B^a \bmod p

z = (g^b)^a \bmod p

Aplicando as regras de potência :

(x^n)^m = x^{nm}

O resultado é :

z = g^{ba} \bmod p

• Por seu lado, o Bob, tendo recebido A, também calcula o valor de z da seguinte forma:

z é igual a A elevado à potência b modulo p :

z = A^b \bmod p

O resultado é :

z = (g^a)^b \bmod p

z = g^{ab} \bmod p

z = g^{ba} \bmod p

Graças à distributividade do operador módulo, Alice e Bob obtêm exatamente o mesmo valor z. Este número representa o seu segredo comum, equivalente à cor castanha na popularização anterior com latas de tinta. Podem agora utilizar este segredo comum para encriptar simetricamente as suas comunicações através de uma rede não segura.

Um atacante, mesmo na posse de p, g, A e B (os valores públicos), não será capaz de calcular a, b ou z (os valores privados). Para isso, seria necessário inverter a exponenciação, uma operação impossível sem tentar todas as possibilidades uma a uma, pois equivale a calcular o logaritmo discreto, ou seja, a recíproca da exponencial num grupo cíclico finito.

Assim, desde que os valores de a, b e p sejam suficientemente grandes, o protocolo Diffie-Hellman é seguro. Tipicamente, com parâmetros de 2048 bits (um número decimal de 600 dígitos), testar todas as possibilidades para a e b seria impraticável. Até à data, com estes números, este algoritmo é considerado seguro.

É aqui que reside o principal inconveniente do protocolo Diffie-Hellman. Para ser seguro, o algoritmo tem de utilizar números grandes. É por isso que, atualmente, se prefere utilizar o algoritmo ECDH (Elliptic Curve Diffie-Hellman), uma variante do Diffie-Hellman baseada numa curva algébrica, mais precisamente numa curva elíptica. Esta abordagem permite trabalhar com números muito mais pequenos, mantendo uma segurança equivalente, reduzindo assim os recursos necessários para o cálculo e o armazenamento.

O princípio geral do algoritmo permanece o mesmo. No entanto, em vez de usar um número aleatório a e um número A calculado a partir de a por exponenciação modular, usamos um par de chaves estabelecidas numa curva elíptica. Em vez de confiar na distributividade do operador de módulo, usamos a lei de grupo em curvas elípticas e, mais precisamente, a associatividade desta lei.

Para explicar brevemente o princípio da criptografia em curvas elípticas, uma chave privada é representada por um número aleatório entre 1 e n-1, em que n representa a ordem da curva. A chave pública, por outro lado, é um ponto específico desta curva, obtido a partir da chave privada através da adição e duplicação de pontos a partir do ponto gerador, de acordo com a equação :

K = k \cdot G

Nesta fórmula, K designa a chave pública, k a chave privada e G o ponto gerador.

Uma caraterística essencial destas chaves é a facilidade com que K pode ser calculado a partir de k e G, enquanto que é virtualmente impossível encontrar k a partir de K e G. Esta assimetria cria uma função unidirecional. Por outras palavras, é fácil calcular a chave pública se conhecermos a chave privada, mas é impossível recuperar a chave privada a partir da chave pública. Esta segurança é ainda reforçada pela dificuldade computacional do logaritmo discreto.

Vamos utilizar esta propriedade para adaptar o nosso algoritmo Diffie-Hellman. O princípio de funcionamento do ECDH é o seguinte:

• Alice e Bob chegam a acordo sobre uma curva elíptica criptograficamente segura e os seus parâmetros. Esta informação é pública;
• Alice gera um número aleatório ka que será a sua chave privada. Esta chave privada deve permanecer secreta. Ela determina a sua chave pública Ka adicionando e duplicando pontos na curva elíptica escolhida:

K_a = k_a \cdot G

• Bob também gera um número aleatório kb, que será a sua chave privada. Ele calcula a chave pública associada Kb :

K_b = k_b \cdot G

• Alice e Bob trocam as suas chaves públicas Ka e Kb numa rede pública não segura.
• Alice calcula um ponto (x,y) na curva aplicando a sua chave privada ka à chave pública de Bob Kb :

(x,y) = k_a \cdot K_b

• Bob calcula um ponto (x,y) na curva aplicando a sua chave privada kb à chave pública de Alice Ka :

(x,y) = k_b \cdot K_a

• Alice e Bob obtêm o mesmo ponto na curva elíptica. O segredo partilhado será a abcissa x deste ponto.

Obtêm o mesmo segredo partilhado porque :

(x,y) = k_a \cdot K_b = k_a \cdot (k_b \cdot G) = (k_a \cdot k_b) \cdot G = (k_b \cdot k_a) \cdot G = k_b \cdot (k_a \cdot G) = k_b \cdot K_a

Um potencial atacante que observe a rede pública não segura só poderá obter as chaves públicas de cada indivíduo e os parâmetros da curva elíptica escolhida. Como explicado acima, esta informação por si só não é suficiente para determinar as chaves privadas. Consequentemente, o atacante não pode descobrir o segredo partilhado entre Alice e Bob.

O ECDH é, por conseguinte, um algoritmo de troca de chaves. É frequentemente utilizado em conjunto com outros métodos criptográficos para estabelecer um protocolo completo. Por exemplo, o ECDH está no centro do TLS (Transport Layer Security), um protocolo de encriptação e autenticação utilizado para a camada de transporte da Internet. O TLS utiliza o ECDHE para a troca de chaves, uma variante do ECDH em que as chaves são efémeras, para proporcionar uma confidencialidade persistente. Além disso, o TLS utiliza algoritmos de autenticação, como o ECDSA, algoritmos de encriptação, como o AES, e funções de hash, como o SHA256.

O TLS é responsável pelo s em https e pelo cadeado na barra de endereços do seu browser - símbolos de comunicações encriptadas. Ao fazer este curso, estará a utilizar ECDH, e é muito provável que o utilize diariamente sem sequer o saber.

A transação de notificação

Como vimos na secção anterior, o ECDH é uma variante da troca Diffie-Hellman que utiliza pares de chaves estabelecidos numa curva elíptica. Ainda bem que já temos muitos pares de chaves respeitando esse padrão em nossas carteiras Bitcoin! A ideia do BIP47 é utilizar os pares de chaves das carteiras Bitcoin determinísticas hierárquicas de ambas as partes para estabelecer segredos partilhados e efémeros entre elas. Em vez disso, o BIP47 usa ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).

O ECDHE é utilizado pela primeira vez no BIP47 para transmitir o código de pagamento do remetente para o destinatário. Esta é a famosa transação de notificação. Este passo é essencial, porque para que o BIP47 funcione eficazmente, ambas as partes envolvidas (emissor e recetor) precisam de conhecer os códigos de pagamento um do outro. Este conhecimento permite a derivação das chaves públicas efémeras e, consequentemente, dos endereços de receção em branco associados.

Antes desta troca, o remetente já tem logicamente conhecimento do código de pagamento do destinatário, tendo-o obtido fora da cadeia, por exemplo, no seu sítio Web, na sua fatura ou nas suas redes sociais. No entanto, o destinatário não tem necessariamente conhecimento do código de pagamento do remetente. No entanto, o código deve ser-lhe transmitido; caso contrário, não poderá obter as chaves efémeras necessárias para identificar os endereços onde os seus bitcoins estão armazenados ou aceder aos seus fundos. Embora esta transmissão do código do remetente possa tecnicamente ser efectuada fora da cadeia através de outros meios de comunicação, isto coloca um problema se a carteira tiver de ser recuperada apenas a partir da semente.

Isto porque, ao contrário dos endereços convencionais, os endereços BIP47 não são derivados diretamente da semente do destinatário - utilizar um xpub seria mais simples neste caso - mas resultam de um cálculo que combina os dois códigos de pagamento: o do remetente e o do destinatário. Assim, se o destinatário perder a sua carteira e tentar recuperá-la a partir da sua semente, recuperará o seu próprio código de pagamento, que é diretamente derivado da sua semente. No entanto, para recuperar os endereços efémeros, precisará também dos códigos de pagamento de todos aqueles que lhe enviaram bitcoins através da BIP47. Daí a importância da transação de notificação, que permite guardar esta informação na blockchain do Bitcoin, podendo encontrá-la muito facilmente sem ter de procurar nos milhares de milhões de transacções efectuadas desde o seu lançamento em 2009.

Seria, portanto, possível aplicar o BIP47 sem recorrer à transação de notificação, desde que cada utilizador mantenha uma cópia de segurança dos códigos de pagamento dos seus pares. No entanto, este método revela-se complexo de gerir até que seja desenvolvida uma solução simples, robusta e eficaz para realizar, armazenar e atualizar estas cópias de segurança. Na situação atual, a transação de notificação é quase inevitável.

Nos capítulos seguintes, porém, analisaremos outros protocolos com objectivos semelhantes aos do BIP47, mas que não requerem uma transação de notificação. Estas alternativas introduzem, no entanto, os seus próprios compromissos.

Para além da sua função de guardar os códigos de pagamento, a operação de notificação tem também uma função de notificação para o destinatário, como o seu nome indica. Ela alerta o cliente do destinatário para o facto de ter sido estabelecido um novo túnel de pagamento e sugere-lhe que se mantenha atento aos endereços efémeros resultantes.

O modelo de confidencialidade BIP47

Antes de detalhar o funcionamento técnico da transação de notificação, é importante discutir o modelo de confidencialidade associado à BIP47, que justifica certas medidas tomadas na criação desta transação inicial.

O código de pagamento em si não representa um risco direto para a confidencialidade. Ao contrário do modelo tradicional da Bitcoin, que visa quebrar a ligação entre a identidade do utilizador e as suas transacções (que são públicas) preservando o anonimato das chaves e dos endereços, o código de pagamento pode ser abertamente associado a uma identidade sem representar uma ameaça.

Isto deve-se ao facto de o código de pagamento não ser utilizado para derivar diretamente os endereços que recebem pagamentos BIP47. Em vez disso, estes endereços são gerados através da aplicação ECDH entre as chaves derivadas dos códigos de pagamento das duas partes envolvidas.

Assim, um código de pagamento em si não conduz diretamente a uma perda de confidencialidade, uma vez que apenas o endereço de notificação é derivado do mesmo. Embora este endereço possa revelar certas informações, não revela normalmente as partes com quem se efectuam as transacções, a menos que se proceda a uma análise exaustiva da cadeia. Com efeito, se o remetente utilizar UTXOs que possam ser associados à sua identidade para efetuar a transação de notificação, então é possível deduzir que a sua identidade está provavelmente associada a pagamentos BIP47 ao seu código de pagamento. Isto não revelará as transacções subjacentes, mas indicará a sua provável existência.

Por conseguinte, é essencial manter esta separação rigorosa entre os códigos de pagamento dos utilizadores. Neste sentido, a comunicação inicial do código é um momento crítico para a confidencialidade do pagamento, mas essencial para o bom funcionamento do protocolo. Se um dos códigos de pagamento puder ser obtido publicamente (por exemplo, num sítio Web), o segundo código, o do remetente, não deve, em caso algum, ser associado ao primeiro.

Vejamos um exemplo concreto: Quero fazer um donativo a um movimento político através do BIP47 :

• A organização tornou público o seu código de pagamento no seu sítio Web ou através das suas redes sociais;
• Este código está, portanto, ligado ao movimento político;
• Recebo este código de pagamento ;
• Antes de enviar, tenho de me certificar de que conhecem o meu próprio código de pagamento, que também está associado à minha identidade, uma vez que o utilizo para receber transacções nas minhas redes sociais.

Como é que posso transmitir o meu código sem riscos? A utilização de meios de comunicação convencionais poderia levar à fuga de informação e, consequentemente, associar-me a este movimento político. A transação de notificação oferece uma solução, graças a uma camada de encriptação que impede essa associação entre dois códigos. Embora não seja o único método de transmissão secreta do código de pagamento do remetente, é um método muito eficaz.

No diagrama abaixo, as linhas cor de laranja indicam os pontos onde o fluxo de informação deve ser interrompido e as setas pretas mostram as ligações potencialmente observáveis por terceiros:

Na realidade, no modelo de confidencialidade tradicional da Bitcoin, é muitas vezes complexo dissociar completamente o fluxo de informação entre o par de chaves e o utilizador, especialmente em transacções remotas. Por exemplo, no contexto de uma campanha de donativos, o destinatário deve inevitavelmente divulgar um endereço ou uma chave pública através do seu sítio Web ou das suas redes sociais. A utilização correta do BIP47, em particular na transação de notificação, permite contornar este problema graças ao ECDHE e à camada de encriptação que veremos mais adiante.

Naturalmente, o modelo clássico de confidencialidade da Bitcoin continua a aplicar-se às chaves públicas efémeras, que derivam da combinação dos dois códigos de pagamento. Os dois modelos são, de facto, complementares. O que eu quero enfatizar aqui é que, ao contrário do uso usual de uma chave pública para receber Bitcoins, o código de pagamento pode ser ligado a uma identidade específica, já que a informação "Alice está transacionando com Bob" é quebrada em outro estágio. O código de pagamento é utilizado para gerar endereços de pagamento, mas apenas com base na observação da blockchain, é impossível associar uma transação de pagamento BIP47 aos códigos de pagamento utilizados para a executar, a menos que os UTXOs envolvidos já estivessem anteriormente ligados a uma identidade e os utilizadores associassem os seus códigos de pagamento às respectivas identidades.

Em suma, o modelo de confidencialidade oferecido pelos pagamentos BIP47 pode ser considerado superior ao modelo básico da Bitcoin, embora isso não signifique que seja mágico.

Criação da transação de notificação

Vejamos agora como funciona esta transação de notificação. Imaginemos que a Alice pretende enviar fundos para o Bob utilizando o BIP47. No meu exemplo, Alice actua como remetente e Bob como destinatário. O Bob publicou o seu código de pagamento no seu sítio Web. Por conseguinte, a Alice já conhece o código de pagamento do Bob.

1- Alice calcula um segredo partilhado com ECDH :

• Ela seleciona um par de chaves da sua carteira HD num ramo diferente do seu código de pagamento. Note-se que este par não deve ser facilmente associado ao endereço de notificação da Alice, nem à identidade da Alice (ver secção anterior);
• Alice seleciona a chave privada para este par. Chamamos-lhe a (minúsculas);

a

• A Alice obtém a chave pública associada ao endereço de notificação do Bob. Esta chave é o primeiro filho derivado do código de pagamento do Bob (índice /0). Chamamos a esta chave pública B (maiúsculas). A chave privada associada a esta chave pública tem o nome de b (minúsculas). B é determinada pela adição e duplicação de pontos na curva elíptica a partir de G (o ponto gerador) com b (a chave privada):

B = b \cdot G

• Alice calcula um ponto secreto S (em maiúsculas) na curva elíptica adicionando e duplicando pontos, aplicando a sua chave privada a a partir da chave pública B de Bob.

S = a \cdot B

• Alice calcula o fator de cegueira f que será utilizado para encriptar o seu código de pagamento. Para o fazer, utiliza a função HMAC-SHA512 para determinar um número pseudo-aleatório. A segunda entrada para esta função é um valor que apenas o Bob será capaz de encontrar: x, que é a abcissa do ponto secreto calculado acima. A primeira entrada é o, que é o UTXO consumido como entrada para esta transação (ponto de saída).

f = \text{HMAC-SHA512}(o, x)

**2 - Alice converte o seu código de pagamento pessoal para a base 2 (binário) **

**3 - Utiliza este fator de cegueira como chave para efetuar uma encriptação simétrica no payload do seu código de pagamento. A operação efectuada é comparável à cifra Vernam, também conhecida por "One-Time Pad".

• Alice começa por dividir o seu fator de cegueira em dois: os primeiros 32 bytes são denominados f1 e os últimos 32 bytes são denominados f2. Isto dá-nos :

f = f1 || f2

• Alice calcula a cifra x' da abcissa da chave pública x do seu código de pagamento e a cifra c' do seu código de cadeia c separadamente. f1 e f2 actuam como chaves de cifra respetivamente. A operação utilizada é a XOR (ou exclusiva).

x' = x \oplus f1

c' = c \oplus f2

• Alice substitui os valores reais da abcissa da chave pública x e o código de string c no seu código de pagamento pelos valores encriptados x' e c'.

**Portanto, a Alice tem atualmente o seu código de pagamento com um payload cifrado. Ela construirá e transmitirá uma transação que envolve a sua chave pública A como entrada, uma saída para o endereço de notificação do Bob e uma saída OP_RETURN que consiste no seu código de pagamento com a carga encriptada. Esta transação é a transação de notificação.

Um OP_RETURN é um opcode que marca a saída de uma transação Bitcoin como inválida. Hoje, ele é usado para transmitir ou ancorar informações na blockchain do Bitcoin. Pode armazenar até 80 bytes de dados, que são depois escritos na cadeia e visíveis para todos os outros utilizadores.

Como vimos nas secções anteriores, o ECDH é utilizado para gerar um segredo partilhado entre dois utilizadores que comunicam através de uma rede insegura e potencialmente observada por atacantes. No BIP47, o ECDH é utilizado para comunicar na rede Bitcoin, que, pela sua própria natureza, é uma rede de comunicação transparente e é observada por muitos atacantes. O segredo partilhado calculado através da troca de chaves ECDH é depois utilizado para encriptar a informação secreta a transmitir: o código de pagamento do remetente (Alice).

Vou resumir os passos que acabámos de ver juntos para realizar uma transação de notificação:

• Alice obtém o código de pagamento e o endereço de notificação do Bob;
• Alice seleciona um UTXO da sua carteira HD com o par de chaves correspondente;
• Calcula um ponto secreto na curva elíptica utilizando ECDH ;
• Utiliza este ponto secreto para calcular um HMAC, que é o fator de cegueira;
• Ela usa este fator de cegueira para encriptar o payload do seu código de pagamento pessoal;
• Utiliza uma saída de transação OP_RETURN para comunicar o código de pagamento oculto ao Bob.

Notificação de transacções: um estudo prático

Para entender como funciona mais detalhadamente, e em particular o uso de OP_RETURN, vamos dar uma olhada em uma transação de notificação real. Realizei uma transação desse tipo na testnet, que pode ser encontrada clicando aqui.

Olhando para esta transação, já podemos ver que tem uma única entrada e 4 saídas:

• A primeira saída é o OP_RETURN que contém o meu código de pagamento oculto;
• A segunda saída de 546 sats aponta para o endereço de notificação do meu destinatário;
• O terceiro resultado de 15 000 sats representa a taxa de serviço, uma vez que utilizei a Samourai Wallet para efetuar esta transação;
• A quarta saída de 2 milhões de sats representa a taxa de câmbio, ou seja, a diferença restante na minha entrada que regressa a outro endereço que me pertence.

O mais interessante para estudar é obviamente a saída 0 usando OP_RETURN. Vamos dar uma olhada mais de perto no que ele contém. Aqui está a scriptPubKey em hexadecimal :

6a4c50010002b13b2911719409d704ecc69f74fa315a6cb20fdd6ee39bc9874667703d67b164927b0e88f89f3f8b963549eab2533b5d7ed481a3bea7e953b546b4e91b6f50d800000000000000000000000000

Há várias partes neste guião. Em primeiro lugar, o ficheiro :

6a4c

Entre os opcodes, podemos reconhecer o 0x6a que designa o OP_RETURN e o 0x4c que designa o OP_PUSHDATA1.

O byte que se segue a este último opcode indica o tamanho do payload subsequente. Ele indica 0x50, ou 80 bytes:

6a4c50

De seguida, temos os metadados do meu código de pagamento em texto claro:

010002

A abcissa cifrada da chave pública do meu código de pagamento :

b13b2911719409d704ecc69f74fa315a6cb20fdd6ee39bc9874667703d67b164

O código de cadeia encriptado do meu código de pagamento :

927b0e88f89f3f8b963549eab2533b5d7ed481a3bea7e953b546b4e91b6f50d8

E, finalmente, o preenchimento de 80 bytes, o tamanho padrão de um OP_RETURN :

00000000000000000000000000

Para o ajudar a compreender, eis o meu código de pagamento em texto simples na base 58 :

PM8TJQCyt6ovbozreUCBrfKqmSVmTzJ5vjqse58LnBzKFFZTwny3KfCDdwTqAEYVasn11tTMPc2FJsFygFd3YzsHvwNXLEQNADgxeGnMK8Ugmin62TZU

E na base 16 :

4701000277507c9c17a89cfca2d3af554745d6c2db0e7f6b2721a3941a504933103cc42add94881210d6e752a9abc8a9fa0070e85184993c4f643f1121dd807dd556d1dc000000000000000000000000008604e4db

Se compararmos o meu código de pagamento em texto simples com o OP_RETURN, verificamos que o HRP (0x47) e a soma de controlo (0x8604e4db) não são transmitidos. Isto é normal, uma vez que esta informação se destina a seres humanos.

De seguida, podemos reconhecer a versão (0x01), o campo de bits (0x00) e a paridade da chave pública (0x02). E, no final do código de pagamento, os bytes vazios (0x00000000000000000000000000000000000000) que permitem o preenchimento para atingir um total de 80 bytes. Todos estes metadados são transmitidos sem encriptação.

Por fim, podemos observar que a abcissa da chave pública (0x77507c9c17a89cfca2d3af554745d6c2db0e7f6b2721a3941a504933103cc42a) e o código da string (0xdd94881210d6e752a9abc8a9fa0070e85184993c4f643f1121dd807dd556d1dc) foram encriptados. Esta é a carga útil do código de pagamento.

O que é XOR?

Vimos nas secções anteriores que o código de pagamento é transmitido encriptado utilizando a operação XOR. Vamos analisar mais detalhadamente o funcionamento deste operador, uma vez que é muito utilizado em criptografia.

XOR é um operador lógico bit a bit baseado na álgebra booleana. Dados dois operandos em bits, devolve 1 se os bits do mesmo valor forem diferentes, e devolve 0 se os bits do mesmo valor forem iguais. Aqui está a tabela verdade do XOR de acordo com os valores dos operandos D e E :

| D | E | D XOR E |

| --- | --- | ------- |

| 0 | 0 | 0 |

| 0 | 1 | 1 |

| 1 | 0 | 1 |

| 1 | 1 | 0 |

Por exemplo:

0110 \oplus 1110 = 1000

Ou :

010011 \oplus 110110 = 100101

Com a ECDH, a utilização do XOR como camada de cifragem é particularmente coerente. Em primeiro lugar, graças a este operador, a encriptação é simétrica. Isto significa que o destinatário pode desencriptar o código de pagamento com a mesma chave utilizada para a encriptação. As chaves de encriptação e de desencriptação são calculadas a partir do segredo partilhado utilizando ECDH. Esta simetria é possível graças às propriedades de comutatividade e associatividade do operador XOR:

• Outras propriedades :

D \oplus D = 0

D \oplus 0 = D

• Comutatividade :

D \oplus E = E \oplus D

• Associatividade :

D \oplus (E \oplus Z) = (D \oplus E) \oplus Z = D \oplus E \oplus Z

Se :

D \oplus E = L

Depois :

D \oplus L = D \oplus (D \oplus E) = D \oplus D \oplus E = 0 \oplus E = E \\
\therefore D \oplus L = E

Em segundo lugar, este método de encriptação é muito semelhante à cifra de Vernam (One-Time Pad), o único algoritmo de encriptação conhecido até à data que tem segurança incondicional (ou absoluta). Para que a cifra de Vernam tenha esta caraterística, a chave de encriptação deve ser perfeitamente aleatória, do mesmo tamanho que a mensagem e utilizada apenas uma vez. No método de cifragem aqui utilizado para o BIP47, a chave é, de facto, do mesmo tamanho que a mensagem e o fator de cegueira é exatamente do mesmo tamanho que a concatenação da abcissa da chave pública com o código da cadeia do código de pagamento. Esta chave de encriptação é utilizada apenas uma vez. Por outro lado, esta chave não é derivada de uma aleatoriedade perfeita, uma vez que se trata de um HMAC. Pelo contrário, é pseudo-aleatória. Portanto, não se trata de uma cifra Vernam, mas o método aproxima-se.

Receção da transação de notificação

Agora que a Alice enviou a transação de notificação ao Bob, vamos ver como é que o Bob a interpreta. Como lembrete, Bob deve ter acesso ao código de pagamento de Alice. Sem esta informação, como veremos na próxima secção, não poderá derivar os pares de chaves criados por Alice e, por conseguinte, não poderá aceder aos seus bitcoins recebidos através do BIP47. De momento, a carga do código de pagamento da Alice está encriptada. Vamos ver como é que o Bob o desencripta.

1- Bob monitoriza as transacções que criam saídas com o seu endereço de notificação.

2- Quando uma transação tem uma saída no seu endereço de notificação, o Bob analisa-a para ver se contém uma saída OP_RETURN que esteja em conformidade com a norma BIP47.

3- Se o primeiro byte do payload OP_RETURN for 0x01, Bob começa a procurar um possível segredo partilhado com ECDH :

• O Bob seleciona a chave pública de entrada para a transação. Ou seja, a chave pública de Alice denominada A com :

A = a \cdot G

• O Bob seleciona a chave privada b associada ao seu endereço de notificação pessoal :

b

• Bob calcula o ponto secreto S (segredo partilhado ECDH) na curva elíptica adicionando e duplicando pontos, aplicando a sua chave privada b à chave pública de Alice A :

S = b \cdot A

• O Bob determina o fator de ofuscação f que permitirá desencriptar a carga do código de pagamento da Alice. Da mesma forma que Alice o calculou anteriormente, Bob encontrará f aplicando HMAC-SHA512 a x, o valor da abcissa do ponto secreto S, e a o, o UTXO consumido como entrada para esta transação de notificação:

f = \text{HMAC-SHA512}(o, x)

**O Bob interpreta os dados OP_RETURN da transação de notificação como um código de pagamento. Ele irá simplesmente desencriptar o payload deste potencial código de pagamento usando o fator de cegueira f:

• O Bob divide o fator de cegueira f em 2 partes: os primeiros 32 bytes de f serão f1 e os últimos 32 bytes serão f2 ;
• O Bob decifra o valor da abcissa encriptada x' a partir da chave pública do código de pagamento da Alice:

x = x' \oplus f1

• O Bob decifra o valor do código de cadeia cifrado c' do código de pagamento da Alice:

c = c' \oplus f2

5- Bob verifica se o valor da chave pública do código de pagamento da Alice faz parte do grupo secp256k1. Em caso afirmativo, interpreta-o como um código de pagamento válido. Caso contrário, ignora a transação.

Agora que Bob conhece o código de pagamento de Alice, Alice pode enviar-lhe até 2^32 pagamentos, sem nunca ter de repetir uma transação de notificação deste tipo.

Porque é que funciona? Como é que o Bob pode determinar o mesmo fator de cegueira que a Alice, e assim decifrar o seu código de pagamento? Vejamos mais de perto a ação da ECDH no que acabámos de descrever.

Em primeiro lugar, estamos a lidar com encriptação simétrica. Isto significa que a chave de encriptação e a chave de desencriptação têm o mesmo valor. Esta chave na transação de notificação é o fator de cegueira:

f = f1 || f2

Alice e Bob devem, portanto, obter o mesmo valor para f, sem o transmitir diretamente, uma vez que um atacante poderia roubá-lo e decifrar a informação secreta. Este fator de cegueira é obtido aplicando o HMAC-SHA512 a 2 valores:

• a abcissa de um ponto secreto ;
• e o UTXO consumido na entrada da transação.

Por conseguinte, o Bob precisa destas duas informações para decifrar o código de pagamento da Alice. Para o UTXO de entrada, o Bob pode simplesmente obtê-lo observando a transação de notificação. Para o ponto secreto, o Bob terá de utilizar o ECDH. Como se viu na secção anterior sobre Diffie-Hellman, simplesmente trocando as suas respectivas chaves públicas e aplicando secretamente as suas chaves privadas à chave pública um do outro, Alice e Bob podem encontrar um ponto secreto preciso na curva elíptica. A transação de notificação baseia-se neste mecanismo:

• O par de chaves do Bob :

B = b \cdot G

• O par de chaves da Alice :

A = a \cdot G

• Para um segredo S (x, y) :

S = a \cdot B = a \cdot (b \cdot G) = (b \cdot a) \cdot G = b \cdot A

Agora que Bob conhece o código de pagamento de Alice, poderá detetar os seus pagamentos BIP47 e derivar as chaves privadas que bloqueiam os bitcoins recebidos.

Vou resumir os passos que acabámos de ver juntos para receber e interpretar uma transação de notificação:

• O Bob monitoriza a saída da transação para o seu endereço de notificação;
• Quando detecta um, recupera a informação contida no OP_RETURN ;
• Bob seleciona a chave pública como entrada e calcula um ponto secreto utilizando ECDH ;
• Utiliza este ponto secreto para calcular um HMAC, que é o fator de cegueira;
• Utiliza este fator de cegueira para decifrar o código de pagamento de Alice contido no OP_RETURN.

A operação de pagamento BIP47

Vejamos como funciona o processo de pagamento com o BIP47. Para recordar a situação atual :

• Alice conhece o código de pagamento do Bob, que simplesmente obteve no seu sítio Web;
• O Bob conhece o código de pagamento da Alice a partir da transação de notificação;
• A Alice vai efetuar o seu primeiro pagamento ao Bob. Ela pode efetuar muitos mais da mesma forma.

Antes de explicar este processo, penso que é importante recordar quais os índices em que estamos a trabalhar atualmente. O caminho de derivação de um código de pagamento é descrito da seguinte forma: m/47'/0'/0'. A profundidade seguinte divide os índices da seguinte forma:

• O primeiro par de filhas normais (não reforçadas) é o utilizado para gerar o endereço de notificação discutido na secção anterior: m/47'/0'/0'/0 ;
• Os pares de chaves filhas normais são utilizados na ECDH para gerar endereços de recibos de pagamento BIP47, como veremos nesta secção: de m/47'/0'/0'/0 a m/47'/0'/0'/2.147.483.647 ;
• Os pares de chaves filhas reforçadas são códigos de pagamento efémeros: de m/47'/0'/0'/0'/0' a m/47'/0'/0'/2.147.483.647'.

Sempre que Alice quiser enviar um pagamento a Bob, obtém um endereço novo, único e em branco, mais uma vez utilizando o protocolo ECDH:

• Alice seleciona a primeira chave privada derivada do seu código de pagamento pessoal reutilizável :

a

• Alice seleciona a primeira chave pública não utilizada derivada do código de pagamento de Bob. Chamaremos a esta chave pública B. Está associada à chave privada b conhecida apenas pelo Bob:

B = b \cdot G

• Alice calcula um ponto secreto S na curva elíptica adicionando e duplicando pontos aplicando a sua chave privada a a partir da chave pública de Bob B :

S = a \cdot B

• A partir deste ponto secreto, Alice calcula o segredo partilhado s (minúsculas). Para tal, seleciona a abcissa do ponto secreto S denominado Sx, e passa este valor para a função hash SHA256:

$$ S = (Sx, Sy) $$$

s = \text{SHA256}(Sx)

• Alice usa este segredo partilhado s para calcular um endereço de receção de pagamento Bitcoin. Primeiro, ela verifica se s está contido na ordem da curva secp256k1. Se não for esse o caso, ela incrementa o índice da chave pública de Bob para obter outro segredo partilhado ;
• Num segundo passo, ela calcula uma chave pública K0 adicionando os pontos B e s-G na curva elíptica. Por outras palavras, Alice adiciona a chave pública derivada do código de pagamento de Bob B a outro ponto calculado na curva elíptica adicionando e duplicando pontos com o segredo partilhado s do ponto gerador da curva secp256k1 G. Este novo ponto representa uma chave pública e chamamos-lhe K0 :

K0 = B + s \cdot G

• Com esta chave pública K0, Alice pode derivar um endereço de receção em branco da forma padrão (por exemplo, SegWit V0 em bech32).

Depois de Alice ter obtido o endereço de receção K0 de Bob, pode efetuar uma transação Bitcoin da forma habitual. Para o fazer, ela escolhe um UTXO que possui, protegido por um par de chaves de um ramo diferente da sua carteira HD, e consome-o para satisfazer uma saída para o endereço K0 de Bob. É importante notar que este pagamento, uma vez derivado o endereço, segue um processo clássico e já não depende das chaves associadas ao BIP47.

Vou resumir os passos que acabámos de ver juntos para enviar um pagamento BIP47:

• Alice seleciona a primeira chave privada filha derivada do seu código de pagamento pessoal ;
• Calcula um ponto secreto na curva elíptica utilizando ECDH a partir da primeira chave pública filha não utilizada derivada do código de pagamento de Bob;
• Utiliza este ponto secreto para calcular um segredo partilhado com SHA256 ;
• Ela utiliza este segredo partilhado para calcular um novo ponto secreto na curva elíptica;
• Ela acrescenta este novo ponto secreto à chave pública do Bob;
• Obtém uma nova chave pública efémera para a qual apenas Bob tem a chave privada associada;
• Alice pode efetuar uma transação clássica para Bob com o endereço de receção efémero derivado.

Se Alice quiser fazer um segundo pagamento, seguirá os mesmos passos que antes, exceto que desta vez selecionará a segunda chave pública derivada do código de pagamento de Bob. Especificamente, ela usará a próxima chave não utilizada. Obterá assim um novo endereço de receção pertencente ao Bob, designado por K1 :

Pode continuar desta forma e obter até 2^32 endereços em branco pertencentes ao Bob.

De uma perspetiva externa, olhando para a cadeia de blocos, é teoricamente impossível diferenciar um pagamento BIP47 de um pagamento convencional. Eis um exemplo de uma transação de pagamento BIP47 na Testnet:

94b2e59510f2e1fa78411634c98a77bbb638e28fb2da00c9f359cd5fc8f87254

Parece uma transação clássica com uma entrada consumida, uma saída de pagamento e uma taxa de câmbio:

Receção do pagamento BIP47 e derivação da chave privada

Alice acaba de efetuar o seu primeiro pagamento para um endereço BIP47 em branco pertencente a Bob. Agora vamos ver como é que o Bob recebe este pagamento. Veremos também porque é que Alice não tem acesso à chave privada do endereço que ela própria acabou de gerar e como é que Bob encontra essa chave para gastar os bitcoins que acabou de receber.

Assim que Bob recebe a transação de notificação de Alice, ele obtém a chave pública BIP47 K0 mesmo antes de o seu correspondente ter enviado um pagamento. Assim, ele observa qualquer pagamento para o endereço associado. De facto, ele deriva imediatamente vários endereços que observa (K0, K1, K2, K3...). Eis como ele deriva esta chave pública K0 :

• O Bob seleciona a primeira chave privada filha derivada do seu código de pagamento. Esta chave privada tem o nome de b. Está associada à chave pública B com a qual Alice efectuou os seus cálculos no passo anterior:

b

• Bob seleciona a primeira chave pública de Alice derivada do seu código de pagamento. Esta chave tem o nome de A. Está associada à chave privada a com a qual a Alice efectuou os seus cálculos e que é conhecida apenas por ela. O Bob pode realizar este processo, uma vez que conhece o código de pagamento da Alice, que lhe foi enviado com a transação de notificação:

A = a \cdot G

• Bob calcula o ponto secreto S, adicionando e duplicando pontos na curva elíptica, aplicando a sua chave privada b à chave pública de Alice A. Mais uma vez, o ECDH é utilizado para garantir que este ponto S será o mesmo para Bob e Alice:

S = b \cdot A

• Da mesma forma que Alice, Bob isola a abscissa deste ponto S. Chamámos a este valor Sx. Ele passa este valor para a função SHA256 para encontrar o segredo partilhado s (minúsculas):

s = \text{SHA256}(Sx)

• Da mesma forma que Alice, Bob calcula o ponto s-G na curva elíptica. De seguida, adiciona este ponto secreto à sua chave pública B. Obtém então um novo ponto na curva elíptica, que interpreta como uma chave pública K0 :

K0 = B + s \cdot G

Quando Bob tiver esta chave pública K0, pode obter a chave privada associada para gastar os seus bitcoins. Só ele pode gerar esta chave privada:

• O Bob soma a chave privada da sua filha b derivada do seu código de pagamento pessoal. Só ele pode obter o valor de b. Em seguida, adiciona b ao segredo partilhado s para obter k0, a chave privada de K0:

k0 = b + s

Graças à lei de grupo da curva elíptica, Bob obtém exatamente a chave privada correspondente à chave pública utilizada por Alice. Temos, portanto, que :

K0 = k0 \cdot G

Vou resumir os passos que acabámos de ver juntos para receber um pagamento BIP47 e calcular a chave privada correspondente:

• Bob seleciona a primeira chave privada filha derivada do seu código de pagamento pessoal ;
• Calcula um ponto secreto na curva elíptica utilizando ECDH a partir da primeira chave pública filha derivada do código de cadeia de Alice;
• Utiliza este ponto secreto para calcular um segredo partilhado com SHA256 ;
• Ele usa este segredo partilhado para calcular um novo ponto secreto na curva elíptica;
• Acrescenta este novo ponto secreto à sua chave pública pessoal;
• Obtém uma nova chave pública efémera, a chave para a qual Alice enviará o seu primeiro pagamento;
• Bob calcula a chave privada associada a esta chave pública efémera adicionando a sua chave privada filha derivada do seu código de pagamento e o segredo partilhado.

Como Alice não pode obter b (a chave privada de Bob), não pode determinar k0 (a chave privada associada ao endereço de receção BIP47 de Bob). Esquematicamente, podemos representar o cálculo do segredo partilhado S da seguinte forma:

Uma vez encontrado o segredo partilhado com ECDH, Alice e Bob calculam a chave pública de pagamento BIP47 K0 e Bob calcula também a chave privada associada k0 :

Reembolso do pagamento BIP47

Uma vez que o Bob conhece o código de pagamento reutilizável da Alice, já tem toda a informação necessária para lhe enviar um reembolso. Não precisa de voltar a contactar a Alice para lhe pedir qualquer informação. Ele simplesmente precisa de a notificar com uma transação de notificação, para que ela possa recuperar os seus endereços BIP47 com a sua semente, e então ele pode também enviar-lhe até 2^32 pagamentos.

A funcionalidade de reembolso é específica do BIP47 e é uma das suas vantagens em relação a outros métodos, como os pagamentos silenciosos, que analisaremos em capítulos posteriores.

O Bob pode então reembolsar a Alice da mesma forma que ela lhe enviou os pagamentos. Os papéis invertem-se:

*Muito obrigado a [Fanis Michalakis] (https://x.com/FanisMichalakis) pela sua revisão e pelos seus conselhos especializados sobre o artigo que inspirou a redação deste capítulo!

https://planb.network/tutorials/privacy/on-chain/paynym-bip47-a492a70b-50eb-4f95-a766-bae2c5535093

Pagamentos silenciosos

O BIP47 tem sido amplamente criticado por sua ineficiência onchain. Como explicado no capítulo anterior, exige a realização de uma transação de notificação para cada novo destinatário. Este constrangimento torna-se insignificante se planearmos estabelecer um canal de pagamento sustentável com este destinatário. De facto, uma única transação de notificação abre caminho a um número quase infinito de pagamentos BIP47 subsequentes.

No entanto, em determinadas situações, a transação de notificação pode ser um obstáculo para o utilizador. Tomemos o exemplo de uma doação única a um beneficiário: com um endereço Bitcoin clássico, uma única transação é suficiente para completar a doação. Mas com o BIP47, são necessárias duas transacções: uma para a notificação e outra para o pagamento efetivo. Quando a procura de espaço em bloco é baixa e as taxas de transação são baixas, este passo extra não é normalmente um problema. No entanto, em tempos de congestionamento, as taxas de transação podem tornar-se exorbitantes para um único pagamento, duplicando potencialmente o custo para o utilizador em comparação com uma transação Bitcoin normal, o que pode revelar-se inaceitável para o utilizador.

Para situações em que o utilizador planeia efetuar apenas alguns pagamentos a um identificador estático, foram desenvolvidas outras soluções. Entre estas contam-se os pagamentos silenciosos, descritos em [BIP352] (https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki). Este protocolo permite utilizar um identificador estático para receber pagamentos sem produzir reutilizações de endereços e sem exigir a utilização de transacções de notificação. Vejamos como funciona este protocolo.

Para entender completamente este capítulo, é essencial dominar o funcionamento do ECDH (Elliptic Curve Diffie-Hellman) e a derivação de chaves criptográficas numa carteira HD. Estes conceitos foram abordados em pormenor no capítulo anterior sobre o BIP47. Não os vou repetir aqui. Se ainda não está familiarizado com estes conceitos, recomendo que consulte o capítulo anterior antes de continuar com este. Não voltarei a falar dos riscos associados à reutilização dos endereços de receção, nem da importância de ter um identificador único para a receção dos pagamentos

Porque não deslocar a notificação?

Tal como referido no capítulo BIP47, a transação de notificação tem duas funções principais:

• Notifica o destinatário ;
• Transmite o código de pagamento do remetente.

Poder-se-ia pensar, ingenuamente, que este processo de notificação poderia ser efectuado fora da cadeia. Em teoria, é perfeitamente viável: tudo o que o destinatário teria de fazer é indicar um meio de comunicação para receber os códigos de pagamento BIP47 dos remetentes. No entanto, há dois grandes problemas com esta abordagem:

• Em primeiro lugar, transferiria o processo de transmissão do código para outro protocolo de comunicação. Os problemas relacionados com o custo e a confidencialidade da troca manter-se-iam, mas seriam simplesmente transferidos para este novo protocolo. Em termos de confidencialidade, isto também poderia criar uma ligação entre a identidade de um utilizador e a atividade na cadeia, que é o que procuramos evitar ao realizar a notificação diretamente na cadeia de blocos. Além disso, fazer a notificação fora da blockchain introduziria riscos de censura (como o bloqueio de fundos) que não existem na Bitcoin;
• Em segundo lugar, isto colocaria um problema de recuperação. Com o BIP47, o destinatário deve conhecer os códigos de pagamento dos remetentes para aceder aos fundos. Isto é verdade aquando da receção, mas também no caso de os fundos serem recuperados através da semente se a carteira se perder. Com as notificações onchain, este risco é evitado, uma vez que o utilizador pode recuperar e desencriptar as transacções de notificação simplesmente conhecendo a sua semente. No entanto, se a notificação for feita fora da blockchain, o utilizador teria de manter uma cópia de segurança dinâmica de todos os códigos de pagamento recebidos, o que é impraticável para o utilizador médio.

Todos estes condicionalismos tornam a utilização da notificação onchain essencial para a BIP47. No entanto, os Silent Payments procuram evitar esta etapa de notificação onchain precisamente devido ao seu custo. A solução adoptada não consiste, portanto, em deslocar a notificação, mas em eliminá-la totalmente. Para tal, há que aceitar um compromisso: a digitalização. Ao contrário do BIP47, onde o utilizador sabe exatamente onde encontrar os seus fundos graças às transacções de notificação, com o Silent Payments, o utilizador tem de examinar todas as transacções Bitcoin existentes para detetar quaisquer pagamentos que lhe sejam destinados. Para reduzir esta carga operacional, a pesquisa de pagamentos silenciosos limita-se apenas a transacções susceptíveis de conter tais pagamentos, ou seja, aquelas com pelo menos uma saída Taproot P2TR. A pesquisa também se concentra exclusivamente em transacções a partir da data de criação da carteira (não é necessário pesquisar transacções que remontem a 2009 se a carteira tiver sido criada em 2024).

Assim, pode ver-se por que razão o BIP47 e os pagamentos silenciosos, embora tenham um objetivo semelhante, implicam contrapartidas diferentes e, por conseguinte, respondem efetivamente a casos de utilização distintos. Para pagamentos pontuais, como donativos pontuais, os pagamentos silenciosos são mais adequados devido ao seu custo mais baixo. Por outro lado, para transacções regulares para o mesmo destinatário, como no caso de plataformas de troca ou pools de mineração, o BIP47 pode ser preferido.

Vejamos o funcionamento técnico dos pagamentos silenciosos para compreender melhor o que está em causa. Para o efeito, sugiro que adoptemos a mesma abordagem do documento explicativo do BIP352. Vamos decompor progressivamente os cálculos a efetuar, elemento por elemento, justificando cada novo elemento.

Alguns conceitos a compreender

Antes de começar, é importante salientar que os pagamentos silenciosos dependem exclusivamente da utilização de tipos de script P2TR (Pay to Taproot). Ao contrário do BIP47, não é necessário derivar endereços de receção a partir de chaves públicas infantis através de hashing. No padrão P2TR, a chave pública ajustada é usada diretamente e não criptografada no endereço. Assim, um endereço de receção Taproot é essencialmente uma chave pública com alguns metadados. Esta chave pública modificada é a agregação de duas outras chaves públicas: uma que permite a despesa direta e tradicional através de uma simples assinatura, e a outra que representa a raiz Merkle do MAST, que autoriza a despesa sujeita à satisfação de uma das condições potencialmente inscritas na árvore Merkle.

Há duas razões principais para a decisão de limitar os pagamentos silenciosos exclusivamente à Taproot:

• Em primeiro lugar, facilita consideravelmente a implementação e as futuras actualizações do software de carteiras, uma vez que só é necessário respeitar uma norma;
• Em segundo lugar, esta abordagem ajuda a melhorar o anonimato dos utilizadores, incentivando-os a não se dividirem entre diferentes tipos de scripts, que geram impressões digitais de carteiras distintas na análise em cadeia (para mais informações sobre este conceito, consultar o capítulo 4 da parte 2).

Derivação ingénua de uma chave pública de pagamentos silenciosos

Vamos começar com um exemplo simples para entender como funcionam os SPs (Silent Payments). Tomemos como exemplo Alice e Bob, dois utilizadores de Bitcoin. Alice deseja enviar Bitcoins para Bob num endereço de receção em branco. Existem três objectivos para este processo:

• A Alice deve ser capaz de gerar um endereço em branco;
• O Bob deve ser capaz de identificar um pagamento enviado para este endereço específico;
• O Bob precisa de obter a chave privada associada a este endereço para poder gastar os seus fundos.

Alice tem um UTXO na sua carteira Bitcoin segura com o seguinte par de chaves:

• a: a chave privada ;
• A: a chave pública (A = a \cdot G)

Bob tem um endereço SP que publicou na Internet com :

• b: a chave privada ;
• B: a chave pública (B = b \cdot G)

Ao recuperar o endereço de Bob, Alice é capaz de calcular um novo endereço em branco que pertence a Bob usando ECDH. Chamemos a este endereço P :

P = B + \text{hash}(a \cdot B) \cdot G

Nesta equação, Alice calculou simplesmente o produto escalar da sua chave privada a e da chave pública de Bob B. Passou este resultado para uma função hash conhecida por todos. O valor resultante é então multiplicado escalarmente pelo ponto gerador G da curva elíptica secp256k1. Finalmente, Alice adiciona o ponto resultante à chave pública de Bob B. Uma vez que Alice tem este endereço P, ela utiliza-o como saída numa transação, ou seja, envia bitcoins para ele.

No contexto dos pagamentos silenciosos, a função "hash" corresponde a uma função hash SHA256 especificamente marcada com BIP0352/SharedSecret, que garante que os hashes gerados são únicos para este protocolo e não podem ser reutilizados noutros contextos, oferecendo simultaneamente uma proteção adicional contra a reutilização de nonces nas assinaturas. Esta norma corresponde à especificada na BIP340 para assinaturas Schnorr em secp256k1. Graças às propriedades da curva elíptica em que se baseia a ECDH, sabemos que :

a \cdot B = b \cdot A

O Bob poderá assim calcular o endereço de receção para o qual a Alice enviou os bitcoins. Para isso, ele monitoriza todas as transacções Bitcoin que cumprem os critérios dos Pagamentos Silenciosos e aplica o seguinte cálculo a cada uma delas para ver se o pagamento lhe é endereçado (scanning):

P' = B + \text{hash}(b \cdot A) \cdot G

Quando ele analisa a transação da Alice, apercebe-se que P' é igual a P. Por conseguinte, ele sabe que o pagamento é dirigido a ela:

P' = B + \text{hash}(b \cdot A) \cdot G = B + \text{hash}(a \cdot B) \cdot G = P

A partir daqui, Bob poderá calcular a chave privada p que permite gastar o endereço P:

p = (b + \text{hash}(b \cdot A)) \bmod n

Como se pode ver, para calcular esta chave privada p, é necessário ter a chave privada b. Só o Bob tem esta chave privada b. Por conseguinte, ele será o único capaz de gastar os bitcoins enviados para o seu endereço Silent Payments.

Legenda:

• B : A chave pública/endereço estático publicado pelo Bob
• b : A chave privada do Bob
• A : chave pública UTXO da Alice utilizada como entrada da transação
• a : chave privada da Alice
• G : O ponto gerador da curva elíptica secp256k1
• \text{SHA256} : A função hash SHA256 marcada com BIP0352/SharedSecret
• s : O segredo comum da ECDH
• P : A chave pública/endereço único para pagamento a Bob

Aqui está uma abordagem inicial bastante ingénua para usar o endereço estático do Bob, notado B, para derivar um endereço único P para enviar bitcoins. No entanto, este método é demasiado simplista e tem várias falhas que precisam de ser corrigidas. O primeiro problema é que, neste esquema, Alice não pode criar várias saídas para Bob dentro da mesma transação.

Como é que posso criar várias saídas?

No exemplo da secção anterior, Alice cria uma única saída que irá para Bob no seu endereço único P. Com a mesma entrada selecionada, é impossível para a Alice criar dois endereços em branco distintos para o Bob, uma vez que o método utilizado conduziria sempre ao mesmo resultado para P, ou seja, o mesmo endereço. No entanto, pode haver muitas situações em que a Alice queira dividir o seu pagamento ao Bob em vários montantes mais pequenos, criando assim vários UTXOs. É, portanto, necessário encontrar um método para o conseguir.

Para o conseguir, vamos modificar ligeiramente o cálculo que a Alice efectua para obter P, de modo a poder gerar dois endereços distintos para o Bob, nomeadamente P_0 e P_1.

Para modificar o cálculo e obter 2 endereços diferentes, basta adicionar um número inteiro que modifique o resultado. Assim, a Alice adicionará 0 ao seu cálculo para obter o endereço P_0 e 1 para obter o endereço P_1. Chamemos a este número inteiro i :

P_i = B + \text{hash}(a \cdot B \text{ ‖ } i) \cdot G

O processo de cálculo mantém-se inalterado em relação ao método anterior, exceto que, desta vez, Alice concatena a \cdot B com i antes de proceder ao hash. Depois, basta modificar i para obter um novo endereço pertencente a Bob. Por exemplo:

P_0 = B + \text{hash}(a \cdot B \text{ ‖ } 0) \cdot G

P_1 = B + \text{hash}(a \cdot B \text{ ‖ } 1) \cdot G

Quando o Bob analisa a blockchain em busca de pagamentos silenciosos destinados a ele, ele começa usando i = 0 para o endereço P_0. Se não encontrar nenhum pagamento em P_0, conclui que esta transação não contém pagamentos silenciosos destinados a ele e abandona a análise. No entanto, se P_0 for válido e contiver um pagamento para ele, ele continua com P_1 na mesma transação para verificar se a Alice fez um segundo pagamento. Se P_1 for inválido, pára de procurar esta transação; caso contrário, continua a testar os valores sucessivos de i:

P_0 = B + \text{hash}(b \cdot A \text{ ‖ } 0) \cdot G

P_1 = B + \text{hash}(b \cdot A \text{ ‖ } 1) \cdot G

Uma vez que o Bob pára imediatamente em i = 0 se P_0 não funcionar, a utilização deste número inteiro não acrescenta quase nenhuma carga operacional adicional ao Bob para a fase de exploração da transação.

O Bob pode então calcular as chaves privadas da mesma forma:

p_0 = (b + \text{hash}(b \cdot A \text{ ‖ } 0)) \bmod n

p_1 = (b + \text{hash}(b \cdot A \text{ ‖ } 1)) \bmod n

Legenda:

• B : A chave pública/endereço estático publicado pelo Bob
• b : A chave privada do Bob
• A : chave pública UTXO da Alice utilizada como entrada da transação
• a : chave privada da Alice
• G : O ponto gerador da curva elíptica secp256k1
• \text{SHA256} : A função hash SHA256 marcada com BIP0352/SharedSecret
• s_0 : O primeiro segredo comum ECDH
• s_1 : O segundo segredo comum da ECDH
• P_0 : A primeira chave pública / endereço único para pagamento ao Bob
• P_1 : A segunda chave pública / endereço único para pagamento ao Bob

Com este método, estamos a começar a obter um bom protocolo, mas ainda há alguns desafios a ultrapassar, nomeadamente a prevenção da reutilização de endereços.

Como evitar a reutilização de endereços?

Como vimos nas secções anteriores, Alice utiliza o par de chaves que protege o seu UTXO, que irá utilizar para calcular o segredo partilhado ECDH com Bob. Este segredo permite-lhe obter o endereço único P_0. No entanto, o par de chaves (a, A) utilizado pela Alice pode proteger vários UTXOs se ela tiver reutilizado este endereço várias vezes. No caso de Alice efetuar dois pagamentos para o endereço estático de Bob B utilizando dois UTXOs protegidos pela mesma chave A, isto resultaria na reutilização do endereço por Bob.

A reutilização de endereços é uma prática muito má em termos de confidencialidade do utilizador. Para saber porquê, aconselho-o a rever as primeiras partes deste curso de formação. De facto, uma vez que o endereço único P_0 é derivado de A e B, se Alice derivar um segundo endereço para um segundo pagamento a B, com a mesma chave A, acabará exatamente no mesmo endereço P_0. Para evitar este risco e impedir a reutilização de endereços no âmbito dos pagamentos silenciosos, teremos de modificar um pouco os nossos cálculos.

O que queremos é que cada UTXO consumido pela Alice como entrada para um pagamento dê um endereço único do lado do Bob, mesmo que vários UTXOs estejam protegidos pelo mesmo par de chaves. Assim, tudo o que precisamos de fazer é adicionar uma referência ao UTXO quando calcularmos o endereço único P_0. Esta referência será simplesmente o hash do UTXO consumido como entrada:

\text{inputHash} = \text{hash}(\text{outpoint} \text{ ‖ } A)

E Alice adicionará esta referência à entrada para o seu cálculo do endereço único P_0 :

P_0 = B + \text{hash}(\text{inputHash} \cdot a \cdot B \text{ ‖ } 0) \cdot G

Ao digitalizar, o Bob também pode adicionar \text{inputHash}, uma vez que só tem de observar a transação para deduzir \text{outpoint} :

P_0 = B + \text{hash}(\text{inputHash} \cdot b \cdot A \text{ ‖ } 0) \cdot G

Quando encontra um P_0 válido, pode calcular a chave privada p_0 correspondente:

p_0 = (b + \text{hash}(\text{inputHash} \cdot b \cdot A \text{ ‖ } 0)) \bmod n

Legenda:

• B : A chave pública/endereço estático publicado pelo Bob
• b : A chave privada do Bob
• A : chave pública UTXO da Alice utilizada como entrada da transação
• a : chave privada da Alice
• H : hash UTXO utilizado como entrada
• G : O ponto gerador da curva elíptica secp256k1
• \text{SHA256} : A função hash SHA256 marcada com BIP0352/SharedSecret
• s_0 : O primeiro segredo comum da ECDH
• P_0 : A primeira chave pública / endereço único para pagamento ao Bob

Para já, os nossos cálculos pressupõem que a Alice utiliza um único input para a sua transação. No entanto, ela deve poder utilizar vários inputs. Consequentemente, do lado do Bob, para cada transação que envolva vários inputs, ele deve teoricamente calcular a ECDH para cada input para determinar se lhe é destinado um pagamento. Este método não é satisfatório, pelo que temos de encontrar uma solução para reduzir o volume de trabalho!

Transformar chaves públicas em entradas

Para resolver este problema, em vez de utilizarmos o par de chaves que assegura uma entrada específica do lado da Alice, utilizaremos a soma de todos os pares de chaves utilizados nas entradas da transação. Esta soma será então considerada como um novo par de chaves. Esta técnica é conhecida como "tweaking".

Por exemplo, imaginemos que a transação da Alice tem 3 entradas, cada uma protegida com um par de chaves diferente:

• a_0 é utilizado para proteger a entrada #0 ;
• a_1 é utilizado para proteger a entrada #1;
• a_2 assegura a entrada #2.

Seguindo o método anteriormente descrito, Alice teria de escolher um único par de chaves de entre a_0, a_1 e a_2 para calcular o segredo ECDH e gerar o endereço de pagamento único P a partir do endereço estático de Bob B. No entanto, esta abordagem exige que o Bob teste cada possibilidade sequencialmente, começando com a_0, depois a_1, e assim por diante, até identificar um par que gere um endereço P válido. Este processo exige que o Bob execute o cálculo do ECDH em todas as entradas de todas as transacções, o que aumenta consideravelmente a carga operacional da análise.

Para evitar isto, pedimos à Alice para calcular P usando a soma de todas as chaves de entrada. Usando o nosso exemplo, a chave privada alterada a seria calculada da seguinte forma:

a = a_0 + a_1 + a_2

Da mesma forma, Alice e Bob podem calcular a chave pública modificada:

A = A_0 + A_1 + A_2

Com este método, o Bob só precisa de calcular a soma das chaves públicas da transação e, em seguida, calcular o segredo ECDH apenas a partir de A, o que reduz consideravelmente o número de cálculos necessários para a fase de exploração.

No entanto, lembre-se da secção anterior. Adicionámos o hash \text{inputHash} ao nosso cálculo, que é utilizado como um nonce para evitar a reutilização de endereços:

\text{inputHash} = \text{hash}(\text{outpoint} \text{ ‖ } A)

Mas se existirem várias entradas numa transação, é necessário poder determinar qual o \text{outpoint} escolhido neste cálculo. De acordo com o BIP352, o critério de seleção do \text{outpoint} a utilizar é escolher o mais pequeno lexicograficamente, o que significa selecionar o UTXO que aparece em primeiro lugar por ordem alfabética. Este método padroniza o UTXO a ser escolhido em cada transação. Por exemplo, se este \text{outpoint} mais pequeno lexicograficamente for \text{outpoint}_L, o cálculo de \text{inputHash} será :

\text{inputHash} = \text{hash}(\text{outpoint}_L \text{ ‖ } A)

Os cálculos permanecem idênticos aos apresentados na secção anterior, exceto que a chave privada a e a sua chave pública correspondente A já não são um par utilizado para proteger uma única entrada, mas representam agora o ajuste para todos os pares de chaves nas entradas.

Separar as chaves de despesas e de digitalização

Para já, referimo-nos ao endereço estático de pagamento silencioso B como uma chave pública única. Lembre-se que é esta chave pública B que a Alice utiliza para criar o segredo partilhado ECDH, que por sua vez calcula o endereço de pagamento único P. O Bob utiliza esta chave pública B e a chave privada correspondente b para a fase de leitura. Mas também utilizará a chave privada b para calcular a chave privada p que permite efetuar despesas a partir do endereço P.

A desvantagem deste método é que a chave privada b, que é usada para calcular todas as chaves privadas dos endereços que receberam pagamentos silenciosos, é também usada pelo Bob para verificar as transacções. Este passo requer que a chave b esteja disponível num software de carteira ligado à Internet, o que a expõe mais ao risco de roubo do que mantê-la numa carteira fria. Idealmente, seria benéfico poder tirar partido dos Pagamentos Silenciosos mantendo a chave privada b, que controla o acesso a todas as outras chaves privadas, segura numa carteira de hardware. Felizmente, o protocolo foi adaptado para permitir exatamente isso.

Para tal, o BIP352 requer que o recetor utilize 2 pares de chaves diferentes:

• b_{\text{spend}}$: para calcular as chaves privadas de endereços de pagamento únicos;
• b_{\text{scan}}$: para encontrar endereços de pagamento únicos.

Desta forma, Bob pode manter a chave privada b_{\text{spend}} numa carteira de hardware e utilizar a chave privada b_{\text{scan}} num software online para encontrar os seus pagamentos silenciosos, sem revelar b_{\text{spend}}. Por outro lado, as chaves públicas B_{\text{scan}} e B_{\text{spend}} são ambas reveladas publicamente, uma vez que estão localizadas no endereço estático de Bob B :

B = B_{\text{scan}} \text{ ‖ } B_{\text{gastos}}

Para calcular um endereço de pagamento único P_0 pertencente ao Bob, a Alice efectua agora o seguinte cálculo:

P_0 = B_{\text{spend}} + \text{hash}(\text{inputHash} \cdot a \cdot B_{\text{scan}} \text{ ‖ } 0) \cdot G

Para encontrar os pagamentos que lhe são dirigidos, o Bob efectua o seguinte cálculo:

P_0 = B_{\text{spend}} + \text{hash}(\text{inputHash} \cdot b_{\text{scan}} \cdot A \text{ ‖ } 0) \cdot G

Como pode ver, até agora o Bob não precisou de usar b_{\text{spend}}, que está na sua carteira de hardware. Quando ele quiser gastar P_0, pode fazer o seguinte cálculo para encontrar a chave privada p_0 :

p_0 = (b_{\text{spend}} + \text{hash}(\text{inputHash} \cdot b_{\text{scan}} \cdot A \text{ ‖ } 0)) \bmod n

Legenda:

• B_{\text{scan}}: Chave de digitalização pública do Bob (endereço estático)
• b_{\text{scan}} : A chave de digitalização privada do Bob
• B_{\text{spend}} : Chave de despesa pública do Bob (endereço estático)
• b_{\text{spend}} : a chave de despesa privada do Bob
• A : Soma das entradas de chave pública (tweak)
• a : A chave privada correspondente à chave pública modificada
• H : O hash do UTXO mais pequeno (lexicograficamente) utilizado como entrada
• G : O ponto gerador da curva elíptica secp256k1
• \text{SHA256} : A função hash SHA256 marcada com BIP0352/SharedSecret
• s_0 : O primeiro segredo comum ECDH
• P_0 : A primeira chave pública / endereço único para pagamento ao Bob

Utilizar endereços SP com uma etiqueta

Bob tem, portanto, um endereço estático B para pagamentos silenciosos como :

B = B_{\text{scan}} \text{ ‖ } B_{\text{gastos}}

O problema com este método é que não permite separar os diferentes pagamentos enviados para este endereço. Por exemplo, se o Bob tiver 2 clientes diferentes para a sua empresa e quiser diferenciar os pagamentos para cada um deles, precisará de 2 endereços estáticos diferentes. Uma solução ingénua, com a abordagem atual, seria o Bob criar duas carteiras separadas, cada uma com o seu próprio endereço estático, ou mesmo estabelecer dois endereços estáticos diferentes dentro da mesma carteira. No entanto, esta solução requer a varredura de todo o blockchain duas vezes (uma para cada endereço), a fim de detetar pagamentos destinados a cada endereço, respetivamente. Este duplo controlo aumenta excessivamente a carga operacional do Bob.

Para resolver este problema, o BIP352 utiliza um sistema de etiquetas que permite diferentes endereços estáticos, sem aumentar excessivamente a carga de trabalho de encontrar pagamentos silenciosos na cadeia de blocos. Para o fazer, adicionamos um número inteiro m à chave pública de despesa B_{\text{spend}}. Este número inteiro pode assumir o valor de 1 para o primeiro endereço estático, depois 2 para o segundo, e assim por diante. As chaves de despesa B_{\text{spend}} serão agora chamadas B_m e serão construídas desta forma:

B_m = B_{\text{spend}} + \text{hash}(b_{\text{scan}} \text{ ‖ } m) \cdot G

Por exemplo, para a primeira chave de despesa com a etiqueta 1 :

B_1 = B_{\text{spend}} + \text{hash}(b_{\text{scan}} \text{ ‖ } 1) \cdot G

O endereço estático publicado pelo Bob consistirá agora em B_{\text{scan}} e B_m. Por exemplo, o primeiro endereço estático com a etiqueta 1 será :

B = B_{\text{scan}} \text{ ‖ } B_1

*Só começamos a partir da etiqueta 1 porque a etiqueta 0 está reservada para a mudança A Alice, por seu lado, obterá o endereço de pagamento único P da mesma forma que anteriormente, mas utilizando o novo B_1 em vez de B_{\text{spend}} :

P_0 = B_1 + \text{hash}(\text{inputHash} \cdot a \cdot B_{\text{scan}} \text{ ‖ } 0) \cdot G

Na realidade, Alice nem sequer sabe necessariamente que Bob tem um endereço etiquetado, pois está simplesmente a utilizar a segunda parte do endereço estático que ele forneceu e, neste caso, é o valor B_1 em vez de B_{text{spend}}.

Para verificar os pagamentos, o Bob utilizará sempre o valor do seu endereço estático inicial com B_{\text{spend}} desta forma:

P_0 = B_{\text{spend}} + \text{hash}(\text{inputHash} \cdot b_{\text{scan}} \cdot A \text{ ‖ } 0) \cdot G

Depois, simplesmente subtrai o valor que encontra para P_0 de cada saída, uma a uma. Em seguida, verifica se um dos resultados destas subtracções corresponde ao valor de uma das etiquetas que está a usar na sua carteira. Se, por exemplo, a saída #4 corresponder à etiqueta 1, isto significa que esta saída é um Pagamento Silencioso associado ao seu endereço estaticamente etiquetado B_1 :

Out_4 - P_0 = \text{hash}(b_{\text{scan}} \text{ ‖ } 1) \cdot G

Funciona porque :

B_1 = B_{\text{spend}} + \text{hash}(b_{\text{scan}} \text{ ‖ } 1) \cdot G

Graças a este método, o Bob pode utilizar uma multiplicidade de endereços estáticos (B_1, B_2, B_3...), todos derivados do seu endereço estático de base (B = B_{\text{scan}} \text{ ‖ } B_{\text{spend}}), de modo a manter a utilização separada.

Note-se, no entanto, que esta separação de endereços estáticos só é válida do ponto de vista da gestão de carteiras pessoais, mas não separa identidades. Uma vez que todos eles têm o mesmo B_{\text{scan}}, é muito fácil associar todos os endereços estáticos e deduzir que pertencem a uma única entidade.

Legenda:

• B_{\text{scan}}: Chave de digitalização pública do Bob (endereço estático)
• b_{\text{scan}} : A chave de digitalização privada do Bob
• B_{\text{spend}} : Chave de despesa pública do Bob (endereço inicial)
• B_m : Chave pública de despesa do Bob identificada (endereço estático)
• b_m: a chave de despesa privada do Bob com o rótulo
• A : Soma das entradas de chave pública (tweak)
• a : A chave privada correspondente à chave pública modificada
• H : O hash do UTXO mais pequeno (lexicograficamente) utilizado como entrada
• G : O ponto gerador da curva elíptica secp256k1
• \text{SHA256} : A função hash SHA256 marcada com BIP0352/SharedSecret
• s_0 : O primeiro segredo comum da ECDH
• P_0 : A primeira chave pública / endereço único para pagamento ao Bob
• p_0 : A chave privada do primeiro endereço de pagamento único para o Bob
• X : O hash da chave privada de digitalização com a etiqueta

Como posso criar um endereço de pagamentos silenciosos?

Para criar um endereço dedicado a pagamentos silenciosos, primeiro é necessário derivar 2 pares de chaves da sua carteira Bitcoin HD:

• O par b_{\text{scan}}, B_{\text{scan}} para procurar pagamentos dirigidos a nós;
• O par b_{\text{spend}}, B_{\text{spend}} para pensar nos bitcoins que recebemos.

Estes pares são derivados utilizando os seguintes caminhos (Bitcoin Mainnet):

scan : m / 352' / 0' / 0' / 1' / 0
spend : m / 352' / 0' / 0' / 0' / 0

Assim que tivermos estes 2 pares de chaves, basta concatená-los (de ponta a ponta) para criar o payload do endereço estático:

B = B_{\text{scan}} \text{ ‖ } B_{\text{gastos}}

Se quisermos utilizar etiquetas, substituímos B_{\text{spend}} por B_m :

$$ B = B_{\text{scan}} \text{ ‖ } B_m $$$

Com a etiqueta m :

B_m = B_{\text{spend}} + \text{hash}(b_{\text{scan}} \text{ ‖ } m) \cdot G

Uma vez que temos este payload, adicionamos o HRP (Human-Readable Part) sp e a versão q (= versão 0). Também adicionamos uma soma de verificação e formatamos o endereço como bech32m.

Por exemplo, aqui está o meu endereço estático de pagamentos silenciosos:

sp1qqvhjvsq2vz8zwrw372vuzle7472zup2ql3pz64yn5cpkw5ngv2n6jq4nl8cgm6zmu48yk3eq33ryc7aam6jrvrg0d0uuyzecfhx2wgsumcurv77e

Um ponto importante em relação aos endereços estáticos, que pode ter compreendido nas secções anteriores, é que estes endereços não são visíveis nas transacções Bitcoin. Apenas os endereços de pagamento P usados nas saídas aparecem no blockchain no formato Taproot padrão. Portanto, do lado de fora, é impossível distinguir uma transação envolvendo Silent Payment de uma transação comum usando saídas P2TR.

Tal como no BIP47, é impossível estabelecer uma ligação entre um endereço estático B e um endereço de pagamento P derivado de B. De facto, mesmo que Eve, um potencial atacante, tente analisar a blockchain com o endereço estático B de Bob, não conseguirá efetuar os cálculos necessários para determinar P. Para o fazer, precisaria ou da chave privada de Bob b_{\text{scan}}, ou das chaves privadas do remetente a, mas ambas são obviamente privadas. Por conseguinte, é possível associar explicitamente o endereço estático de uma pessoa a uma forma de identidade pessoal.

Como é que utilizo os pagamentos silenciosos?

A proposta de Pagamentos Silenciosos é relativamente recente e só foi implementada por um número muito limitado de carteiras neste momento. Tanto quanto sei, existem apenas 3 produtos de software que os suportam:

• CakeWallet
• Silentium
• [DonationWallet] (https://github.com/Sosthene00/donationwallet)

Em breve, iremos fornecer-lhe um tutorial detalhado sobre como configurar o seu próprio endereço estático de pagamentos silenciosos.

Uma vez que esta funcionalidade é nova, aconselhamos-te a ter cuidado e a evitar usar os Pagamentos silenciosos para grandes quantias na rede principal.

Para criar este capítulo sobre Pagamentos Silenciosos, utilizei [o sítio de explicação sobre Pagamentos Silenciosos] (https://silentpayments.xyz/) e [o documento de explicação sobre o BIP352] (https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki).

Seção final

Comentários e classificações

true

Exame final

true

Conclusão

true