Fermata #125 - DMix, il CoinJoin senza coordinatore

Bitcoin ha un problema di fungibilità. La fungibilità è, per esempio, nelle banconote. Una banconota da €10 è uguale a un'altra banconota da €10. In Bitcoin ogni UTXO ha la sua storia, si porta dietro le transazioni passate. Dato un UTXO, io posso sapere chi l'ha speso l’ultima volta, chi l’ha speso quella prima e quella prima ancora. Il CoinJoin risolve questo problema.

Ipotizziamo di avere un input da 1 BTC, uno da 0,5 BTC e uno da 0,7 BTC, con un totale 2,2 BTC. Come output ne abbiamo due da 1 BTC e uno da 0,2 BTC. Questo è un CoinJoin: ha due output uguali e nessun osservatore esterno è in grado di dire se il primo output da 1 BTC viene dall'input da 1 BTC oppure dalla somma di 0,5 BTC e 0,7 BTC. In questo modo i due output vengono resi fungibili.

Il CoinJoin è questo: una transazione in cui esistono output che hanno lo stesso valore, per cui non è chiaro da quale input derivino.

Ci sono alcune variabili quando si parla di privacy, una di queste è l'anonimity set. In breve: più è la gente che fa qualcosa, meno è probabile che qualcuno individui un target specifico. Se a fare un’attività siamo in due, un osservatore esterno che mi voglia individuare ha il 50% di probabilità di trovarmi; se siamo il 10, il 10%, ecc.

Anche nel caso del CoinJoin, dunque, è bene che il numero di partecipanti sia ampio. Ma più persone ci sono, più è difficile coordinarsi. Senza una terza parte centrale, la difficoltà del coordinamento cresce esponenzialmente rispetto all’aumento dei partecipanti.

In termini semplici, il problema è che il coordinatore centrale vede tutto: sa quali sono i partecipanti, è potenzialmente in grado di stabilire chi può partecipare e chi no, può trovare la correlazione tra input e output, può tenere conto di quante volte qualcuno esegue un CoinJoin, può tracciare gli IP di chi non utilizza Tor, ecc. Essendo un custode di dati preziosi, quindi, il coordinatore diventa obiettivo dell’analisi on-chain.

Wasabi fa mascherare all’utente i propri input tramite le firme cieche. In questo modo il coordinatore si ritrova con tanti input e tanti output ed è in grado di creare la transazione senza poter ricostruire i collegamenti tra input e output. Wasabi fa cambiare l’identità Tor dell’utente durante il processo, in modo che il coordinatore non trovi correlazioni. Lato utente è molto semplice, basta cliccare un tasto e tutto avviene in background.

Tuttavia c’è ancora la possibilità di censurare determinate transazioni sulla base di pattern temporali: questi si possono individuare con analisi on-chain e off-chain. E’ difficile, i risultati non sono esatti al 100%, ma resta comunque un potere da gatekeeper.

Anche Samourai ha il coordinatore ma non è chiarissimo come agisca e se ci possano essere gli stessi problemi di cui sopra.

Nel caso di Join Market, invece, il coordinatore cambia per ogni round di CoinJoin. In pratica all’interno del mercato JoinMarket ci sono quelli che vengono chiamati maker e taker, rispettivamente i creatori di liquidità - coloro che vogliono fare il CoinJoin - e quelli che la liquidità la prendono, coordinando il CoinJoin. E’ un approccio molto interessante e funziona, è un modo per decentralizzare la coordinazione. Il problema è che a volte i taker potrebbero benissimo essere infiltrati di Chainalysis.

L’idea di DMix è nata quando si iniziava a parlare threshold signatures nel contesto di Taproot. Già prima dell’implementazione del soft-fork era possibile firmare una transazione con più persone. In una transazione multisig 3-di-3, per esempio, tre chiavi private venivano utilizzate per firmare la transazione e on-chain si vedevano le tre rispettive chiavi pubbliche. Questo poteva essere un problema di privacy perché si era in grado di vedere quante entità ci fossero dietro a una transazione.

L’arrivo delle threshold signatures con Taproot permette a più entità di firmare una transazione mostrando on-chain una firma unica. Più chiavi private ma una sola chiave pubblica e un solo indirizzo on-chain. In questo modo i vari tipi di transazione on-chain diventano indistinguibili.

L'obiettivo di DMix è che tutte le persone che partecipano al CoinJoin facciano contemporaneamente da coordinatore. Lo fanno creando tutti insieme una chiave pubblica che diventa un indirizzo: l’indirizzo del DMix. In una prima fase ogni partecipante invia i propri fondi all’indirizzo e in una seconda fase tutti insieme li spendono con le firme utilizzate per generare la chiave pubblica univoca: questo secondo passaggio è l’effettiva transazione di CoinJoin.

Lo svantaggio è che servono due transazioni. Stiamo lavorando alla soluzione - che a livello teorico c’è - per riunire tutto il processo in un unico passaggio. Il vantaggio è che non c’è più un coordinatore esterno ma i partecipanti possono coordinarsi tra loro creando la chiave pubblica condivisa. Dopo il primo passaggio non serve più coordinazione perché una volta fatta la chiave ognuno agisce in modo indipendente. Quando i partecipanti mandano i soldi dentro il DMix lo fanno tramite una transazione time-locked. Questo significa che se entro il blocco N gli altri non hanno inviato i loro fondi, chi ha invece inviati può ritirarli. 

Se il DMix fallisce perché, per esempio, qualcuno non ha mandato i soldi, non rimane alcuna traccia on-chain. Un osservatore esterno non è in grado di riconoscere il DMix fallito.

Sì, soprattutto se i partecipanti non si conoscono. L’idea principale è infatti proporre DMix come soluzione per conoscenti. L'assunzione principale è che vogliamo privacy dal resto del mondo, non necessariamente dai nostri amici.

Tecnicamente un DMix si può fare anche di persona. Magari in un futuro lontano con un'app che comunica via Bluetooth con i dispositivi limitrofi.

Ipotizziamo che esista una mappa che indichi il percorso di un input verso il suo output corrispondente. Quello che si vuole fare con il CoinJoin è massimizzare il numero di possibili percorsi che ci sono per ogni transazione. Il modo più facile per farlo è quello di avere tutti gli output del CoinJoin uguali, ma in questo modo un CoinJoin è facilmente riconoscibile. Se una transazione ha tanti output dello stesso importo, quasi sicuramente quella transazione è un CoinJoin.

Questo però non è l’unico metodo.

Si può fare in modo di ottenere degli output sempre fungibili, perché non si è in grado di ricondurli ai corrispondenti input, ma tutti di diverso importo. In questo modo è molto più difficile affermare che la transazione sia un CoinJoin, c’è una maggior plausible deniability1.

Quindi la prima parte della ricerca sta nel chiedersi: che cos’è una transazione normale? Se un utente qualunque deve fare una transazione, cosa fa di solito? Ovviamente non sarà una transazione con un input e due output, perché la gente utilizzerà ogni tanto quei due output che ha ricevuto. Quindi quanti sono? Due input e due output? Tre input e quattro output? Bisogna capire in primis qual è la versione più comune, la più probabile e poi rendere la transazione di CoinJoin il più possibile simile a quella.

Il coordinamento necessario per effettuare un CoinJoin - quindi lo scambio di informazioni necessarie per la transazione collaborativa - avviene tramite Nostr. JoinStr mi sembra molto simile a JoinMarket, con mercato di maker e taker. Mi sembra un'idea interessante visto che i messaggi su Nostr possono essere criptati.