Address Clustering

Ana utiliza direcciones nuevas para distintos cobros y después paga en una tienda con su cartera. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. El analista ve dinero en movimiento, pero debe separar dos preguntas: ¿qué fondos se gastaron y qué direcciones podrían estar bajo el mismo control? El pago a la tienda responde a la primera. No basta para agrupar a Ana con el comercio. Address Clustering busca otras pistas, como gastar juntos varios cobros. Un diagrama de pagos muestra relaciones reales entre transacciones; los grupos coloreados añaden una interpretación. Distinguir ambas cosas es esencial para leer estos mapas. [1] [5]

Los fondos recibidos anteriormente existen como UTXO, salidas de transacciones aún sin gastar. Cada salida registra un importe y las condiciones para gastarlo. Una entrada nueva apunta a una salida anterior concreta, no a una casilla universal de «dirección del remitente». La herramienta recupera su scriptPubKey original, que expresa las condiciones para gastarla. En los tipos compatibles, una dirección representa esas condiciones de forma cómoda; no todos los scripts tienen una dirección convencional. Una explicación rigurosa debe aclarar si agrupa direcciones o scripts e indicar la red y los bloques estudiados. Un bloque agrupa transacciones en un lote que se añade al historial compartido. Un identificador técnico no se convierte así en la identidad de una persona. [4] [6]

La Common-Input Ownership Heuristic supone control común de varias entradas de una transacción. Identificar change es otro paso: busca la salida que devuelve al pagador lo que sobra tras el pago y la comisión. Si acierta, puede relacionar la nueva dirección de cambio de Ana con cobros anteriores. Si confunde el pago a la tienda con change, une fondos ajenos. Dos salidas no revelan por sí solas sus funciones. Pueden corresponder a dos destinatarios o a transferencias entre carteras propias. Una dirección nunca vista tampoco demuestra que pertenezca al pagador. [1] [3]

Un importe redondeado, el tipo de script o una dirección reutilizada son pistas, no leyes inmutables. Una actualización de cartera puede construir transacciones de otra manera y hacer fallar un modelo antiguo. CoinJoin permite colaborar a varios participantes; con Payjoin según BIP 78, el destinatario también puede añadir entradas propias. La colaboración no exige salidas con importes iguales. Por eso no se puede prometer una precisión histórica para transacciones actuales sin una nueva evaluación. También importa en qué casos el método no ofrece predicción. [2] [3]

Imaginemos dos grupos de direcciones separados. Un solo vínculo erróneo puede unirlos y extender el error a todos sus miembros. Para unir grupos con rapidez, los programas suelen usar union-find, una estructura de datos que registra grupos conectados. Su forma habitual no permite retirar una relación antigua y dividir automáticamente el resultado de manera correcta. Para poder auditar el análisis conviene conservar transacciones, vínculos individuales y versiones de reglas, no solo la lista final. Es una consecuencia práctica de la propagación de errores descrita en la investigación: corregir puede exigir recalcular, no simplemente renombrar el grupo. [2]

Malte Möser y Arvind Narayanan estudian el cluster collapse, la fusión incorrecta de muchos grupos en uno enorme. Su constrained union-find rechaza unir grupos conectados por una salida que el modelo considera un pago. En el ejemplo de Ana, estimar que paga a la tienda puede impedir unir después ambas partes. Pero esa protección no conoce la verdad de forma independiente: depende de la estimación del pago y puede rechazar vínculos correctos. Menos uniones no ofrecen automáticamente un retrato completo ni libre de errores de los propietarios. [2]

Etiquetar una dirección con el nombre de una plataforma y extenderlo a todo un cluster son dos pasos distintos. La etiqueta necesita una fuente, un período de validez y una ruta de propagación comprobable. Un grupo controlado por una plataforma puede servir a muchos clientes. La validación del modelo tampoco debería depender solo de datos creados con el mismo supuesto. Deben evaluarse por separado las uniones erróneas, los vínculos omitidos y la cobertura de la muestra. Muchas direcciones etiquetadas no garantizan atribuciones correctas. [1] [2]

Ana puede mover fondos entre dos carteras propias. Si el modelo no las relaciona, podría contar el movimiento como un pago entre entidades distintas. Una agrupación mejorada puede reconocerlo como traslado interno, o self-churn, y reducir el volumen estimado sin cambiar la historia de la blockchain. Del mismo modo, el saldo de un cluster son sus UTXO todavía sin gastar en un bloque concreto; sumar todos los cobros antiguos incluiría dinero ya gastado. Al comparar gráficos, revise la fecha, la versión del modelo, las etiquetas y el corte de los datos. [1] [2]