La heurística de propiedad por entradas comunes

La heurística de propiedad por entradas comunes es la regla de agrupación más antigua y más utilizada en las cadenas UTXO. Produce la mayoría de los vínculos en cualquier clúster de Bitcoin, suele ser correcta y, cuando se equivoca, puede unir carteras enteras. Un analista necesita saber tanto por qué funciona como qué transacciones la invalidan exactamente.

La lógica

Para gastar un UTXO, una transacción debe proporcionar un script de desbloqueo o testigo válido para esa salida, lo que en la práctica significa una firma de la clave que la controla. Por lo tanto, una transacción con tres entradas necesita firmas para tres monedas. En el uso habitual, una cartera crea un pago seleccionando monedas de su propio saldo y firmándolas todas. Así que, si aparecen varias direcciones como entradas de una misma transacción, la explicación más probable es que una sola cartera y, por tanto, un solo controlador, tenga las claves de todas ellas.

La idea es tan antigua como Bitcoin. La sección de privacidad del libro blanco de 2008 ya advierte que las transacciones con múltiples entradas «necesariamente revelan que sus entradas pertenecían al mismo propietario». Reid y Harrigan (2011, «Un análisis del anonimato en el sistema Bitcoin») la utilizaron para crear una red de usuarios, y Meiklejohn et al. (2013, «Un puñado de bitcoins») la formularon como su Heurística 1: si dos o más direcciones son entradas de la misma transacción, las controla el mismo usuario. La regla también se denomina heurística de propiedad por entradas comunes (CIOH) o heurística de entradas múltiples.

Un ejemplo práctico

Esta es una transacción decodificada, simplificada para mostrar los campos relevantes para la agrupación (identificadores truncados):

{
  "txid": "7c1e…40ab",
  "vin": [
    {"prevout": "a91f…03:1", "address": "bc1q…k3f7", "value_btc": 0.0400},
    {"prevout": "e2c8…7d:0", "address": "bc1q…m9a2", "value_btc": 0.0250},
    {"prevout": "51b0…e9:4", "address": "bc1q…x0d1", "value_btc": 0.0180}
  ],
  "vout": [
    {"n": 0, "address": "bc1q…p2w8", "value_btc": 0.0700},
    {"n": 1, "address": "bc1q…r4t6", "value_btc": 0.0128}
  ]
}

Las tres entradas suman 0,0830 BTC; las salidas suman 0,0828 BTC, por lo que la comisión es de 0,0002 BTC (20.000 satoshis). La regla de entradas comunes crea vínculos entre bc1q…k3f7, bc1q…m9a2 y bc1q…x0d1. No dice nada sobre las salidas: determinar si bc1q…r4t6 es cambio perteneciente a la misma cartera es una inferencia aparte y mucho menos sólida, que se aborda en la lección Heurísticas para detectar el cambio.

Si bc1q…m9a2 ya formaba parte de un clúster de 2.000 direcciones y bc1q…x0d1 de uno de 300, esta única transacción los fusiona en un clúster de 2.301 direcciones. Ese es el alcance de la regla y también su peligro.

La regla es más sólida cuando se trata de servicios. Los exchanges de custodia y los procesadores de pagos consolidan periódicamente muchos depósitos pequeños en una sola salida: una transacción de entrada múltiple que puede gastar cientos de direcciones de depósito a la vez. Cada barrido vincula todas esas direcciones con la cartera del servicio, razón por la cual los clústeres de servicios crecen hasta tener millones de direcciones y por la que a menudo basta con un único depósito verificado para etiquetarlos (consulta la lección Atribución y etiquetado). Las consolidaciones de usuarios comunes funcionan de la misma manera, pero a menor escala: una cartera que reúne una docena de monedas antiguas para ahorrar comisiones futuras revela que las tenía todas. Ambos casos se basan en el mismo supuesto: que solo una parte firmó; y ambos son correctos siempre que nadie más haya aportado una entrada.

Qué tan bien funciona

Las pruebas sobre su precisión son limitadas, pero consistentes. Meiklejohn et al. aplicaron la regla a toda la cadena en 2013 y redujeron 12.056.684 claves públicas a unos 5,58 millones de clústeres. Nick (2015, una tesis de maestría sobre la desanonimización basada en datos en Bitcoin) obtuvo datos reales poco comunes a partir de una filtración de privacidad en los filtros de Bloom que utilizan las carteras ligeras, que expuso los conjuntos de direcciones de carteras reales; la regla de entradas comunes identificó más del 69 % de las direcciones de esas carteras. Observa qué mide esa cifra: exhaustividad (cuánto se encontró de cada cartera), no precisión (cuántos vínculos eran correctos). Por lo general, se considera que la regla tiene una precisión alta en transacciones ordinarias, pero eso es un supuesto sobre el comportamiento de las carteras, y las transacciones que se describen a continuación lo incumplen.

Cuándo falla el supuesto

CoinJoin. Varias personas acuerdan realizar una sola transacción; cada una aporta entradas y firma solo las suyas, y las salidas suelen incluir varias de igual valor, de modo que nadie puede saber qué salida pertenece a quién. Aplicar la regla de entradas comunes fusiona las carteras de todas las personas participantes, lo que produce precisamente el vínculo falso que CoinJoin pretende inducir. Consulta la lección Mezcladores, CoinJoin y ofuscación en grafos para ver cómo se representan estas transacciones en un grafo.

