157 / 736CIOH

Common-Input Ownership Heuristic

Por qué gastar juntos sugiere un control común

Cuando una cartera reúne varios cobros en un pago, revela una nueva relación entre ellos. Un analista puede deducir un control común, pero una transacción compartida no implica necesariamente un solo propietario.

La Common-Input Ownership Heuristic supone que varias entradas de una transacción de Bitcoin —referencias a importes anteriores que se están gastando— suelen estar controladas por la misma entidad. Utiliza el comportamiento de las carteras para encontrar direcciones relacionadas. Es una pista analítica, no una regla de Bitcoin ni una prueba de propiedad.

Pedro recibe dos pagos en direcciones distintas. Más tarde, al pagar la reparación de su bicicleta, la cartera gasta ambos cobros juntos. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. Un observador ve ahora una relación antes invisible: alguien pudo gastar esos fondos en una transacción. En una cartera personal corriente, resulta razonable sospechar un control común. Ese comportamiento sostiene la heurística, una regla práctica de estimación. Sin embargo, Bitcoin no exige que todas las entradas tengan el mismo propietario. Tampoco un mayor número de entradas indica por sí solo la probabilidad de que la deducción sea correcta. [1] [6]

Los fondos recibidos existen como UTXO, salidas aún sin gastar de transacciones anteriores. Cada salida registra un importe y las condiciones para gastarlo. Cada entrada nueva apunta a una salida concreta. El analista recupera sus condiciones de gasto, escritas en un script, un pequeño programa que establece las reglas de gasto, y vincula la dirección o el script correspondiente con los de las demás entradas. Ese es el alcance preciso del método. Una transacción con una sola entrada no aporta un nuevo par para relacionar. Tampoco distingue qué salida nueva es el pago y cuál es change, el resto que vuelve al pagador. Eso requiere otra pista. Por tanto, la salida del taller no puede atribuirse automáticamente a Pedro solo por aparecer en su pago. [1] [4]

Pedro y otra persona pueden preparar una transacción conjunta y firmar cada uno sus entradas. Sus claves privadas, los números secretos con los que se crean firmas que autorizan el gasto de bitcoins, permanecen separadas. PSBT es un formato para intercambiar una transacción incompleta y la información necesaria entre programas o dispositivos, descrito en BIP 174. El coordinador que reúne los datos no necesita poseer todas las claves. La red comprueba las condiciones de gasto, no que una sola persona haya creado cada firma. Multisig aborda además otra cuestión: puede exigir varias firmas para una entrada, mientras que esta heurística estima la relación entre varias entradas. [2] [5] [6]

CoinJoin permite que varios participantes aporten fondos propios a una transacción conjunta. Payjoin muestra el problema dentro de un pago: según BIP 78, el destinatario también puede añadir sus entradas. Si el taller aceptara ese pago, aplicar la heurística a ciegas podría agrupar sus fondos con los de Pedro. La colaboración no exige que todas las salidas tengan el mismo importe. Por tanto, excluir transacciones que parezcan CoinJoin evidentes no basta para declarar que las restantes tienen un propietario único. No significa que toda transacción sea colaborativa, sino que su apariencia no siempre permite descartar esa posibilidad. [2]

Imaginemos las direcciones A, B y C. Una transacción gasta juntas salidas de A+B. Otra combina salidas diferentes de B+C. No se está gastando dos veces el mismo UTXO. A través de B, la herramienta puede unir A+B+C en un grupo o cluster. Pero si la segunda transacción fue una colaboración entre distintas personas, el error también afecta a la dirección A ya atribuida. Así pueden propagarse errores entre grupos enteros. Un número pequeño de vínculos incorrectos no garantiza un número pequeño de direcciones mal atribuidas. [1] [3]

Una plataforma puede gastar en una transacción fondos que administra para muchos clientes. La heurística podría identificar correctamente el control operativo común del servicio. No establece qué clientes tienen la propiedad económica de los fondos. Ni siquiera el nombre del servicio se obtiene solo de las entradas: la etiqueta necesita pruebas adicionales y debe corresponder al período estudiado. En cambio, Pedro puede usar varias carteras sin reunir nunca sus fondos. Contar los grupos encontrados no equivale, por tanto, a contar personas. Control, propiedad e identidad son cuestiones relacionadas, pero distintas. [1]

Un analista quiere saber si acertó al vincular direcciones. Si la única confirmación es otro gasto conjunto posterior, puede estar repitiendo la misma suposición. Eso no aporta automáticamente pruebas independientes. Malte Möser y Arvind Narayanan describen el uso de esos datos de referencia y sus límites. La evaluación debe explicar de dónde procede la muestra, qué transacciones excluye y qué período cubre. Las uniones erróneas, los vínculos omitidos y la cobertura deben evaluarse por separado. Sin calibración frente a casos conocidos, una puntuación no puede interpretarse como la probabilidad de identificar correctamente a una persona. [3]

Pedro puede utilizar Coin Control, la selección manual de los UTXO que gastará, para limitar futuras conexiones entre cobros hasta entonces separados. Eso no borra transacciones anteriores y exige entender qué fondos está seleccionando. Payjoin tampoco elimina todas las demás formas de atribución. En el análisis, cada vínculo debería poder rastrearse hasta una transacción, una versión de la regla y un motivo de inclusión o exclusión. Estas preguntas se derivan de los límites descritos en las fuentes. Al descubrir un error, debe ser posible determinar de nuevo qué direcciones pertenecen al grupo; añadir una nota a una conclusión sin modificar no repara atribuciones equivocadas. [2] [3]

Para obtener la imagen más completa, lee esta entrada junto con Address Clustering, CoinJoin, Payjoin, Chain Surveillance, PSBT, Coin Control. También enlazan con esta entrada Payjoin, Coin Selection, Chain Surveillance, Address Clustering.

DOC · 001Meiklejohn et al. — A Fistful of BitcoinsFuente primaria DOC · 002BIP 78 — A Simple Payjoin ProposalEspecificación DOC · 003Möser and Narayanan — Resurrecting Address Clustering in BitcoinFuente primaria DOC · 004Bitcoin Developer Guide — TransactionsDocumentación DOC · 005BIP 174 — Partially Signed Bitcoin Transaction FormatEspecificación DOC · 006Bitcoin Developer Guide — WalletsDocumentación
Revisado: Fuentes primero · No es asesoramiento financiero