A heurística de propriedade por entrada comum

A heurística de propriedade por entrada comum é a regra de agrupamento mais antiga e mais usada em redes UTXO. Ela produz a maioria dos vínculos em qualquer cluster de Bitcoin, costuma estar correta e, quando está errada, erra de maneiras que podem unir carteiras inteiras. Um analista precisa saber tanto por que ela funciona quanto exatamente quais transações a invalidam.

A lógica

Para gastar um UTXO, uma transação precisa fornecer um script de desbloqueio ou testemunha válido para essa saída, o que, na prática, significa uma assinatura da chave que a controla. Portanto, uma transação com três entradas precisa de assinaturas para três moedas. No uso comum, uma carteira monta um pagamento selecionando moedas do próprio saldo e assinando todas elas. Assim, se vários endereços aparecem como entradas da mesma transação, a explicação mais provável é que uma carteira — e, portanto, um controlador — detém as chaves de todos eles.

A ideia é tão antiga quanto o Bitcoin. A seção sobre privacidade do white paper de 2008 já alerta que transações com várias entradas “necessariamente revelam que suas entradas pertenciam ao mesmo proprietário”. Reid e Harrigan (2011, “Uma análise do anonimato no sistema Bitcoin”) usaram essa ideia para construir uma rede de usuários, e Meiklejohn et al. (2013, “Um punhado de bitcoins”) a apresentaram como sua Heurística 1: se dois ou mais endereços forem entradas da mesma transação, eles são controlados pelo mesmo usuário. A regra também é chamada de heurística de propriedade por entrada comum (CIOH) ou heurística de múltiplas entradas.

Um exemplo detalhado

Veja uma transação decodificada, simplificada para mostrar os campos relevantes ao agrupamento (identificadores truncados):

{
  "txid": "7c1e…40ab",
  "vin": [
    {"prevout": "a91f…03:1", "address": "bc1q…k3f7", "value_btc": 0.0400},
    {"prevout": "e2c8…7d:0", "address": "bc1q…m9a2", "value_btc": 0.0250},
    {"prevout": "51b0…e9:4", "address": "bc1q…x0d1", "value_btc": 0.0180}
  ],
  "vout": [
    {"n": 0, "address": "bc1q…p2w8", "value_btc": 0.0700},
    {"n": 1, "address": "bc1q…r4t6", "value_btc": 0.0128}
  ]
}

As três entradas somam 0,0830 BTC; as saídas somam 0,0828 BTC, portanto a taxa é de 0,0002 BTC (20.000 satoshis). A regra de entrada comum cria vínculos entre bc1q…k3f7, bc1q…m9a2 e bc1q…x0d1. Ela não diz nada sobre as saídas: determinar se bc1q…r4t6 é troco pertencente à mesma carteira é uma inferência separada e muito mais fraca, abordada na aula Heurísticas de detecção de troco.

Se bc1q…m9a2 já estivesse em um cluster de 2.000 endereços e bc1q…x0d1 em um cluster de 300, essa única transação os uniria em um cluster de 2.301 endereços. Esse é o alcance da regra — e também seu perigo.

A regra é mais forte no caso de serviços. Exchanges custodiais e processadores de pagamento consolidam periodicamente muitos depósitos pequenos em uma única saída, em uma transação de agregação de entradas que pode gastar centenas de endereços de depósito de uma só vez. Cada varredura vincula todos esses endereços à carteira do serviço, razão pela qual os clusters de serviços crescem até milhões de endereços e por que um único depósito verificado costuma ser suficiente para rotulá-los (veja a aula Atribuição e rotulagem). As consolidações feitas por usuários comuns funcionam da mesma maneira, em menor escala: uma carteira que reúne uma dúzia de moedas antigas para economizar em taxas futuras revela que as detinha todas. Os dois casos se baseiam na mesma suposição — que apenas uma parte assinou — e ambos estão corretos desde que ninguém mais tenha contribuído com uma entrada.

O quanto funciona

As evidências sobre a precisão são limitadas, mas consistentes. Meiklejohn et al. aplicaram a regra a toda a cadeia em 2013 e reduziram 12.056.684 chaves públicas a cerca de 5,58 milhões de clusters. Nick (2015, uma dissertação de mestrado sobre desanonimização orientada por dados no Bitcoin) obteve dados reais raros por meio de um vazamento de privacidade nos filtros Bloom usados por carteiras leves, que expôs os conjuntos de endereços de carteiras reais; a regra de entrada comum identificou mais de 69% dos endereços dessas carteiras. Observe o que esse número mede: revocação (quanto de cada carteira foi encontrado), não precisão (quantos vínculos estavam corretos). Em geral, considera-se que a regra tem alta precisão em transações comuns, mas isso é uma suposição sobre o comportamento das carteiras, e as transações a seguir a violam.

Onde a suposição falha

CoinJoin. Vários usuários concordam em participar de uma única transação; cada um contribui com entradas e assina apenas as próprias, e as saídas normalmente incluem várias de valor idêntico, de modo que ninguém consegue saber a quem pertence cada saída. Aplicar a regra de entrada comum une as carteiras de todos os participantes, criando exatamente o vínculo falso que o CoinJoin foi projetado para induzir. Veja a aula Mixers, CoinJoin e ofuscação em grafos para saber como essas transações aparecem em um grafo.

