Address Clustering agrupa endereços Bitcoin ou scripts de saída aos quais um modelo atribui controlo comum. A blockchain não guarda esses grupos. Nomear um serviço ou pessoa é outro passo, com provas próprias.
O grafo transacional liga saídas realmente gastas às transações que as consomem. Um cluster agrupa ainda nós por controlo inferido. Um pagamento entre endereços não basta para lhes atribuir um proprietário comum; arestas transacionais e vínculos de controlo são diferentes. [Meiklejohn et al. — A Fistful of Bitcoins]
Uma entrada referencia um UTXO anterior, não um campo universal de endereço do remetente. É preciso recuperar o scriptPubKey original e indicar rede e intervalo de blocos. Alguns scripts não têm representação habitual como endereço; convertê-los numa suposta pessoa confundiria objeto técnico e identidade. [Bitcoin Developer Guide — Transactions]
Common-Input Ownership Heuristic liga as entradas. Detetar change pode acrescentar uma saída; escolher erradamente o destinatário funde as partes. Duas saídas não significam automaticamente pagamento e change: podem ser dois destinatários ou transferências entre carteiras próprias. A novidade do endereço não decide sozinha. [Meiklejohn et al. — A Fistful of Bitcoins] [BIP 78 — A Simple Payjoin Proposal]
Tipo de script, montantes redondos e uso anterior podem ser características do modelo, não provas. CoinJoin e Payjoin contrariam alguns pressupostos; as exceções não exigem montantes visivelmente iguais. Mudanças de software ou comportamento alteram erros, pelo que o desempenho histórico exige nova medição para dados atuais. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin] [BIP 78 — A Simple Payjoin Proposal]
Union-find cria grupos transitivos eficientemente. Uma implementação comum não pode simplesmente apagar uma fusão antiga e dividir corretamente o cluster. Guarde arestas, transações e versões de regras; corrigir pode exigir recálculo. Só a lista de membros não preserva o percurso de provas da fusão. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Möser e Narayanan limitam union-find para impedir fusões entre grupos separados por uma saída de pagamento prevista. Isto pode travar cluster collapse, mas depende da própria inferência do pagamento. Uma regra conservadora também pode rejeitar vínculos corretos; menos fusões não descrevem automaticamente melhor todos os proprietários. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Rotular um endereço com um serviço e propagar o rótulo ao cluster são afirmações distintas. Registe origem, período e percurso de propagação; um grupo de uma bolsa não é um cliente. Referências derivadas da mesma heurística não são totalmente independentes. Separe falsas fusões, falsas divisões e cobertura da amostra. [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Reconhecer uma transferência interna pode retirar self-churn das entradas estimadas. Outra versão de grupos pode rever métricas históricas sem alterar a blockchain. Calcule saldos com UTXO ainda não gastos num bloco definido, não todas as saídas historicamente recebidas. Indique versões do modelo e rótulos e corte dos dados. [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Para ter uma visão mais completa, leia este verbete junto com Common-Input Ownership Heuristic, Chain Surveillance, Saída de troco, CoinJoin, PayJoin, UTXO. Também há referências a este verbete em Pseudonimidade, Chain Surveillance, Common-Input Ownership Heuristic, Transaction Labeling.