Agrupamento e a heurística de propriedade comum das entradas

Quase toda afirmação on-chain sobre "quem" se apoia em uma etapa de agrupamento. Quando um relatório diz que uma exchange recebeu 40 BTC ou que um grupo de ransomware controla 300 endereços, a afirmação depende de um método que agrupou endereços e dos erros desse método. Em blockchains UTXO, a maioria dos vínculos de qualquer agrupamento decorre de uma regra: a heurística de propriedade comum das entradas. Ela costuma estar correta e, quando erra, mescla carteiras inteiras. Esta aula aborda o que é agrupamento, por que a regra funciona, quais transações a invalidam e como registrar agrupamentos para que um revisor possa desmontá-los vínculo por vínculo.

Endereços, agrupamentos e entidades

É fácil confundir três níveis:

Agrupamento é a versão, na blockchain, da resolução de entidades, o problema geral de dados que consiste em decidir quais registros se referem à mesma coisa subjacente. O resultado não é um fato lido na blockchain, mas uma inferência construída sobre suposições a respeito de como carteiras e pessoas se comportam. Que uma transação gastou três entradas é um fato registrado; que uma única parte controlava as três é uma conclusão heurística, e o relatório deve manter essa distinção.

Observe a palavra controlados. Uma heurística pode, no máximo, mostrar que as mesmas chaves, ou o mesmo software atuando para um operador, movimentaram os fundos. Uma exchange custodial controla as chaves de milhões de clientes, portanto, um agrupamento rotulado como "Exchange X" representa o serviço, não qualquer um de seus clientes. Controle não é propriedade, e nenhum dos dois é identidade (Aula 4.5).

Como os agrupamentos são construídos

O agrupamento tem duas etapas. Primeiro, heurísticas produzem evidências de vínculo: pares de endereços que, segundo alguma regra, compartilham um controlador. A regra de entradas comuns vincula todas as entradas de uma transação; a detecção de troco vincula um remetente à sua saída de troco (Aula 4.2); blockchains baseadas em contas usam vínculos comportamentais, como endereços de depósito compartilhados (Aula 4.3). Em seguida, o analista calcula o fecho transitivo desses vínculos: se A está vinculado a B e B a C, então A, B e C formam um agrupamento, embora nenhuma evidência isolada conecte A e C. Em termos de grafos, os agrupamentos são os componentes conexos do grafo de evidências.

Por exemplo, a transação 4f3a…c21e gasta fundos dos endereços a1 e a2, e a transação 9b7d…e014, uma semana depois, de a2 e a3. A regra produz os vínculos a1–a2 e a2–a3; o fecho produz um agrupamento {a1, a2, a3}. O vínculo a1–a3 nunca foi observado; ele é herdado. Se qualquer uma das transações era, na verdade, colaborativa, com dois proprietários, todo o agrupamento está errado, não apenas um vínculo.

A heurística de propriedade comum das entradas

A lógica

Para gastar um UTXO, uma transação deve fornecer um script de desbloqueio ou uma testemunha válida para ele, na prática, uma assinatura da chave que o controla; portanto, três entradas precisam de assinaturas para três moedas. No uso comum, uma carteira seleciona moedas de seu próprio saldo e assina todas elas. Assim, se vários endereços aparecem como entradas de uma transação, a explicação mais provável é que uma carteira e, portanto, um controlador detenha todas as suas chaves.

A ideia é tão antiga quanto o Bitcoin: a seção sobre privacidade do white paper de 2008 alerta que transações com múltiplas entradas "necessariamente revelam que suas entradas pertenciam ao mesmo proprietário". Reid e Harrigan (2011) a usaram para construir uma rede de usuários, e Meiklejohn et al. (2013, "Por um Punhado de Bitcoins") a enunciaram como sua Heurística 1: se dois ou mais endereços são entradas da mesma transação, eles são controlados pelo mesmo usuário. Ela também é chamada de heurística de propriedade comum das entradas (CIOH) ou heurística de múltiplas entradas.

Um exemplo resolvido