PayJoin. Em um PayJoin (BIP 78), o destinatário de um pagamento adiciona uma de suas próprias entradas à transação do remetente. O resultado parece um pagamento comum com duas entradas, portanto a regra vincula as moedas do remetente às do destinatário, e o valor aparente do pagamento também fica distorcido. Não é possível distinguir de forma confiável um PayJoin bem construído de uma transação normal, então sua existência estabelece um limite para a confiança em qualquer vínculo isolado. Sua adoção tem sido baixa, o que limita o dano geral, mas não o descarta em um caso específico.

Outras transações multipartidárias. Qualquer protocolo em que duas ou mais partes contribuam com entradas invalida a regra: aberturas de canais Lightning financiados por duas partes, alguns protocolos de swap e de agrupamento de pagamentos e transações assinadas com SIGHASH_ANYONECANPAY, que permite que outras pessoas adicionem entradas após a primeira assinatura (usado, por exemplo, em contratos de financiamento coletivo).

Controle compartilhado. Um endereço multisig mantido em conjunto por várias pessoas é um único “proprietário” no sentido do script, mas corresponde a várias pessoas na realidade. A entidade correta é o arranjo conjunto, não qualquer signatário individual.

Custódia e importação de chaves. Um serviço custodial gasta juntos os depósitos de clientes; portanto, seu cluster está correto para o serviço, mas nada revela sobre os clientes. Carteiras que permitem aos usuários importar ou varrer chaves privadas recebidas de outras pessoas (carteiras de papel, cartões-presente) podem vincular moedas que tinham proprietários diferentes; o cluster da Mt. Gox mencionado na aula O que é agrupamento e por que ele importa é o caso mais conhecido.

Medidas de proteção

Cinco práticas mantêm a regra útil.

1. Filtre possíveis CoinJoins antes de criar vínculos. O teste mais simples procura várias saídas exatamente do mesmo valor.

-- Sinaliza possíveis CoinJoins para que suas entradas não sejam vinculadas
WITH same_value AS (
  SELECT tx_id, value_sat, COUNT(*) AS n_equal
  FROM outputs
  GROUP BY tx_id, value_sat
),
shape AS (
  SELECT t.tx_id, t.input_count, MAX(s.n_equal) AS max_equal_outputs
  FROM transactions t
  JOIN same_value s ON s.tx_id = t.tx_id
  GROUP BY t.tx_id, t.input_count
)
SELECT tx_id
FROM shape
WHERE input_count >= 2
  AND max_equal_outputs >= 3;  -- ajuste esse limite e documente-o

A consulta conta, por transação, quantas saídas compartilham cada valor, mantém o maior desses grupos e sinaliza transações com várias entradas nas quais pelo menos três saídas são idênticas. O limite é uma decisão de julgamento. A consulta também detectará alguns pagamentos em lote de exchanges que, por acaso, paguem valores iguais; excluí-los custa apenas alguns vínculos (um falso negativo), o que é o erro mais seguro. Ela não detectará projetos de CoinJoin que evitem saídas de valores iguais, por isso é um filtro, não um detector. Ferramentas de pesquisa usam regras mais sofisticadas; Goldfeder et al. (2018, “Quando o cookie encontra a blockchain”) adicionaram uma exclusão de CoinJoin ao agrupamento justamente por esse motivo.

1. Sinalize combinações de entradas incomuns. Entradas de tipos de script diferentes (por exemplo, uma entrada P2PKH legado ao lado de uma entrada P2TR) são incomuns em softwares de carteira individual e merecem uma segunda análise.

1. Monitore as fusões. Revise qualquer vínculo que uniria dois clusters grandes ou dois clusters com rótulos diferentes. Harrigan e Fretter (2016, “A eficácia extraordinária do agrupamento de endereços”) observaram que é raro dois clusters grandes se unirem naturalmente, portanto uma fusão desse tipo é um sinal de alerta.

1. Mantenha a transação como evidência de cada vínculo. Se uma transação mais tarde for identificada como CoinJoin ou PayJoin, seus vínculos poderão ser removidos e os clusters, reconstruídos.

1. Informe a regra, não apenas o resultado. Declare que um cluster foi construído com a regra de entrada comum, quais exclusões foram aplicadas e em que altura de bloco.

Níveis de confiança

A geração dos pares de endereços a partir de tabelas de entradas em SQL e a inicialização de clusters com esses pares são abordadas na aula Consultando dados UTXO.

Foco no exame: por que entradas gastas juntas implicam um controlador compartilhado (cada entrada precisa da própria assinatura válida, e as carteiras selecionam moedas do próprio saldo); a regra como Heurística 1 de Meiklejohn et al. e suas raízes no white paper; revocação versus precisão nas evidências dos filtros Bloom (mais de 69% dos endereços das carteiras encontrados); as principais exceções (CoinJoin, PayJoin conforme BIP 78, canais financiados por duas partes, SIGHASH_ANYONECANPAY, multisig, custódia e importação de chaves); por que um único vínculo pode unir dois clusters inteiros; filtrar saídas de valores iguais antes de criar vínculos e documentar o limite; revisar fusões grandes ou entre clusters com rótulos conflitantes.