Common-Input Ownership Heuristic supone que una misma entidad suele controlar las entradas de una transacción Bitcoin. Aprovecha el comportamiento de carteras habituales; no es una regla de consenso ni una prueba de identidad personal.
Cada entrada referencia un UTXO anterior. El analista recupera su script de salida y utiliza el gasto conjunto para conectar las direcciones o scripts correspondientes. Una transacción de una sola entrada no crea una pareja nueva mediante esta regla. Por sí sola, tampoco identifica change ni al propietario de la salida del destinatario. [Meiklejohn et al. — A Fistful of Bitcoins] [Bitcoin Developer Guide — Transactions]
Una cartera puede seleccionar varios UTXO propios para un pago. Gastarlos juntos revela una relación que los pagos entrantes separados no mostraban. Es una observación sobre selección de monedas, no una exigencia del protocolo; el número de entradas no proporciona por sí solo la probabilidad de una atribución correcta. [Meiklejohn et al. — A Fistful of Bitcoins]
Los participantes pueden firmar sus entradas por separado y ensamblar una transacción válida. PSBT, según BIP 174, permite intercambiar datos y firmas; el coordinador no necesita todas las claves privadas. La validez demuestra que se cumplen las condiciones de gasto, no que firme una sola persona. Multisig dentro de una entrada es distinto del control común de varias entradas. [BIP 78 — A Simple Payjoin Proposal] [BIP 174 — Partially Signed Bitcoin Transaction Format]
CoinJoin puede reunir entradas de varios participantes. En Payjoin según BIP 78, el receptor añade entradas propias al pago del emisor; aplicar ciegamente la heurística fusionaría ambas partes. Esta colaboración no exige salidas de importes iguales. Excluir solo CoinJoin evidentes no demuestra que las demás transacciones tengan un único propietario. [BIP 78 — A Simple Payjoin Proposal]
El ejemplo usa direcciones A, B, C, no el gasto repetido del mismo UTXO: una transacción conecta A+B y otra gasta salidas diferentes de B+C. La fusión transitiva produce A+B+C. Si la segunda relación proviene de un pago colaborativo, el error afecta también al cluster anterior; pocas aristas falsas no implican pocas direcciones mal atribuidas. [Meiklejohn et al. — A Fistful of Bitcoins] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Una plataforma de intercambio puede gastar conjuntamente UTXO administrados para muchos clientes. La heurística puede reflejar control operativo sin identificar a los propietarios económicos. La etiqueta del servicio necesita procedencia independiente y vigencia temporal; una persona también puede usar varias carteras nunca conectadas. Contar clusters no equivale a contar personas. [Meiklejohn et al. — A Fistful of Bitcoins]
Validar una unión solo mediante un gasto conjunto posterior puede reutilizar la heurística que se evalúa. Möser y Narayanan muestran usos y límites de esos datos. La evaluación debe documentar origen de la muestra, transacciones excluidas y período, separando fusiones falsas, vínculos omitidos y cobertura. Una puntuación sin calibrar no es una probabilidad de identidad. [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
Conserve para cada arista la transacción, versión de la regla y motivo de aceptación o exclusión. Nueva evidencia contraria debe permitir recalcular el cluster, no añadir una nota a una conclusión intacta. Coin Control puede limitar futuros gastos conjuntos de monedas separadas, pero no borrar la historia; Payjoin cuestiona esta heurística, no todas las fuentes de atribución. [BIP 78 — A Simple Payjoin Proposal] [Möser and Narayanan — Resurrecting Address Clustering in Bitcoin]
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, Chain Surveillance, Address Clustering.