Uma transação decodificada, simplificada para 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 totalizam 0,0830 BTC e as saídas, 0,0828 BTC; portanto, a taxa é de 0,0002 BTC (20.000 satoshis). A regra de entradas comuns vincula bc1q…k3f7, bc1q…m9a2 e bc1q…x0d1. Ela nada diz sobre as saídas: determinar se bc1q…r4t6 é troco pertencente à mesma carteira é uma inferência separada e muito mais fraca (Aula 4.2).

Se bc1q…m9a2 já estava em um agrupamento de 2.000 endereços e bc1q…x0d1 em um agrupamento de 300, essa única transação os mescla em um agrupamento de 2.301 endereços. Esse é o poder da regra e seu perigo.

A regra é mais forte quando se trata de serviços. Exchanges custodiais e processadores de pagamento consolidam periodicamente muitos depósitos pequenos em uma saída, uma transação de convergência que pode gastar fundos de 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 agrupamentos de serviços crescem até milhões de endereços e pela qual um depósito verificado costuma bastar para rotulá-los (Aula 4.5). Um usuário que combina uma dúzia de moedas antigas para economizar taxas futuras revela, da mesma forma, que uma carteira detinha todas elas. Ambos os casos estão corretos desde que ninguém mais tenha contribuído com uma entrada.

Qual é sua eficácia

Meiklejohn et al. aplicaram a regra à blockchain completa em 2013 e reduziram 12.056.684 chaves públicas a cerca de 5,58 milhões de agrupamentos. Nick (2015, em uma dissertação de mestrado) obteve raros dados de referência comprovados a partir de um vazamento de privacidade nos filtros de Bloom de carteiras leves, que expôs os conjuntos de endereços de carteiras reais; a regra de entradas comuns identificou mais de 69% dos endereços nessas 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 para transações comuns, mas isso é uma suposição sobre o comportamento das carteiras, que as transações abaixo violam (a Aula 4.4 aborda a medição da qualidade dos agrupamentos).

Onde a suposição falha

CoinJoin. Vários usuários combinam realizar uma única transação; cada um contribui com entradas e assina apenas as suas, e as saídas normalmente incluem várias de valor idêntico, de modo que ninguém consiga determinar qual saída pertence a quem. Aplicar a regra de entradas comuns mescla as carteiras de todos os participantes, o que é precisamente o vínculo falso que o CoinJoin foi projetado para induzir (Aula 6.2).

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 e do destinatário, e o valor aparente do pagamento também é distorcido. Um PayJoin bem construído não pode ser distinguido de forma confiável de uma transação normal, portanto, sua existência impõe um limite à força de 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 multipartes. Aberturas de canais Lightning com financiamento de ambas as partes, alguns protocolos de troca e processamento em lote e transações assinadas com SIGHASH_ANYONECANPAY, que permite que outros adicionem entradas após a primeira assinatura (usado, por exemplo, em contratos no estilo de financiamento coletivo), têm entradas de várias partes.

Controle compartilhado. Um endereço multisig mantido conjuntamente por várias pessoas é um único "proprietário" no sentido do script; a entidade correta é o arranjo conjunto, não qualquer signatário individual.

Custódia e importação de chaves. Um serviço custodial gasta depósitos de clientes em conjunto, portanto, seu agrupamento está correto para o serviço, mas nada diz sobre os clientes. Carteiras que permitem aos usuários importar ou varrer chaves privadas recebidas de terceiros (carteiras de papel, cartões-presente) podem vincular moedas que tinham proprietários diferentes. Harrigan e Fretter ("A Eficácia Surpreendente do Agrupamento de Endereços", 2016) excluíram o maior agrupamento de Bitcoin, com mais de 10 milhões de endereços originalmente pertencentes à Mt. Gox, exatamente por esse motivo.

Agrupamentos não são entidades

A correspondência entre agrupamentos e entidades do mundo real falha nas duas direções.

