Address Clustering

Ana usa endereços novos para recebimentos diferentes e depois paga uma loja com sua carteira. Uma carteira é um aplicativo ou dispositivo para receber e enviar bitcoins. O analista vê dinheiro circulando, mas deve separar duas perguntas: quais fundos foram gastos e quais endereços podem ter o mesmo controlador? O pagamento à loja responde à primeira. Não basta para colocar Ana e a loja no mesmo grupo. Address Clustering busca outras pistas, como gastar vários recebimentos juntos. O diagrama de pagamentos mostra vínculos reais entre transações; os grupos coloridos já acrescentam uma interpretação. Essa distinção é essencial para ler esses mapas. [1] [5]

Os fundos recebidos anteriormente existem como UTXO, saídas de transações ainda não gastas. Cada saída registra um valor e as condições para gastá-lo. Uma entrada nova aponta para uma saída anterior específica, não para um campo universal de “endereço do remetente”. A ferramenta recupera o scriptPubKey original, que descreve suas condições de gasto. Nos tipos compatíveis, o endereço representa essas condições de forma conveniente; nem todo script possui um endereço convencional. Uma explicação cuidadosa deve dizer se agrupa endereços ou scripts e informar a rede e os blocos examinados. Um bloco reúne transações em um lote acrescentado ao histórico compartilhado. Um identificador técnico não se torna, por isso, a identidade de alguém. [4] [6]

A Common-Input Ownership Heuristic presume controle comum de várias entradas de uma transação. Identificar change é outro passo: procura-se a saída que devolve ao pagador o restante após o pagamento e a taxa. Um acerto pode ligar o novo endereço de troco de Ana aos recebimentos anteriores. Confundir o pagamento à loja com change liga fundos alheios. Duas saídas não revelam suas funções por si sós. Podem representar dois destinatários ou transferências entre carteiras próprias. Um endereço nunca visto também não prova que pertence ao pagador. [1] [3]

Um valor arredondado, um tipo de script ou um endereço reutilizado podem ser pistas, não regras imutáveis. Uma atualização de carteira pode montar transações de outra forma e fazer um modelo antigo errar. CoinJoin permite uma transação entre vários participantes; no Payjoin descrito em BIP 78, o destinatário pode acrescentar entradas próprias. A colaboração não exige saídas com valores iguais. Portanto, a precisão medida no passado não pode ser prometida para transações atuais sem nova avaliação. Também importa saber em quais casos o método não faz previsão. [2] [3]

Imagine dois grupos de endereços antes separados. Uma ligação errada pode uni-los e espalhar o erro por todos os membros. Programas costumam usar union-find, uma estrutura de dados que acompanha grupos conectados, para realizar uniões rapidamente. Sua forma convencional não remove uma ligação antiga e separa automaticamente o resultado de maneira correta. Para tornar a análise verificável, a recomendação prática é guardar transações, ligações individuais e versões das regras, não apenas a lista final. Isso decorre da propagação de erros descrita na pesquisa: corrigir pode exigir novo cálculo, não só mudar o nome do grupo. [2]

Malte Möser e Arvind Narayanan estudam como evitar cluster collapse, a fusão incorreta de muitos grupos em um enorme. Seu constrained union-find recusa unir grupos ligados por uma saída prevista como pagamento. No exemplo de Ana, estimar que ela paga à loja pode impedir uma união posterior das duas partes. Essa proteção, porém, não conhece a verdade de forma independente: depende da previsão do pagamento e pode recusar ligações válidas. Menos uniões não produzem automaticamente uma imagem completa ou sem erros dos proprietários. [2]

Rotular um endereço com o nome de uma corretora e estender o rótulo a um cluster inteiro são etapas distintas. O rótulo precisa de fonte, período de validade e um caminho verificável de propagação. Um grupo controlado por uma corretora pode atender muitos clientes. A validação do modelo também não deve depender apenas de dados criados pela mesma suposição. Uniões incorretas, relações não identificadas e cobertura da amostra precisam de avaliações separadas. Muitos endereços rotulados não garantem atribuições corretas. [1] [2]

Ana pode transferir fundos entre duas carteiras próprias. Se o modelo não as relaciona, pode contar o movimento como pagamento entre entidades diferentes. Um agrupamento melhor pode reconhecê-lo como transferência interna, ou self-churn, reduzindo o volume estimado sem alterar a história da blockchain. Da mesma forma, o saldo de um cluster corresponde aos seus UTXO ainda não gastos em um bloco determinado; somar todos os recebimentos antigos incluiria dinheiro já gasto. Ao comparar gráficos, confira a data, a versão do modelo, os rótulos e o corte dos dados. [1] [2]