L’euristica di proprietà degli input comuni

L’euristica di proprietà degli input comuni è la regola di clustering più antica e più utilizzata nelle blockchain UTXO. Produce la maggior parte dei collegamenti in qualsiasi cluster Bitcoin, di solito è corretta e, quando non lo è, può fondere interi wallet. Un analista deve sapere sia perché funziona sia quali transazioni la mettono esattamente in crisi.

La logica

Per spendere un UTXO, una transazione deve fornire uno script di sblocco o una witness validi per quell’output, il che in pratica significa una firma della chiave che lo controlla. Una transazione con tre input richiede quindi le firme per tre monete. Nell’uso ordinario, un wallet crea un pagamento selezionando monete dal proprio saldo e firmandole tutte. Perciò, se più indirizzi compaiono come input della stessa transazione, la spiegazione più probabile è che un solo wallet, e quindi un solo controllore, possieda le chiavi di tutti.

L’idea è antica quanto Bitcoin. La sezione sulla privacy del white paper del 2008 avverte già che le transazioni con più input «rivelano necessariamente che i loro input erano di proprietà dello stesso proprietario». Reid e Harrigan (2011, «Un’analisi dell’anonimato nel sistema Bitcoin») la usarono per costruire una rete di utenti, mentre Meiklejohn et al. (2013, «Una manciata di Bitcoin») la formularono come euristica 1: se due o più indirizzi sono input della stessa transazione, sono controllati dallo stesso utente. La regola è chiamata anche euristica di proprietà degli input comuni (CIOH) o euristica dei multi-input.

Un esempio svolto

Ecco una transazione decodificata, semplificata nei campi rilevanti per il clustering (identificativi troncati):

{
  "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}
  ]
}

I tre input ammontano a 0,0830 BTC; gli output ammontano a 0,0828 BTC, quindi la commissione è di 0,0002 BTC (20.000 satoshi). La regola degli input comuni crea collegamenti tra bc1q…k3f7, bc1q…m9a2 e bc1q…x0d1. Non dice nulla sugli output: stabilire se bc1q…r4t6 sia il resto appartenente allo stesso wallet è un’inferenza distinta e molto più debole, trattata nella lezione Euristiche di rilevamento del resto.

Se bc1q…m9a2 si trovava già in un cluster di 2.000 indirizzi e bc1q…x0d1 in un cluster di 300, questa singola transazione li fonde in un cluster di 2.301 indirizzi. Questa è la leva della regola, ma anche il suo pericolo.

La regola è più efficace con i servizi. Gli exchange con custodia e i processori di pagamento periodicamente consolidano molti piccoli depositi in un unico output, con una transazione di raccolta che può spendere centinaia di indirizzi di deposito in una volta. Ogni raccolta collega tutti quegli indirizzi al wallet del servizio: ecco perché i cluster dei servizi raggiungono milioni di indirizzi e perché spesso basta un singolo deposito verificato per etichettarli (vedi la lezione Attribuzione ed etichettatura). I consolidamenti effettuati dagli utenti comuni funzionano allo stesso modo, ma su scala più ridotta: un wallet che unisce una dozzina di vecchie monete per risparmiare sulle commissioni future rivela di averle detenute tutte. Entrambi i casi si basano sulla stessa ipotesi, cioè che abbia firmato una sola parte, ed entrambi sono corretti purché nessun altro abbia contribuito con un input.

Quanto funziona bene

Le prove sull’accuratezza sono limitate ma coerenti. Nel 2013 Meiklejohn et al. applicarono la regola all’intera blockchain e ridussero 12.056.684 chiavi pubbliche a circa 5,58 milioni di cluster. Nick (2015, una tesi magistrale sulla de-anonimizzazione di Bitcoin basata sui dati) ottenne dati reali verificati, una risorsa rara, grazie a una fuga di dati sulla privacy nei filtri Bloom usati dai wallet leggeri, che rivelò gli insiemi di indirizzi di wallet reali; la regola degli input comuni identificò più del 69% degli indirizzi di quei wallet. Si noti che cosa misura questa percentuale: il recupero (quanta parte di ciascun wallet è stata individuata), non la precisione (quanti collegamenti erano corretti). In genere, la regola è considerata molto precisa per le transazioni ordinarie, ma si tratta di un’ipotesi sul comportamento dei wallet, che viene violata dalle transazioni descritte di seguito.

Quando l’ipotesi viene meno

CoinJoin. Più utenti concordano su un’unica transazione; ciascuno contribuisce con i propri input e firma solo i propri, mentre gli output includono in genere diversi importi identici, così che nessuno possa stabilire a chi appartiene ciascun output. Applicare la regola degli input comuni fonde i wallet di tutti i partecipanti, creando proprio il falso collegamento che CoinJoin è progettato per indurre. Per vedere come appaiono queste transazioni in un grafo, vedi la lezione Mixer, CoinJoin e offuscamento nei grafi.