• Uma entidade, muitos agrupamentos (mesclagem insuficiente). As carteiras frias de uma exchange podem nunca ter seus fundos gastos em conjunto com os de suas carteiras quentes; uma pessoa pode usar três aplicativos de carteira sem relação entre si; em blockchains baseadas em contas, sem gastos com múltiplas entradas, um operador frequentemente aparece como dezenas de endereços desconectados.
• Um agrupamento, muitas entidades (mesclagem excessiva). CoinJoins, a combinação de fundos sob custódia e a importação de chaves, conforme descrito acima, unem carteiras que pertencem a pessoas diferentes.

Os agrupamentos também mudam ao longo do tempo: um agrupamento calculado no bloco 800.000 pode se mesclar com outro até o bloco 850.000. Todo agrupamento é um retrato de um momento e deve trazer a altura do bloco na qual foi calculado.

Falsos positivos, falsos negativos e como os erros se propagam

Um vínculo falso positivo une endereços que não são controlados pela mesma parte; um falso negativo é um vínculo real que o método não detectou. Seus custos recaem sobre usuários diferentes:

Nenhum conjunto de heurísticas é o melhor para todos: uma equipe de conformidade que bloqueia transações com base em rótulos de agrupamentos deve priorizar a precisão; um investigador que está gerando pistas pode aceitar mais falsos positivos, desde que cada pista seja verificada antes de chegar a um relatório.

Os erros de agrupamento não são proporcionais ao número de vínculos incorretos. Como os agrupamentos são fechos transitivos, um único vínculo falso entre um agrupamento de 5.000 endereços e outro de 40.000 produz um agrupamento de 45.000, e todos os endereços passam a compartilhar qualquer rótulo que um dos lados possuía. Os erros também se acumulam com o tamanho. Se cada vínculo tem, de forma independente, uma probabilidade p de estar errado, um agrupamento montado a partir de n vínculos está livre de erros com probabilidade (1 − p)^n. Com p = 0,001 e n = 1.000 vínculos, isso é 0,999^1.000 ≈ 0,37: uma chance de 63% de que o agrupamento contenha pelo menos uma mesclagem falsa. Portanto, agrupamentos grandes têm maior probabilidade de estar contaminados, justamente onde os analistas tendem a depositar mais confiança. Meiklejohn et al. constataram que uma versão ingênua de sua heurística de troco produziu um superagrupamento de 1,6 milhão de chaves públicas contendo Mt. Gox, Instawallet, BitPay e Silk Road (a Aula 4.4 aborda esses superagrupamentos). Nas etapas seguintes, o rótulo mesclado altera estatísticas de fluxo e pontuações de risco, e um relatório acaba apresentando uma conclusão que as evidências não sustentam, por meio de etapas que, individualmente, pareciam razoáveis.

Salvaguardas e registro das evidências

Faça a triagem e monitore antes de vincular

1. Exclua prováveis CoinJoins na triagem. O teste mais simples procura várias saídas de valor exatamente igual:

-- Sinalize possíveis CoinJoins para que suas entradas não sejam vinculadas
WITH same_value AS (
  SELECT transaction_hash, value, COUNT(*) AS n_equal
  FROM outputs
  GROUP BY transaction_hash, value
),
shape AS (
  SELECT t.hash AS transaction_hash, t.input_count,
         MAX(s.n_equal) AS max_equal_outputs
  FROM transactions t
  JOIN same_value s ON s.transaction_hash = t.hash
  GROUP BY t.hash, t.input_count
)
SELECT transaction_hash
FROM shape
WHERE input_count >= 2
  AND max_equal_outputs >= 3;  -- ajuste este limiar 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 múltiplas entradas nas quais pelo menos três saídas são idênticas. O limiar depende de julgamento. A consulta também captura alguns pagamentos em lote de exchanges com valores iguais; excluí-los custa apenas alguns vínculos (um falso negativo), o erro mais seguro. Ela não detecta modelos de CoinJoin que evitam saídas iguais, portanto, é um filtro, não um detector; pesquisas de agrupamento como a de Goldfeder et al. (2018) acrescentam uma exclusão de CoinJoin pelo mesmo motivo.

