Address Clustering agrupa direcciones Bitcoin o scripts de salida que un modelo atribuye a control común. La cadena no almacena esos grupos. Nombrar un servicio o persona es otro paso con pruebas propias.
El grafo transaccional conecta salidas realmente gastadas con las transacciones que las consumen. Un cluster agrupa además nodos según control inferido. Un pago entre dos direcciones no basta para asignarlas a un propietario; las aristas de pago y los vínculos de control son distintos. [Meiklejohn et al. — A Fistful of Bitcoins]
Una entrada referencia un UTXO previo, no un campo universal de dirección del emisor. Hay que recuperar el scriptPubKey original e indicar red y rango de bloques. Algunos scripts carecen de representación habitual como dirección; convertirlos en una supuesta persona confundiría objeto técnico e identidad. [Bitcoin Developer Guide — Transactions]
Common-Input Ownership Heuristic conecta las entradas. Detectar change puede añadir una salida; elegir erróneamente al destinatario fusiona ambas partes. Dos salidas no implican automáticamente pago y change: pueden ser dos destinatarios o traslados entre carteras propias. La novedad de una dirección no decide por sí sola. [Meiklejohn et al. — A Fistful of Bitcoins] [BIP 78 — A Simple Payjoin Proposal]
Tipo de script, importes redondos y uso previo pueden ser características del modelo, no pruebas. CoinJoin y Payjoin vulneran supuestos comunes; las excepciones no necesitan importes visiblemente iguales. Cambios de software o comportamiento alteran errores, por lo que el rendimiento histórico no se traslada al presente sin medirlo de nuevo. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin] [BIP 78 — A Simple Payjoin Proposal]
Union-find forma grupos transitivos eficientemente. Una implementación ordinaria no puede borrar una unión pasada y dividir correctamente el cluster resultante. Conserve aristas originales, transacciones y versiones de reglas; corregir puede requerir recalcular. Una lista de miembros no conserva la cadena de evidencia que produjo la fusión. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Möser y Narayanan restringen union-find para impedir unir grupos separados por una salida de pago predicha. Esto puede frenar cluster collapse, pero depende de la inferencia del pago. Una regla conservadora puede rechazar vínculos válidos; menos fusiones no describen automáticamente mejor a todos los propietarios. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Etiquetar una dirección con un servicio y extender la etiqueta al cluster son afirmaciones distintas. Registre procedencia, período y ruta de propagación; un grupo de una plataforma de intercambio no es un cliente. Referencias derivadas de la misma heurística no son plenamente independientes. Distinga fusiones falsas, divisiones falsas y cobertura. [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Reconocer un traslado interno puede excluir self-churn de las entradas estimadas. Otra versión de clusters puede revisar una métrica histórica sin cambiar la cadena. Calcule el saldo con los UTXO aún no gastados del grupo en un bloque concreto, no sumando todas las salidas recibidas históricamente. Indique versiones de modelo y etiquetas y corte de datos. [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Para obtener la imagen más completa, lee esta entrada junto con Common-Input Ownership Heuristic, Chain Surveillance, Salida de cambio, CoinJoin, PayJoin, UTXO. También enlazan con esta entrada Seudonimidad, Chain Surveillance, Common-Input Ownership Heuristic, Transaction Labeling.