PayJoin. In un PayJoin (BIP 78), il destinatario di un pagamento aggiunge alla transazione del mittente uno dei propri input. Il risultato sembra un normale pagamento a due input, quindi la regola collega le monete del mittente e del destinatario, e anche l’importo apparente del pagamento risulta distorto. Un PayJoin ben costruito non può essere distinto in modo affidabile da una transazione normale, quindi la sua esistenza pone un limite alla sicurezza di qualsiasi singolo collegamento. La sua diffusione è stata limitata, il che riduce il danno complessivo ma non ne esclude la presenza in un caso specifico.

Altre transazioni multi-parte. Qualsiasi protocollo in cui due o più parti contribuiscono con input infrange la regola: aperture di canali Lightning finanziate da entrambe le parti, alcuni protocolli di swap e di batching, e transazioni firmate con SIGHASH_ANYONECANPAY, che consente ad altri di aggiungere input dopo la prima firma (usato, per esempio, nei contratti di tipo crowdfunding).

Controllo condiviso. Un indirizzo multisig detenuto congiuntamente da più persone costituisce un solo «proprietario» in termini di script, ma nella realtà rappresenta più persone. L’entità corretta è l’accordo congiunto, non un singolo firmatario.

Custodia e importazione di chiavi. Un servizio di custodia spende insieme i depositi dei clienti, quindi il suo cluster è corretto per il servizio ma non dice nulla sui clienti. I wallet che consentono agli utenti di importare o trasferire chiavi private ricevute da altri (paper wallet, buoni regalo) possono collegare monete che avevano proprietari diversi; il cluster di Mt. Gox menzionato nella lezione Che cos’è il clustering e perché è importante è il caso più noto.

Misure di sicurezza

Cinque pratiche consentono di usare la regola in modo efficace.

1. Escludere i probabili CoinJoin prima di creare collegamenti. Il test più semplice individua più output dello stesso identico valore.

-- Segnala i possibili CoinJoin per evitare di collegarne gli input
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;  -- regola questa soglia e documentala

La query conta, per ogni transazione, quanti output condividono ciascun valore, conserva il gruppo più numeroso e segnala le transazioni con più input in cui almeno tre output sono identici. La soglia è una scelta discrezionale. Il test individuerà anche alcuni pagamenti in batch di exchange che per caso pagano importi uguali; escluderli comporta la perdita di pochi collegamenti (un falso negativo), un errore più prudente. Non individuerà i modelli CoinJoin che evitano gli output uguali, quindi è un filtro, non un rilevatore. Gli strumenti di ricerca usano regole più articolate; per questo motivo Goldfeder et al. (2018, «Quando il cookie incontra la blockchain») aggiunsero un’esclusione dei CoinJoin al loro clustering.

1. Segnalare le combinazioni di input insolite. Input di tipi di script diversi (per esempio un input legacy P2PKH accanto a un input P2TR) sono insoliti nei software di un singolo wallet e meritano un’ulteriore verifica.

1. Monitorare le fusioni. Esaminare qualsiasi collegamento che fonderebbe due cluster grandi o due cluster con etichette diverse. Harrigan e Fretter (2016, «L’irragionevole efficacia del clustering degli indirizzi») osservarono che è raro che due grandi cluster si fondano naturalmente, quindi una fusione del genere è un segnale di allarme.

1. Conservare la transazione di prova per ogni collegamento. Se in seguito una transazione si rivela essere un CoinJoin o un PayJoin, i suoi collegamenti possono essere rimossi e i cluster ricostruiti.

1. Dichiarare la regola, non solo il risultato. Specificare che un cluster è stato creato con la regola degli input comuni, quali esclusioni sono state applicate e a quale altezza di blocco.

Livelli di sicurezza

La generazione delle coppie di indirizzi effettive dalle tabelle degli input in SQL e la creazione di cluster a partire da esse sono trattate nella lezione Interrogare i dati UTXO.

Focus sull’esame: perché gli input spesi insieme implicano un controllore condiviso (ogni input richiede la propria firma valida e i wallet selezionano monete dal proprio saldo); la regola come euristica 1 di Meiklejohn et al. e le sue radici nel white paper; la distinzione tra recupero e precisione nei dati dei filtri Bloom (individuato più del 69% degli indirizzi dei wallet); le principali eccezioni (CoinJoin, PayJoin secondo BIP 78, canali finanziati da entrambe le parti, SIGHASH_ANYONECANPAY, multisig, custodia e importazione di chiavi); perché un singolo collegamento può fondere due interi cluster; il controllo degli output di uguale valore prima di creare collegamenti e la documentazione della soglia; l’esame delle fusioni di grandi dimensioni o tra cluster con etichette in conflitto.