1. Sinalize combinações incomuns de entradas. Entradas de tipos de script diferentes (por exemplo, uma entrada P2PKH legada ao lado de uma entrada P2TR) são incomuns em um único software de carteira e merecem uma segunda análise.
2. Monitore as mesclagens. Revise qualquer vínculo que mesclaria dois agrupamentos grandes ou dois agrupamentos com rótulos diferentes. Harrigan e Fretter observaram que agrupamentos grandes raramente se mesclam naturalmente, portanto, uma mesclagem desse tipo é um sinal de alerta. Revise também qualquer agrupamento que cresça acentuadamente entre retratos de momentos distintos.

Guarde as evidências, não apenas os agrupamentos

Armazene uma linha por evidência de vínculo:

-- Uma linha por evidência de vínculo, não uma linha por agrupamento
CREATE TABLE cluster_evidence (
  addr_a        VARCHAR NOT NULL,
  addr_b        VARCHAR NOT NULL,
  heuristic     VARCHAR NOT NULL,  -- p. ex. 'common_input', 'change_v3'
  evidence_tx   VARCHAR NOT NULL,  -- txid ou hash da transação
  block_height  BIGINT  NOT NULL,
  strength      VARCHAR            -- 'high', 'moderate' ou 'low' (veja a tabela abaixo)
);

-- Reconstrua os agrupamentos apenas com as evidências mais fortes
SELECT addr_a, addr_b
FROM cluster_evidence
WHERE heuristic = 'common_input'
  AND strength = 'high';

Como os agrupamentos são derivados dessa tabela, o analista pode reconstruí-los com um conjunto de heurísticas mais rigoroso ou mais flexível, remover uma transação posteriormente identificada como CoinJoin ou PayJoin e ver o que se desfaz, ou mostrar a um revisor por que dois endereços acabaram juntos. Calcular componentes conexos é trabalhoso em SQL puro (CTEs recursivas funcionam, mas não escalam bem); a maioria das equipes exporta as arestas selecionadas para uma biblioteca de grafos ou uma rotina union-find. A geração dos pares de entrada em escala, com a mesma exclusão de CoinJoin, é abordada na Aula 2.9 (os nomes de colunas aqui seguem o esquema UTXO daquela aula).

Força e elaboração de relatórios

Na escala A–D do curso (Aula 3.2), todo vínculo de entradas comuns é de grau C, uma única heurística, independentemente de sua linha aqui; a tabela classifica a força dos vínculos dentro desse grau e determina quais podem transmitir rótulos (Aula 4.5). O curso reserva a palavra "confiança" para a base de um julgamento apresentado em relatório (Aula 9.2), portanto, vínculos heurísticos são avaliados por força. Identifique e date o conjunto de heurísticas, as exclusões, os limiares e a altura do bloco do retrato que embasam cada agrupamento citado. Escreva "endereços agrupados pela heurística de entradas comuns, com filtro de CoinJoin ativado, rotulados como Serviço X com base em um depósito de teste", em vez de "carteira do Serviço X" (a Aula 9.2 aborda a linguagem dos relatórios). Por fim, teste a sensibilidade: execute novamente as principais análises sem a heurística mais fraca e informe se as conclusões continuam válidas.

Foco no exame: a diferença entre endereço, agrupamento e entidade, e controle versus propriedade em serviços custodiais; agrupamento como resolução de entidades e como fecho transitivo (componentes conexos) de evidências de vínculo; por que entradas gastas em conjunto implicam um controlador compartilhado e a origem da regra (white paper, Heurística 1 de Meiklejohn et al.); revocação versus precisão nas evidências dos filtros de Bloom (mais de 69% dos endereços das carteiras encontrados); as exceções (CoinJoin, PayJoin conforme a BIP 78, canais com financiamento de ambas as partes, SIGHASH_ANYONECANPAY, multisig, custódia e importação de chaves); mesclagem insuficiente e excessiva; os diferentes custos de falsos positivos e falsos negativos; por que um vínculo falso mescla agrupamentos inteiros e propaga rótulos, e o raciocínio de (1 − p)^n; triagem de saídas de mesmo valor com um limiar documentado; armazenamento de evidências com heurística, transação e altura do bloco para que os agrupamentos possam ser reconstruídos.