PayJoin. En un PayJoin (BIP 78), quien recibe un pago añade una de sus propias entradas a la transacción de quien lo envía. El resultado parece un pago ordinario de dos entradas, por lo que la regla vincula las monedas de quien envía con las de quien recibe; además, también distorsiona el importe aparente del pago. Un PayJoin bien construido no se puede distinguir de forma fiable de una transacción normal, por lo que su existencia pone un límite a la confianza que puede tenerse en un vínculo individual. Su adopción ha sido baja, lo que limita el daño general, pero no permite descartarlo en un caso específico.

Otras transacciones multipartitas. Cualquier protocolo en el que dos o más partes aporten entradas invalida la regla: aperturas de canales Lightning financiadas por dos partes, algunos protocolos de intercambio y procesamiento por lotes, y transacciones firmadas con SIGHASH_ANYONECANPAY, que permite que otras personas añadan entradas después de la primera firma (se utiliza, por ejemplo, en contratos de financiación colectiva).

Control compartido. Una dirección multisig que varias personas mantienen conjuntamente es un solo «propietario» en el sentido del script, pero varias personas en la realidad. La entidad correcta es el acuerdo conjunto, no cualquiera de las personas firmantes.

Custodia e importación de claves. Un servicio de custodia gasta conjuntamente los depósitos de sus clientes, así que su clúster es correcto para el servicio, pero no dice nada sobre sus clientes. Las carteras que permiten a los usuarios importar o barrer claves privadas recibidas de otras personas (carteras de papel, tarjetas de regalo) pueden vincular monedas que tenían distintos propietarios; el clúster de Mt. Gox mencionado en la lección Qué es la agrupación y por qué importa es el caso más conocido.

Medidas de protección

Cinco prácticas permiten que la regla siga siendo útil.

1. Descartar los CoinJoin probables antes de crear vínculos. La prueba más sencilla busca varias salidas de exactamente el mismo valor.

-- Marcar posibles CoinJoin para no vincular sus entradas
WITH same_value AS (
  SELECT tx_id, value_sat, COUNT(*) AS n_equal
  FROM outputs
  GROUP BY tx_id, value_sat
),
shape AS (
  SELECT t.tx_id, t.input_count, MAX(s.n_equal) AS max_equal_outputs
  FROM transactions t
  JOIN same_value s ON s.tx_id = t.tx_id
  GROUP BY t.tx_id, t.input_count
)
SELECT tx_id
FROM shape
WHERE input_count >= 2
  AND max_equal_outputs >= 3;  -- ajusta este umbral y documéntalo

La consulta cuenta, para cada transacción, cuántas salidas comparten cada valor, conserva el grupo más grande y marca las transacciones con varias entradas que tengan al menos tres salidas idénticas. El umbral depende del criterio de quien analiza. También detectará algunos pagos por lotes de exchanges que casualmente paguen importes iguales; excluirlos solo implica perder unos pocos vínculos (un falso negativo), que es el error más seguro. No detectará los diseños de CoinJoin que evitan las salidas de igual valor, así que es un filtro, no un detector. Las herramientas de investigación utilizan reglas más completas; Goldfeder et al. (2018, «Cuando la galleta se encuentra con la cadena de bloques») añadieron una exclusión de CoinJoin a su agrupación por este motivo.

1. Marcar las combinaciones de entradas inusuales. Las entradas de distintos tipos de script (por ejemplo, una entrada P2PKH heredada junto a una entrada P2TR) son poco comunes en el software de una sola cartera y merecen una revisión adicional.

1. Vigilar las fusiones. Revisa cualquier vínculo que pudiera fusionar dos clústeres grandes o dos clústeres con etiquetas diferentes. Harrigan y Fretter (2016, «La eficacia irracional de la agrupación de direcciones») observaron que es poco común que dos clústeres grandes se fusionen de forma natural, por lo que una fusión de este tipo es una señal de alerta.

1. Conservar la transacción que constituye la prueba de cada vínculo. Si más adelante se descubre que una transacción es un CoinJoin o un PayJoin, se pueden eliminar sus vínculos y reconstruir los clústeres.

1. Informar de la regla, no solo del resultado. Indica que un clúster se creó con la regla de entradas comunes, qué exclusiones se aplicaron y a qué altura de bloque.

Niveles de confianza

La generación de pares de direcciones a partir de tablas de entradas en SQL y la creación de clústeres iniciales a partir de ellos se aborda en la lección Consultar datos UTXO.

Enfoque del examen: por qué las entradas gastadas conjuntamente implican un controlador compartido (cada entrada necesita su propia firma válida y las carteras seleccionan monedas de su propio saldo); la regla como Heurística 1 de Meiklejohn et al. y sus orígenes en el libro blanco; la diferencia entre exhaustividad y precisión en las pruebas basadas en filtros de Bloom (se encontró más del 69 % de las direcciones de las carteras); las principales excepciones (CoinJoin, PayJoin según BIP 78, canales financiados por dos partes, SIGHASH_ANYONECANPAY, multisig, custodia e importación de claves); por qué un solo vínculo puede fusionar dos clústeres enteros; filtrar las salidas de igual valor antes de crear vínculos y documentar el umbral; revisar las fusiones grandes o con etiquetas incompatibles.