name: Privacy su Bitcoin goal: Comprendere e padroneggiare i principi di protezione della privacy quando si utilizza Bitcoin objectives:

Definire i concetti teorici necessari per comprendere le questioni relative alla privacy
Identificare e mitigare i rischi associati alla perdita di riservatezza per gli utenti Bitcoin
Utilizzo di metodi e strumenti per la protezione della privacy su Bitcoin
Comprendere i metodi di analisi della catena e sviluppare strategie di difesa

Proteggete la vostra privacy su Bitcoin

In un mondo in cui la riservatezza delle transazioni finanziarie sta gradualmente diventando un lusso, comprendere e padroneggiare i principi di protezione della privacy nell'utilizzo di Bitcoin è essenziale. Questo corso di formazione fornisce tutte le chiavi, sia teoriche che pratiche, per raggiungere questo obiettivo in modo autonomo.

Oggi, su Bitcoin, le aziende sono specializzate nell'analisi della blockchain. Il loro core business consiste proprio nell'intromettersi nella vostra sfera privata, al fine di compromettere la riservatezza delle vostre transazioni. In realtà, non esiste un "diritto alla privacy" in Bitcoin. Spetta quindi a voi, utenti, far valere i vostri diritti naturali e proteggere la riservatezza delle vostre transazioni, perché nessun altro lo farà per voi.

Il corso è stato progettato per essere completo e generale. Ogni concetto tecnico è trattato in dettaglio e supportato da diagrammi esplicativi. L'obiettivo è quello di rendere le conoscenze accessibili a tutti. BTC204 è quindi alla portata di principianti e utenti intermedi. Il corso offre anche un valore aggiunto ai bitcoiners più esperti, in quanto approfondisce alcuni concetti tecnici che spesso vengono fraintesi.

Unisciti a noi per trasformare il tuo utilizzo di Bitcoin e diventare un utente informato, in grado di comprendere le problematiche legate alla riservatezza e alla protezione della tua privacy.

Introduzione

Panoramica del corso

Benvenuto al corso BTC204!

Il Bitcoin non è solo "Number Go Up" e conservazione del valore dei risparmi. Con le sue caratteristiche uniche e la sua storia, è innanzitutto lo strumento della contro-economia. Grazie a questa formidabile invenzione, potete disporre liberamente del vostro denaro, spenderlo e accumularlo, senza che nessuno possa fermarvi.

Il Bitcoin offre una fuga pacifica dal giogo dello Stato, consentendo di godere appieno dei propri diritti naturali, che non possono essere messi in discussione dalle leggi vigenti. Grazie all'invenzione di Satoshi Nakamoto, avete il potere di far rispettare la vostra proprietà privata e di riconquistare la libertà di contrattare.

Tuttavia, il Bitcoin non è anonimo di default, il che può rappresentare un rischio per gli individui impegnati nella contro-economia, in particolare nelle regioni sottoposte a regime dispotico. Ma questo non è l'unico pericolo. Poiché il bitcoin è un bene prezioso e incensurabile, può essere un obiettivo per i ladri. Proteggere la propria privacy diventa quindi anche una questione di sicurezza: può aiutare a prevenire hacking e aggressioni fisiche.

Come vedremo, sebbene il protocollo offra di per sé alcune protezioni della riservatezza, è fondamentale utilizzare strumenti aggiuntivi per ottimizzare e difendere questa riservatezza.

Questo corso di formazione è stato progettato per fornire una panoramica generale e completa delle problematiche legate alla riservatezza di Bitcoin. Ogni concetto tecnico è trattato in dettaglio, con il supporto di diagrammi esplicativi. L'obiettivo è quello di rendere queste conoscenze accessibili a tutti, anche ai principianti e agli utenti intermedi. Per i Bitcoiners più esperti, nel corso del corso vengono trattati anche concetti altamente tecnici e talvolta poco conosciuti, per approfondire la comprensione di ogni argomento.

L'obiettivo di questo corso di formazione non è quello di rendere totalmente anonimo il vostro utilizzo di Bitcoin, ma piuttosto di fornirvi gli strumenti essenziali per sapere come proteggere la vostra riservatezza in base ai vostri obiettivi personali. Avrete la libertà di scegliere tra i concetti e gli strumenti presentati per sviluppare le vostre strategie personali, adattate ai vostri obiettivi e alle vostre esigenze specifiche.

Sezione 1: Definizioni e concetti chiave

Per cominciare, rivedremo i principi fondamentali che regolano il funzionamento di Bitcoin, in modo da poter poi affrontare con calma le nozioni relative alla riservatezza. È essenziale padroneggiare alcuni concetti di base, come UTXO, indirizzi di ricezione e scripting, prima di poter comprendere appieno i concetti che tratteremo nelle sezioni successive. Introdurremo anche il modello generale di riservatezza di Bitcoin, come immaginato da Satoshi Nakamoto, che ci permetterà di comprendere la posta in gioco e i rischi associati.

Sezione 2: Comprendere e proteggere dall'analisi di catena

Nella seconda sezione, esaminiamo le tecniche utilizzate dalle società di analisi della blockchain per tracciare la vostra attività su Bitcoin. La comprensione di questi metodi è fondamentale per rafforzare la protezione della privacy. L'obiettivo di questa sezione è esaminare le strategie degli aggressori per comprendere meglio i rischi e preparare il terreno per le tecniche che studieremo nelle sezioni successive. Analizzeremo i modelli di transazione, le euristiche interne ed esterne e le probabili interpretazioni di questi modelli. Oltre alla teoria, impareremo a utilizzare un block explorer per l'analisi della catena, attraverso esempi pratici ed esercizi.

Sezione 3: Padroneggiare le migliori pratiche per proteggere la vostra privacy

Nella terza sezione del nostro corso di formazione, entriamo nel vivo: la pratica! L'obiettivo è quello di padroneggiare tutte le migliori pratiche essenziali che dovrebbero diventare un riflesso naturale per qualsiasi utente di Bitcoin. Ci occuperemo dell'uso di indirizzi vuoti, del tagging, del consolidamento, dell'uso di nodi completi, nonché del KYC e dei metodi di acquisizione. L'obiettivo è quello di fornire una panoramica completa delle insidie da evitare per stabilire una solida base nella nostra ricerca di protezione della privacy. Per alcune di queste pratiche, sarete guidati a un tutorial specifico su come implementarle.

Sezione 4: Comprendere le transazioni coinjoin

Come possiamo parlare di privacy su Bitcoin senza menzionare le coinjoin? Nella sezione 4 scoprirete tutto quello che c'è da sapere su questo metodo di miscelazione. Scoprirete cosa sono le coinjoin, la loro storia e i loro obiettivi, nonché i diversi tipi di coinjoin esistenti. Infine, per gli utenti più esperti, vedremo cosa sono gli anonset e l'entropia e come calcolarli.

Sezione 5: Comprendere le sfide di altre tecniche di riservatezza avanzate

Nella quinta sezione, daremo un'occhiata a tutte le altre tecniche disponibili per proteggere la privacy su Bitcoin, oltre a coinjoin. Nel corso degli anni, gli sviluppatori hanno dimostrato una notevole creatività nel progettare strumenti dedicati alla privacy. Esamineremo tutti questi metodi, come payjoin, transazioni collaborative, Coin Swap e Atomic Swap, illustrandone il funzionamento, gli obiettivi e gli eventuali punti deboli.

Analizzeremo anche la privacy a livello di rete di nodi e di diffusione delle transazioni. Discuteremo anche i vari protocolli che sono stati proposti nel corso degli anni per migliorare la privacy degli utenti su Bitcoin, compresi i protocolli di indirizzo statico.

BTC204 Pronto a esplorare i meandri della privacy su Bitcoin? Andiamo!

Definizioni e concetti chiave

Il modello UTXO di Bitcoin

Il Bitcoin è prima di tutto una valuta, ma sapete effettivamente come vengono rappresentati i BTC nel protocollo?

UTXO su Bitcoin: cosa sono?

Il protocollo Bitcoin si basa sul modello UTXO, che sta per "Unspent Transaction Output".

Questo modello differisce profondamente dai sistemi bancari tradizionali, che si basano su un meccanismo di conti e saldi per tracciare i flussi finanziari. Nel sistema bancario, infatti, i saldi individuali sono mantenuti in conti collegati a un'identità. Per esempio, quando comprate una baguette da un panettiere, la vostra banca si limita ad addebitare l'importo dell'acquisto sul vostro conto, riducendo il vostro saldo, mentre il conto del panettiere viene accreditato con lo stesso importo, aumentando il suo saldo. In questo sistema, non c'è alcun legame tra il denaro che entra nel vostro conto e quello che ne esce, a parte i registri delle transazioni.

Il Bitcoin funziona in modo diverso. Il concetto di conto non esiste e le unità monetarie non sono gestite attraverso i saldi, ma attraverso gli UTXO. Un UTXO rappresenta una quantità specifica di bitcoin non ancora spesi, formando così un "pezzo di bitcoin", che può essere grande o piccolo. Ad esempio, un UTXO può valere 500 BTC o semplicemente 700 SATS.

**> Il satoshi, spesso abbreviato in sat, è l'unità più piccola di Bitcoin, paragonabile al centesimo di dollaro nelle valute fiat.

1 BTC = 100 000 000 SATS

Teoricamente, un UTXO può rappresentare qualsiasi valore in bitcoin, da un sat a un massimo teorico di circa 21 milioni di BTC. Tuttavia, è logicamente impossibile possedere tutti i 21 milioni di bitcoin, ed esiste una soglia economica inferiore chiamata "polvere", al di sotto della quale un UTXO è considerato economicamente non conveniente da spendere.

**> Il più grande UTXO mai creato su Bitcoin aveva un valore di 500.000 BTC. È stato creato dalla piattaforma MtGox durante un'operazione di consolidamento nel novembre 2011: 29a3efd3ef04f9153d47a990bd7b048a4b2d213daaa5fb8ed670fb85f13bdbcf

UTXO e condizioni di spesa

Gli UTXO sono gli strumenti di scambio di Bitcoin. Ogni transazione comporta il consumo di UTXO come input e la creazione di nuovi UTXO come output. Quando una transazione è completata, gli UTXO utilizzati come input sono considerati "spesi" e nuovi UTXO vengono generati e assegnati ai destinatari indicati negli output della transazione. Pertanto, un UTXO rappresenta semplicemente un output di transazione non speso, e quindi una quantità di bitcoin appartenenti a un utente in un determinato momento.

Tutti gli UTXO sono protetti da script che definiscono le condizioni in cui possono essere spesi. Per consumare un UTXO, un utente deve dimostrare alla rete di soddisfare le condizioni stabilite dallo script che lo protegge. In genere, gli UTXO sono protetti da una chiave pubblica (o da un indirizzo di ricezione che rappresenta tale chiave pubblica). Per spendere un UTXO associato a questa chiave pubblica, l'utente deve dimostrare di possedere la chiave privata corrispondente, fornendo una firma digitale realizzata con questa chiave. Per questo si dice che il portafoglio Bitcoin non contiene bitcoin, ma custodisce le chiavi private, che a loro volta danno accesso agli UTXO e, per estensione, ai bitcoin che rappresentano.

Poiché in Bitcoin non esiste il concetto di conto, il saldo di un portafoglio è semplicemente la somma dei valori di tutti gli UTXO che può spendere. Ad esempio, se il portafoglio Bitcoin può spendere i seguenti 4 UTXO:

- 2 BTC
- 8 BTC
- 5 BTC
- 2 BTC

Il saldo totale del vostro portafoglio sarà di 17 BTC.

La struttura delle transazioni Bitcoin

Ingressi e uscite delle transazioni

Una transazione Bitcoin è un'operazione registrata sulla blockchain che trasferisce la proprietà dei bitcoin da una persona a un'altra. Più precisamente, poiché siamo in un modello UTXO e non esistono conti, la transazione soddisfa le condizioni di spesa che assicuravano uno o più UTXO, li consuma e crea equivalentemente nuovi UTXO con nuove condizioni di spesa. In breve, una transazione sposta i bitcoin da uno script soddisfatto a un nuovo script progettato per garantirli.

Ogni transazione Bitcoin è quindi composta da uno o più ingressi e da una o più uscite. Gli input sono UTXO consumati dalla transazione per generare output. Gli output sono nuovi UTXO che possono essere utilizzati come input per transazioni future.

**> In teoria, una transazione bitcoin potrebbe avere un numero infinito di ingressi e uscite. L'unico limite è la dimensione massima del blocco.

Ogni input in una transazione Bitcoin si riferisce a un precedente UTXO non speso. Per utilizzare un UTXO come input, il suo titolare deve dimostrare di esserne il legittimo proprietario convalidando la scrittura associata, cioè soddisfacendo la condizione di spesa imposta. In generale, ciò significa fornire una firma digitale prodotta con la chiave privata corrispondente alla chiave pubblica che ha garantito inizialmente questo UTXO. La scrittura consiste quindi nel verificare che la firma corrisponda alla chiave pubblica utilizzata al momento della ricezione dei fondi.

Ogni uscita, a sua volta, specifica la quantità di bitcoin da trasferire e il destinatario. Quest'ultimo è definito da un nuovo script, che di solito blocca l'UTXO appena creato con un indirizzo di ricezione o una nuova chiave pubblica.

Affinché una transazione sia considerata valida secondo le regole del consenso, il totale delle uscite deve essere inferiore o uguale al totale degli ingressi. In altre parole, la somma dei nuovi UTXO generati dalla transazione non deve superare la somma degli UTXO consumati come input. Questo principio è logico: se si hanno solo 500.000 SATS, non si può fare un acquisto di 700.000 SATS.

Scambio e fusione in una transazione Bitcoin

L'azione di una transazione Bitcoin su UTXO può quindi essere paragonata alla rifusione di una moneta d'oro. Infatti, un UTXO non è divisibile, ma solo fusibile. Ciò significa che un utente non può semplicemente dividere un UTXO che rappresenta un certo importo in bitcoin in diversi UTXO più piccoli. Deve consumarlo interamente in una transazione per creare uno o più nuovi UTXO di valori arbitrari in uscita, che devono essere inferiori o uguali al valore iniziale.

Il meccanismo è simile a quello di una moneta d'oro. Supponiamo di possedere una moneta da 2 once e di voler effettuare un pagamento di 1 oncia, supponendo che il venditore non possa dare il resto. Dovreste fondere la vostra moneta e fonderne due nuove da 1 oncia ciascuna.

Il Bitcoin funziona in modo simile. Immaginiamo che Alice abbia un UTXO di 10.000 SATS e desideri acquistare una baguette del costo di 4.000 SATS. Alice effettuerà una transazione con 1 UTXO di 10.000 SATS come input, che consumerà interamente, e 2 UTXO di 4.000 SATS e 6.000 SATS come output. L'UTXO di 4.000 SATS sarà inviato al fornaio in pagamento della baguette, mentre l'UTXO di 6.000 SATS tornerà ad Alice sotto forma di resto. Questo UTXO, che ritorna all'emittente originale della transazione, è noto come "scambio" nel gergo Bitcoin.

Immaginiamo ora che Alice non abbia un singolo UTXO da 10.000 SATS, ma piuttosto due UTXO da 3.000 SATS ciascuno. In questa situazione, nessuno dei due UTXO è sufficiente per impostare i 4.000 SATS della bacchetta. Alice deve quindi utilizzare contemporaneamente i 2 UTXO da 3.000 SATS come input della sua transazione. In questo modo, il totale degli input raggiungerà 6.000 SATS, consentendole di soddisfare il pagamento di 4.000 SATS al panettiere. Questo metodo, in cui diversi UTXO vengono raggruppati come input di una transazione, viene spesso definito "fusione".

Commissioni di transazione

Intuitivamente, si potrebbe pensare che i costi di transazione rappresentino anche il risultato di una transazione. Ma in realtà non è così. I costi di transazione rappresentano la differenza tra il totale degli input e il totale degli output. Ciò significa che, dopo aver utilizzato parte del valore degli input per coprire gli output desiderati in una transazione, una certa somma di input rimane inutilizzata. Questa somma residua costituisce i costi di transazione.

Frais = total inputs - total outputs

Prendiamo l'esempio di Alice, che ha un UTXO di 10.000 SATS e vuole comprare una baguette a 4.000 SATS. Alice crea una transazione con il suo UTXO di 10.000 SATS come input. Quindi genera un output di 4.000 SATS per il fornaio per pagare la baguette. Per incoraggiare i minatori a integrare la sua transazione in un blocco, Alice assegna 200 SATS in tasse. Crea quindi un secondo output, lo scambio, che le verrà restituito, pari a 5.800 SATS.

Applicando la formula della tassa, vediamo che rimangono effettivamente 200 SATS per i minori:

Frais = total inputs - total outputs
Frais = 10 000 - (4 000 + 5 800)
Frais = 10 000 - 9 800
Frais = 200

Quando un minatore riesce a convalidare un blocco, è autorizzato a riscuotere queste commissioni per tutte le transazioni incluse nel suo blocco, tramite la cosiddetta transazione "coinbase".

Creare UTXO su Bitcoin

Se avete seguito con attenzione i paragrafi precedenti, saprete che gli UTXO possono essere creati solo consumando altri UTXO esistenti. In questo modo, le monete Bitcoin formano una catena continua. Tuttavia, vi starete chiedendo come sono nati i primi UTXO di questa catena. Ciò solleva un problema simile a quello dell'uovo e della gallina: da dove provengono questi UTXO originali?

La risposta è nella transazione coinbase.

La coinbase è un tipo specifico di transazione Bitcoin, che è unica per ogni blocco ed è sempre la prima di queste. Permette al minatore che ha trovato una prova di lavoro valida di ricevere la ricompensa del blocco. Questa ricompensa è composta da due elementi: block grant e transaction fee, di cui si è parlato nella sezione precedente.

La transazione di coinbase è unica nel suo genere in quanto è l'unica in grado di creare bitcoin ex nihilo, senza la necessità di consumare input per generare output. Questi bitcoin creati ex novo sono quelli che potremmo definire "UTXO originali".

I bitcoin sovvenzionati in blocco sono nuovi BTC creati da zero, secondo un programma di emissione prestabilito nelle regole del consenso. La sovvenzione in blocchi viene dimezzata ogni 210.000 blocchi, cioè circa ogni quattro anni, in un processo noto come "dimezzamento". In origine, con ogni sovvenzione venivano creati 50 bitcoin, ma questo importo è gradualmente diminuito; attualmente, è di 3,125 bitcoin per blocco.

Per quanto riguarda le commissioni di transazione, sebbene anch'esse rappresentino BTC creati ex novo, non devono superare la differenza tra gli input e gli output totali di tutte le transazioni in un blocco. Abbiamo visto in precedenza che queste commissioni rappresentano la parte di input che non viene utilizzata nelle transazioni in uscita. Questa parte è tecnicamente "persa" durante la transazione e il miner ha il diritto di ricreare questo valore sotto forma di uno o più nuovi UTXO. Si tratta di un trasferimento di valore tra l'emittente della transazione e il miner che la aggiunge alla blockchain.

**> I bitcoin generati da una transazione coinbase sono soggetti a un periodo di maturità di 100 blocchi, durante il quale non possono essere spesi dal miner. Questa regola è stata pensata per evitare complicazioni legate all'utilizzo di bitcoin appena creati su una catena che potrebbe in seguito essere resa obsoleta.

Le implicazioni del modello UTXO

Innanzitutto, il modello UTXO influenza direttamente le commissioni delle transazioni di Bitcoin. Poiché la capacità di ogni blocco è limitata, i minatori favoriscono le transazioni che offrono le tariffe migliori in relazione allo spazio che occuperanno nel blocco. Infatti, più UTXO include una transazione nei suoi input e output, più è pesante e quindi richiede commissioni più elevate. Questo è uno dei motivi per cui spesso cerchiamo di ridurre il numero di UTXO nel nostro portafoglio, il che può anche influire sulla riservatezza, un argomento che affronteremo in dettaglio nella terza parte di questo corso.

In secondo luogo, come indicato nelle sezioni precedenti, le monete Bitcoin sono essenzialmente una catena di UTXO. Ogni transazione crea quindi un legame tra un UTXO passato e un UTXO futuro. Gli UTXO permettono quindi di seguire esplicitamente il percorso dei Bitcoin dalla loro creazione fino alla loro spesa attuale. Questa trasparenza può essere vista positivamente, in quanto consente a ciascun utente di accertarsi dell'autenticità dei bitcoin ricevuti. Tuttavia, è anche su questo principio di tracciabilità e verificabilità che si basa l'analisi della blockchain, una pratica destinata a compromettere la vostra riservatezza. Nella seconda parte del corso esamineremo in modo approfondito questa pratica.

Il modello di privacy di Bitcoin

Denaro: autenticità, integrità e doppia spesa

Una delle funzioni del denaro è quella di risolvere il problema della doppia coincidenza dei bisogni. In un sistema basato sul baratto, il completamento di uno scambio richiede non solo di trovare un individuo che ceda un bene corrispondente al mio bisogno, ma anche di fornirgli un bene di valore equivalente che soddisfi il suo stesso bisogno. Trovare questo equilibrio è una questione complessa.

Ecco perché usiamo il denaro per spostare il valore sia nello spazio che nel tempo.

Affinché la moneta risolva questo problema, è essenziale che la parte che fornisce un bene o un servizio sia convinta della sua capacità di spendere quella somma in un momento successivo. Pertanto, qualsiasi individuo razionale che desideri accettare una moneta, sia essa digitale o fisica, si assicurerà che essa soddisfi due criteri fondamentali:

Il pezzo deve avere integrità e autenticità ;**
e non deve essere speso due volte.**

Se si utilizza una moneta fisica, la prima caratteristica è la più complessa da affermare. In diversi periodi storici, l'integrità delle monete metalliche è stata spesso compromessa da pratiche come la rifilatura o la foratura. Nell'antica Roma, ad esempio, era pratica comune per i cittadini raschiare i bordi delle monete d'oro per raccogliere un po' di metallo prezioso, conservandolo per future transazioni. In questo modo il valore intrinseco della moneta veniva ridotto, ma il suo valore nominale rimaneva invariato. Questo è uno dei motivi per cui il bordo della moneta è stato successivamente scanalato.

L'autenticità è anche una caratteristica difficile da verificare su un supporto monetario fisico. Oggi le tecniche di lotta alla contraffazione sono sempre più complesse e costringono i rivenditori a investire in costosi sistemi di verifica.

D'altra parte, per la loro natura, la doppia spesa non è un problema per le valute fisiche. Se vi do una banconota da 10 euro, questa lascia irrevocabilmente il mio possesso ed entra nel vostro, il che esclude naturalmente qualsiasi possibilità di spesa multipla delle unità monetarie che rappresenta. In breve, non potrò più spendere questa banconota da 10 euro.

Per la moneta digitale, la difficoltà è diversa. Garantire l'autenticità e l'integrità di una moneta è spesso più semplice. Come abbiamo visto nella sezione precedente, il modello UTXO di Bitcoin consente di risalire all'origine di una moneta e quindi di verificare che sia stata effettivamente creata da un miner nel rispetto delle regole del consenso.

D'altra parte, garantire che non ci sia una doppia spesa è più complesso, poiché tutti i beni digitali sono essenzialmente informazioni. A differenza dei beni fisici, le informazioni non vengono suddivise quando vengono scambiate, ma si diffondono moltiplicandosi. Ad esempio, se vi invio un documento via e-mail, questo verrà duplicato. Non potete essere sicuri che io abbia cancellato il documento originale.

Prevenire la doppia spesa in Bitcoin

L'unico modo per evitare questa duplicazione di un asset digitale è quello di essere a conoscenza di tutti gli scambi sul sistema. In questo modo, possiamo sapere chi possiede cosa e aggiornare il patrimonio di ciascuno in base alle transazioni effettuate. Questo è ciò che accade, ad esempio, con la moneta scritturale nel sistema bancario. Quando si pagano 10 euro a un commerciante con la carta di credito, la banca registra lo scambio e aggiorna il libro dei conti.

Su Bitcoin, la doppia spesa viene impedita allo stesso modo. Cerchiamo di confermare l'assenza di una transazione che abbia già speso le monete in questione. Se le monete non sono mai state utilizzate, possiamo essere certi che non si verificherà una doppia spesa. Questo principio è stato descritto da Satoshi Nakamoto nel Libro Bianco con la famosa frase:

**L'unico modo per confermare l'assenza di una transazione è essere a conoscenza di tutte le transazioni

Ma a differenza del modello bancario, con Bitcoin non vogliamo doverci fidare di un'entità centrale. Quindi tutti gli utenti devono essere in grado di confermare l'assenza di doppie spese, senza affidarsi a terzi. Quindi tutti devono essere a conoscenza di tutte le transazioni Bitcoin. Per questo motivo le transazioni Bitcoin sono trasmesse pubblicamente su tutti i nodi della rete e registrate in chiaro sulla blockchain.

È proprio questa diffusione pubblica delle informazioni a complicare la protezione della privacy in Bitcoin. Nel sistema bancario tradizionale, in teoria, solo l'istituto finanziario è a conoscenza delle transazioni effettuate. Con Bitcoin, invece, tutti gli utenti sono informati di tutte le transazioni, attraverso i rispettivi nodi.

Il modello di riservatezza: sistema bancario vs. Bitcoin

Nel sistema tradizionale, il conto bancario è legato all'identità del cliente. Il banchiere è in grado di sapere quale conto bancario appartiene a quale cliente e quali transazioni sono associate ad esso. Tuttavia, questo flusso di informazioni è interrotto tra la banca e il pubblico. In altre parole, è impossibile conoscere il saldo e le transazioni di un conto bancario appartenente a un'altra persona. Solo la banca ha accesso a queste informazioni.

Ad esempio, il vostro banchiere sa che ogni mattina comprate la vostra baguette dal panettiere locale, ma il vostro vicino non è a conoscenza di questa transazione. In questo modo, il flusso di informazioni è accessibile alle parti interessate, in particolare alla banca, ma rimane inaccessibile agli estranei.

A causa del vincolo della diffusione pubblica delle transazioni che abbiamo visto nella sezione precedente, il modello di riservatezza di Bitcoin non può seguire il modello del sistema bancario. Nel caso di Bitcoin, poiché il flusso di informazioni non può essere interrotto tra le transazioni e il dominio pubblico, il modello di riservatezza si basa sulla separazione tra l'identità dell'utente e le transazioni stesse.

Ad esempio, se comprate una baguette dal fornaio, pagando in BTC, il vostro vicino, che ha un proprio nodo completo, può vedere la vostra transazione, così come può vedere tutte le altre transazioni del sistema. Tuttavia, se i principi di riservatezza sono rispettati, non dovrebbe essere in grado di collegare questa specifica transazione alla vostra identità.

Tuttavia, poiché le transazioni Bitcoin sono rese pubbliche, è comunque possibile stabilire dei collegamenti tra di esse per dedurre informazioni sulle parti coinvolte. Questa attività costituisce addirittura una specialità a sé stante, nota come "analisi della blockchain". Nella prossima parte del corso, vi invito a esplorare i fondamenti dell'analisi della blockchain, in modo che possiate capire come vengono tracciati i vostri bitcoin e difendervi meglio da essi.

Comprendere e proteggere dall'analisi della catena

Che cos'è l'analisi della catena Bitcoin?

Definizione e funzionamento

L'analisi della catena di bit è la pratica di tracciare il flusso di bitcoin sulla catena di bit. In generale, l'analisi della catena si basa sull'osservazione di caratteristiche in campioni di transazioni precedenti. Consiste quindi nell'identificare queste stesse caratteristiche in una transazione che si desidera analizzare e nel dedurre da esse interpretazioni plausibili. Questo metodo di risoluzione dei problemi, basato su un approccio pratico per trovare una soluzione sufficientemente buona, è noto come "euristica".

In parole povere, l'analisi della catena si articola in tre fasi principali:

Osservare la blockchain ;
L'identificazione di caratteristiche note ;
**La deduzione di ipotesi

L'analisi della blockchain può essere eseguita da chiunque. È sufficiente accedere alle informazioni pubbliche della blockchain tramite un nodo completo per osservare i movimenti delle transazioni e formulare ipotesi. Esistono anche strumenti gratuiti che facilitano questa analisi, come OXT.me, che esploreremo in dettaglio negli ultimi due capitoli di questa sezione. Tuttavia, il rischio principale per la riservatezza proviene dalle aziende specializzate nell'analisi delle stringhe. Queste aziende hanno portato l'analisi della blockchain su scala industriale e vendono i loro servizi a istituzioni finanziarie e governi. Tra queste aziende, Chainalysis è sicuramente la più nota.

Obiettivi dell'analisi di filiera

Uno degli obiettivi dell'analisi della blockchain è raggruppare varie attività su Bitcoin per determinare l'unicità dell'utente che le ha svolte. Successivamente, sarà possibile cercare di collegare questo gruppo di attività a un'identità reale.

Ripensate al capitolo precedente. Ho spiegato perché il modello di privacy di Bitcoin era originariamente basato sulla separazione dell'identità dell'utente dalle transazioni. Si sarebbe quindi tentati di pensare che l'analisi della blockchain sia inutile, poiché anche se riusciamo ad aggregare le attività onchain, non possiamo associarle a un'identità reale.

In teoria, questa affermazione è corretta. Nella prima parte di questo corso abbiamo visto che le coppie di chiavi crittografiche vengono utilizzate per stabilire le condizioni di UTXO. In sostanza, queste coppie di chiavi non rivelano alcuna informazione sull'identità dei loro possessori. Quindi, anche se riusciamo a raggruppare le attività associate a diverse coppie di chiavi, questo non ci dice nulla sull'entità che sta dietro a queste attività.

Tuttavia, la realtà pratica è molto più complessa. Esiste una moltitudine di comportamenti che possono collegare un'identità reale all'attività onchain. In analisi, questo si chiama punto di ingresso, e ce ne sono moltissimi.

Il più comune è il KYC (Know Your Customer). Se ritirate i vostri Bitcoin da una piattaforma regolamentata a uno dei vostri indirizzi personali di ricezione, alcune persone sono in grado di collegare la vostra identità a quell'indirizzo. Più in generale, un punto di ingresso può essere qualsiasi forma di interazione tra la vostra vita reale e una transazione Bitcoin. Ad esempio, se pubblicate un indirizzo di ricezione sui vostri social network, questo potrebbe essere un punto di ingresso per l'analisi. Se si effettua un pagamento in Bitcoin al panettiere, questi sarà in grado di associare il vostro volto (parte della vostra identità) a un indirizzo Bitcoin.

Questi punti di accesso sono praticamente inevitabili quando si utilizza Bitcoin. Anche se possiamo cercare di limitarne la portata, saranno sempre presenti. Ecco perché è fondamentale combinare metodi volti a preservare la privacy. Sebbene mantenere una separazione tra la vostra identità reale e le vostre transazioni sia un approccio interessante, oggi rimane insufficiente. Infatti, se tutte le attività onchain possono essere raggruppate, anche il più piccolo punto di accesso può compromettere l'unico livello di riservatezza stabilito.

Difendersi dall'analisi della catena

Dobbiamo quindi essere in grado di affrontare l'analisi della blockchain anche nell'uso di Bitcoin. Così facendo, possiamo ridurre al minimo l'aggregazione delle nostre attività e limitare l'impatto di un punto di accesso sulla nostra privacy.

Quale modo migliore per contrastare l'analisi della blockchain se non quello di conoscere i metodi utilizzati? Se volete sapere come migliorare la vostra privacy su Bitcoin, dovete comprendere questi metodi. Questo vi permetterà di comprendere meglio tecniche come coinjoin o payjoin (tecniche che esamineremo nelle parti finali del corso) e di ridurre gli errori che potreste commettere.

https://planb.network/tutorials/privacy/on-chain/coinjoin-samourai-wallet-e566803d-ab3f-4d98-9136-5462009262ef

https://planb.network/tutorials/privacy/on-chain/payjoin-848b6a23-deb2-4c5f-a27e-93e2f842140f

A questo proposito, possiamo tracciare un'analogia con la crittografia e la crittoanalisi. Un buon crittografo è innanzitutto un buon crittoanalista. Per ideare un nuovo algoritmo di crittografia, è necessario sapere quali attacchi dovrà affrontare e studiare perché gli algoritmi precedenti sono stati violati. Lo stesso principio si applica alla privacy di Bitcoin. Comprendere i metodi di analisi della blockchain è la chiave per proteggersi da questi attacchi. Ecco perché ho incluso un'intera sezione sull'analisi della catena in questo corso di formazione.

Metodi di analisi della catena

È importante capire che l'analisi delle stringhe non è una scienza esatta. Si basa su euristiche derivate da osservazioni precedenti o da interpretazioni logiche. Queste regole ci permettono di ottenere risultati abbastanza affidabili, ma mai con precisione assoluta. In altre parole, l'analisi delle stringhe comporta sempre una dimensione di probabilità nelle conclusioni raggiunte. Ad esempio, è possibile stimare con vari gradi di certezza che due indirizzi appartengano alla stessa entità, ma la certezza totale sarà sempre fuori portata.

Il senso dell'analisi a catena sta proprio nell'aggregazione di varie euristiche per ridurre al minimo il rischio di errore. In un certo senso, è un'accumulazione di prove che ci avvicina alla realtà.

Queste famose euristiche possono essere raggruppate in diverse categorie, che descriveremo in dettaglio di seguito:

Modelli di transazione ;**
Euristica interna alle transazioni ;**
Euristica esterna alla transazione.**

Satoshi Nakamoto e l'analisi della catena

Le prime due euristiche di analisi della catena sono state scoperte da Satoshi Nakamoto stesso. Ne parla nella Parte 10 del Libro Bianco di Bitcoin. Esse sono :

cIOH (Euristica della proprietà dell'input comune);
e il riutilizzo degli indirizzi.

Fonte: S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf, 2009.

Vedremo quali sono nei capitoli successivi, ma è già interessante notare che queste due euristiche mantengono ancora oggi una preminenza nell'analisi delle catene.

Modelli di transazione

Un modello di transazione è semplicemente un modello o una struttura generale di una transazione tipica, che può essere trovata sulla blockchain e di cui si conosce la probabile interpretazione. Quando studiamo i pattern, ci concentriamo su una singola transazione e la analizziamo ad alto livello.

In altre parole, esamineremo solo il numero di UTXO in ingresso e il numero di UTXO in uscita, senza soffermarci sui dettagli più specifici o sull'ambiente della transazione. In base allo schema osservato, possiamo interpretare la natura della transazione. Cercheremo quindi le caratteristiche della sua struttura e ne dedurremo un'interpretazione.

In questa sezione esamineremo insieme i principali modelli di transazione che si incontrano nell'analisi delle catene e, per ogni modello, vi fornirò la probabile interpretazione di questa struttura, oltre a un esempio concreto.

Spedizione singola (o pagamento singolo)

Cominciamo con un modello molto comune, poiché è quello che emerge nella maggior parte dei pagamenti in bitcoin. Il modello di pagamento semplice è caratterizzato dal consumo di uno o più UTXO come input e dalla produzione di 2 UTXO come output. Questo modello si presenta quindi come segue:

Quando individuiamo questa struttura di transazione sulla blockchain, possiamo già trarre un'interpretazione. Come suggerisce il nome, questo modello indica che siamo in presenza di una transazione di invio o di pagamento. L'utente ha consumato il proprio UTXO in ingresso per soddisfare in uscita un UTXO di pagamento e un UTXO di scambio (denaro restituito allo stesso utente).

Sappiamo quindi che l'utente osservato probabilmente non è più in possesso di uno dei due UTXO di uscita (l'UTXO di pagamento), ma è ancora in possesso dell'altro UTXO (l'UTXO di scambio).

Per il momento non possiamo specificare quale uscita rappresenti quale UTXO, perché non è questo lo scopo dello studio del modello. Ci arriveremo affidandoci all'euristica che studieremo nelle sezioni successive. In questa fase, il nostro obiettivo si limita a identificare la natura della transazione in questione, che in questo caso è un semplice invio.

Ad esempio, ecco una transazione Bitcoin che adotta lo schema di invio semplice:

b6cc79f45fd2d7669ff94db5cb14c45f1f879ea0ba4c6e3d16ad53a18c34b769

Source : Mempool.space

Dopo questo primo esempio, dovreste aver capito meglio cosa significa studiare un "modello di transazione". Esaminiamo una transazione concentrandoci esclusivamente sulla sua struttura, senza prendere in considerazione l'ambiente o i dettagli specifici della transazione. In questa prima fase, guardiamo solo al quadro generale.

Ora che avete capito cos'è un modello, passiamo agli altri modelli esistenti.

Spazzare

Questo secondo modello è caratterizzato dal consumo di un singolo UTXO come input e dalla produzione di un singolo UTXO come output.

L'interpretazione di questo modello è che siamo in presenza di un auto-trasferimento. L'utente ha trasferito i suoi bitcoin a se stesso, a un altro indirizzo che gli appartiene. Poiché non c'è scambio sulla transazione, è altamente improbabile che ci troviamo in presenza di un pagamento. Infatti, quando viene effettuato un pagamento, è quasi impossibile che il pagatore disponga di un UTXO corrispondente esattamente all'importo richiesto dal venditore, più la commissione di transazione. In generale, il pagatore è quindi obbligato a produrre un output di scambio.

Sappiamo quindi che l'utente osservato è probabilmente ancora in possesso di questo UTXO. Nel contesto di un'analisi a catena, se sappiamo che l'UTXO utilizzato come input della transazione appartiene ad Alice, possiamo assumere che anche l'UTXO utilizzato come output appartenga a lei. In seguito sarà interessante trovare euristiche interne alla transazione che possano rafforzare questa ipotesi (le esamineremo nel capitolo 3.3).

Ad esempio, ecco una transazione Bitcoin che adotta lo schema sweep:

35f1072a0fda5ae106efb4fda871ab40e1f8023c6c47f396441ad4b995ea693d

Source : Mempool.space

Attenzione, però, questo tipo di schema può anche rivelare un auto-trasferimento al conto di una piattaforma di scambio di criptovalute. Sarà lo studio degli indirizzi noti e il contesto della transazione a dirci se si tratta di una strisciata verso un portafoglio di autodeposito o di un prelievo verso una piattaforma. In effetti, gli indirizzi delle piattaforme di scambio sono spesso facilmente identificabili.

Riprendiamo l'esempio di Alice: se la scansione porta a un indirizzo noto a una piattaforma (come Binance, ad esempio), ciò può significare che i bitcoin sono stati trasferiti fuori dal possesso diretto di Alice, probabilmente con l'intenzione di venderli o conservarli su questa piattaforma. D'altra parte, se l'indirizzo di destinazione è sconosciuto, è ragionevole supporre che si tratti semplicemente di un altro portafoglio ancora appartenente ad Alice. Ma questo tipo di studio rientra più nella categoria delle euristiche che dei modelli.

Consolidamento

Questo modello è caratterizzato dal consumo di diversi UTXO in ingresso e dalla produzione di un singolo UTXO in uscita.

L'interpretazione di questo schema è che siamo in presenza di un consolidamento. Si tratta di una pratica comune tra gli utenti di Bitcoin, finalizzata alla fusione di più UTXO in previsione di un possibile aumento delle commissioni di transazione. Eseguendo questa operazione in un periodo in cui le commissioni sono basse, è possibile risparmiare sulle commissioni future. Parleremo più diffusamente di questa pratica nel capitolo 4.3.

Possiamo dedurre che l'utente dietro questo modello di transazione era probabilmente in possesso di tutti gli UTXO in ingresso ed è ancora in possesso dell'UTXO in uscita. Quindi probabilmente si tratta di un trasferimento automatico.

Come lo sweep, anche questo tipo di schema può rivelare un autotrasferimento al conto di una piattaforma di scambio. Sarà lo studio degli indirizzi noti e del contesto della transazione a dirci se si tratta di un consolidamento verso un portafoglio di autodeposito o di un prelievo verso una piattaforma.

Ad esempio, ecco una transazione Bitcoin che adotta il modello di consolidamento:

77c16914211e237a9bd51a7ce0b1a7368631caed515fe51b081d220590589e94

Source : Mempool.space

In un'analisi di catena, questo modello può rivelare una grande quantità di informazioni. Ad esempio, se sappiamo che uno degli input appartiene ad Alice, possiamo supporre che anche tutti gli altri input e l'output di questa transazione appartengano a lei. Questa ipotesi permetterebbe di risalire la catena delle transazioni precedenti per scoprire e analizzare altre transazioni che potrebbero essere associate ad Alice.

Spese raggruppate

Questo modello è caratterizzato dal consumo di pochi UTXO come input (spesso uno solo) e dalla produzione di molti UTXO come output.

L'interpretazione di questo modello è che siamo in presenza di una spesa raggruppata. È una pratica che probabilmente rivela un'attività economica molto grande, come una piattaforma di scambio. La spesa raggruppata consente a queste entità di risparmiare sui costi combinando le spese in un'unica transazione.

Da questo modello possiamo dedurre che gli UTXO in ingresso provengono da un'azienda con un alto livello di attività economica e che gli UTXO in uscita si disperderanno. Molti appartengono ai clienti dell'azienda che hanno ritirato bitcoin dalla piattaforma. Altri potranno andare a società partner. Infine, ci saranno sicuramente uno o più scambi che torneranno alla società emittente.

Ad esempio, ecco una transazione Bitcoin che adotta lo schema di spesa in bundle (presumibilmente si tratta di una transazione emessa dalla piattaforma Bybit):

8a7288758b6e5d550897beedd13c70bcbaba8709af01a7dbcc1f574b89176b43

Source : Mempool.space

Transazioni specifiche del protocollo

Tra i modelli di transazione, possiamo anche identificare quelli che rivelano l'uso di un protocollo specifico. Ad esempio, le coinjoin di Whirlpool (discusse nella parte 5) avranno una struttura facilmente identificabile che le differenzia da altre transazioni più convenzionali.

L'analisi di questo schema suggerisce che probabilmente siamo in presenza di una transazione collaborativa. È anche possibile osservare una coinjoin. Se quest'ultima ipotesi si rivela corretta, il numero di uscite potrebbe fornirci una stima approssimativa del numero di partecipanti alla coinjoin.

Ad esempio, ecco una transazione Bitcoin che adotta lo schema di transazione collaborativa coinjoin:

00601af905bede31086d9b1b79ee8399bd60c97e9c5bba197bdebeee028b9bea

Source : Mempool.space

Esistono molti altri protocolli con strutture specifiche. Ad esempio, esistono transazioni Wabisabi, transazioni Stamps e transazioni Runes.

Grazie a questi modelli di transazione, possiamo già interpretare una certa quantità di informazioni su una determinata transazione. Ma la struttura delle transazioni non è l'unica fonte di informazioni da analizzare. Possiamo anche studiarne i dettagli. Questi dettagli interni sono ciò che mi piace chiamare "euristica interna", e li esamineremo nel prossimo capitolo.

Euristica interna

Un'euristica interna è una caratteristica specifica che identifichiamo all'interno di una transazione stessa, senza bisogno di esaminare il suo ambiente, e che ci permette di fare deduzioni. A differenza dei pattern, che si concentrano sulla struttura complessiva della transazione ad alto livello, le euristiche interne si basano sull'insieme dei dati estraibili. Questi includono:

Gli importi dei vari UTXO in entrata e in uscita;
Tutto ciò che riguarda gli script: indirizzi di ricezione, versioning, locktime...

In generale, questo tipo di euristica ci permetterà di identificare lo scambio in una specifica transazione. In questo modo, possiamo perpetuare il tracciamento di un'entità in diverse transazioni. Infatti, se identifichiamo un UTXO appartenente a un utente che vogliamo tracciare, è fondamentale determinare, quando effettua una transazione, quale output è stato trasferito a un altro utente e quale output rappresenta lo scambio, che quindi rimane in suo possesso.

Ancora una volta, vorrei ricordare che queste euristiche non sono assolutamente precise. Prese singolarmente, ci permettono solo di identificare gli scenari probabili. È l'accumulo di più euristiche che aiuta a ridurre l'incertezza, senza mai poterla eliminare del tutto.

Somiglianze interne

Questa euristica prevede lo studio delle somiglianze tra gli input e gli output di una stessa transazione. Se si osserva la stessa caratteristica sugli input e su uno solo degli output della transazione, è probabile che questo output costituisca lo scambio.

La caratteristica più evidente è il riutilizzo di un indirizzo di ricezione nella stessa transazione.

Questa euristica lascia poco spazio ai dubbi. A meno che non sia stata violata la sua chiave privata, lo stesso indirizzo di ricezione rivela necessariamente l'attività di un singolo utente. L'interpretazione che ne deriva è che lo scambio di transazioni è l'uscita con lo stesso indirizzo dell'ingresso. Possiamo quindi continuare a risalire all'individuo a partire da questo scambio.

Ad esempio, ecco una transazione a cui probabilmente si può applicare questa euristica:

54364146665bfc453a55eae4bfb8fdf7c721d02cb96aadc480c8b16bdeb8d6d0

Source : Mempool.space

Queste somiglianze tra input e output non si fermano al riutilizzo degli indirizzi. Qualsiasi somiglianza nell'uso degli script può essere utilizzata per applicare un'euristica. Ad esempio, a volte possiamo osservare lo stesso versioning tra l'input e uno degli output della transazione.

In questo diagramma, possiamo vedere che l'ingresso n° 0 sblocca uno script P2WPKH (SegWit V0 che inizia con bc1q). L'uscita n° 0 utilizza lo stesso tipo di script. L'uscita n° 1, invece, utilizza uno script P2TR (SegWit V1 che inizia con bc1p). L'interpretazione di questa caratteristica è che è probabile che l'indirizzo con lo stesso versioning dell'ingresso sia l'indirizzo di scambio. Pertanto, apparterrebbe sempre allo stesso utente.

Ecco una transazione a cui probabilmente si può applicare questa euristica:

db07516288771ce5d0a06b275962ec4af1b74500739f168e5800cbcb0e9dd578

Source : Mempool.space

In quest'ultimo caso, possiamo notare che l'ingresso n. 0 e l'uscita n. 1 utilizzano script P2WPKH (SegWit V0), mentre l'uscita n. 0 utilizza uno script P2PKH diverso (Legacy).

Nei primi anni 2010, questa euristica basata sulla versione degli script era relativamente poco utile a causa dei limitati tipi di script disponibili. Tuttavia, nel corso del tempo e con i successivi aggiornamenti di Bitcoin, è stata introdotta una crescente varietà di tipi di script. Questa euristica sta quindi diventando sempre più rilevante, poiché con una gamma più ampia di tipi di script, gli utenti si dividono in gruppi più piccoli, aumentando così le possibilità di applicare questa euristica di riutilizzo della versione interna. Per questo motivo, solo dal punto di vista della riservatezza, è consigliabile optare per il tipo di script più comune. Ad esempio, nel momento in cui scrivo queste righe, gli script Taproot (bc1p) sono meno utilizzati degli script SegWit V0 (bc1q). Sebbene i primi offrano vantaggi economici e di riservatezza in alcuni contesti specifici, per gli usi più tradizionali a firma singola può essere sensato attenersi a uno standard più vecchio per motivi di riservatezza, fino a quando il nuovo standard non sarà più ampiamente adottato.

Pagamenti con numeri tondi

Un'altra euristica interna che può aiutarci a identificare lo scambio è l'euristica del numero tondo. In generale, di fronte a uno schema di pagamento semplice (1 ingresso e 2 uscite), se una delle uscite spende un importo tondo, allora questo rappresenta il pagamento.

Per eliminazione, se un output rappresenta il pagamento, l'altro rappresenta lo scambio. Si può quindi interpretare come probabile che l'utente dell'input sia sempre in possesso dell'output identificato come scambio.

Va sottolineato che questa euristica non è sempre applicabile, poiché la maggior parte dei pagamenti viene ancora effettuata in unità di conto fiduciarie. Infatti, quando un commerciante in Francia accetta bitcoin, in genere non mostra prezzi stabili in sats. Al contrario, opterà per una conversione tra il prezzo in euro e l'importo in bitcoin da pagare. Pertanto, alla fine della transazione non dovrebbero esserci numeri tondi.

Tuttavia, un analista potrebbe cercare di effettuare questa conversione tenendo conto del tasso di cambio in vigore al momento della trasmissione della transazione sulla rete. Prendiamo l'esempio di una transazione con un ingresso di 97.552 sats e due uscite, una di 31.085 sats e l'altra di 64.152 sats. A prima vista, questa transazione non sembra comportare importi arrotondati. Tuttavia, applicando il tasso di cambio di 64,339 euro al momento della transazione, si ottiene la seguente conversione in euro:

Un input di 62,76 euro;
Una produzione di 20 euro;
Una produzione di 41,27 euro.

Una volta convertita in valuta fiat, questa transazione può essere utilizzata per applicare l'euristica del pagamento con importo arrotondato. L'uscita da 20 euro è probabilmente andata a un commerciante, o almeno ha cambiato proprietà. Per deduzione, è probabile che l'uscita da 41,27 euro sia rimasta in possesso dell'utente originale.

Se un giorno il bitcoin diventerà l'unità di conto preferita nei nostri scambi, questa euristica potrebbe diventare ancora più utile per l'analisi.

Ad esempio, ecco una transazione a cui probabilmente si può applicare questa euristica:

2bcb42fab7fba17ac1b176060e7d7d7730a7b807d470815f5034d52e96d2828a

Source : Mempool.space

La produzione più grande

Quando identifichiamo un divario sufficientemente grande tra i due output delle transazioni su un modello di pagamento semplice, possiamo stimare che l'output maggiore è probabilmente quello in valuta estera.

Questa euristica del massimo rendimento è sicuramente la più imprecisa di tutte. Da sola è piuttosto debole. Tuttavia, questa caratteristica può essere combinata con altre euristiche per ridurre l'incertezza della nostra interpretazione.

Ad esempio, se stiamo esaminando una transazione con un pagamento tondo e uno più grande, l'applicazione congiunta dell'euristica del pagamento tondo e dell'euristica del pagamento più grande riduce il nostro livello di incertezza.

Ad esempio, ecco una transazione a cui probabilmente si può applicare questa euristica:

b79d8f8e4756d34bbb26c659ab88314c220834c7a8b781c047a3916b56d14dcf

Source : Mempool.space

Euristica esterna

Lo studio delle euristiche esterne significa analizzare le somiglianze, i modelli e le caratteristiche di alcuni elementi che non sono specifici della transazione stessa. In altre parole, mentre prima ci limitavamo a sfruttare gli elementi intrinseci alla transazione con l'euristica interna, ora stiamo ampliando il nostro campo di analisi per includere l'ambiente della transazione, grazie all'euristica esterna.

Riutilizzo dell'indirizzo

Questa è una delle euristiche più conosciute dai bitcoiners. Il riutilizzo degli indirizzi consente di stabilire un collegamento tra transazioni diverse e UTXO diversi. Si verifica quando un indirizzo di ricezione Bitcoin viene utilizzato più volte.

Pertanto, è possibile sfruttare il riutilizzo degli indirizzi all'interno della stessa transazione come euristica interna per identificare lo scambio (come abbiamo visto nel capitolo precedente). Ma il riutilizzo degli indirizzi può essere utilizzato anche come euristica esterna per riconoscere l'unicità di un'entità dietro diverse transazioni.

L'interpretazione del riutilizzo di un indirizzo è che tutti gli UTXO bloccati su quell'indirizzo appartengono (o sono appartenuti) alla stessa entità. Questa euristica lascia poco spazio all'incertezza. Una volta identificata, è probabile che l'interpretazione risultante corrisponda alla realtà. Consente quindi di raggruppare diverse attività onchain.

Come spiegato nell'introduzione alla Parte 3, questa euristica è stata scoperta dallo stesso Satoshi Nakamoto. Nel Libro Bianco, egli menziona una soluzione per aiutare gli utenti a non generarla, che consiste semplicemente nell'utilizzare un indirizzo vuoto per ogni nuova transazione:

"Come ulteriore firewall, si potrebbe usare una nuova coppia di chiavi per ogni transazione, in modo da non collegarle a un proprietario comune._"

Fonte: S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf, 2009.

Ad esempio, ecco un indirizzo che viene riutilizzato in diverse transazioni:

bc1qqtmeu0eyvem9a85l3sghuhral8tk0ar7m4a0a0

Fonte : Mempool.space

Somiglianza di scrittura e impronte di portafogli

Oltre al riutilizzo degli indirizzi, esistono molte altre euristiche che consentono di collegare le azioni allo stesso portafoglio o cluster di indirizzi.

In primo luogo, un analista può cercare le somiglianze nell'uso degli script. Ad esempio, alcuni script minoritari come multisig possono essere più facili da individuare rispetto agli script SegWit V0. Più grande è il gruppo in cui ci nascondiamo, più difficile è individuarci. Questo è uno dei motivi per cui, nei buoni protocolli Coinjoin, tutti i partecipanti utilizzano esattamente lo stesso tipo di script.

Più in generale, un analista può anche concentrarsi sulle impronte digitali caratteristiche di un portafoglio. Si tratta di processi specifici all'uso che possono essere identificati al fine di sfruttarli come euristica di tracciamento. In altre parole, se osserviamo un accumulo delle stesse caratteristiche interne sulle transazioni attribuite all'entità tracciata, possiamo cercare di identificare queste stesse caratteristiche su altre transazioni.

Ad esempio, saremo in grado di identificare che l'utente tracciato invia sistematicamente le sue modifiche a indirizzi P2TR (bc1p...). Se questo processo si ripete, possiamo usarlo come euristica per il resto della nostra analisi. Possiamo anche utilizzare altre impronte digitali, come l'ordine degli UTXO, la posizione della modifica negli output, la segnalazione RBF (Replace-by-Fee) o il numero di versione, il campo nSequence e il campo nLockTime.

Come sottolinea @LaurentMT in Space Kek #19 (un podcast in lingua francese), l'utilità delle impronte digitali di portafoglio nell'analisi delle catene sta aumentando notevolmente nel tempo. In effetti, il numero crescente di tipi di script e la diffusione sempre più progressiva di queste nuove funzionalità da parte dei software di portafoglio accentuano le differenze. In alcuni casi, è addirittura possibile identificare l'esatto software utilizzato dall'entità monitorata. È quindi importante capire che lo studio delle impronte di portafoglio è particolarmente rilevante per le transazioni recenti, piuttosto che per quelle avviate nei primi anni 2010.

In sintesi, un'impronta può essere qualsiasi pratica specifica, eseguita automaticamente dal portafoglio o manualmente dall'utente, che possiamo trovare su altre transazioni per aiutarci nella nostra analisi.

L'euristica della proprietà dell'input comune (CIOH)

L'euristica della proprietà comune degli input (CIOH) è un'euristica che afferma che quando una transazione ha più input, è probabile che tutti provengano da un'unica entità. Di conseguenza, la loro proprietà è comune.

Per applicare il CIOH, osserviamo innanzitutto una transazione con diversi ingressi. Può trattarsi di 2 ingressi o di 30 ingressi. Una volta identificata questa caratteristica, verifichiamo se la transazione rientra in un modello di transazione noto. Ad esempio, se ci sono 5 ingressi con un importo più o meno uguale e 5 uscite con un importo esattamente uguale, sapremo che si tratta della struttura di una coinjoin. Non saremo in grado di applicare il CIOH.

D'altra parte, se la transazione non rientra in nessun modello di transazione collaborativa noto, possiamo interpretare che tutti gli input provengono probabilmente dalla stessa entità. Questo può essere molto utile per estendere un cluster già noto o per continuare una traccia.

CIOH è stato scoperto da Satoshi Nakamoto. Ne parla nella parte 10 del Libro Bianco:

"[...] il collegamento è inevitabile con le transazioni a più voci, che rivelano necessariamente che le loro voci erano detenute dallo stesso proprietario. Il rischio è che se il proprietario di una chiave viene rivelato, i collegamenti possono rivelare altre transazioni che appartenevano allo stesso proprietario."

È particolarmente affascinante notare che Satoshi Nakamoto, ancor prima del lancio ufficiale di Bitcoin, aveva già individuato le due principali vulnerabilità per la privacy degli utenti, ovvero CIOH e il riutilizzo degli indirizzi. Una tale lungimiranza è notevole, poiché queste due euristiche rimangono, ancora oggi, le più utili nell'analisi della blockchain.

Per fare un esempio, ecco una transazione su cui probabilmente possiamo applicare il CIOH:

20618e63b6eed056263fa52a2282c8897ab2ee71604c7faccfe748e1a202d712

Source : Mempool.space

Dati fuori catena

Naturalmente, l'analisi della catena non si limita esclusivamente ai dati onchain. Per affinare l'analisi è possibile utilizzare qualsiasi dato proveniente da un'analisi precedente o disponibile su Internet.

Ad esempio, se osserviamo che le transazioni tracciate vengono sistematicamente trasmesse dallo stesso nodo Bitcoin e riusciamo a identificare il suo indirizzo IP, potremmo essere in grado di identificare altre transazioni provenienti dalla stessa entità, oltre a determinare parte dell'identità dell'emittente. Sebbene questa pratica non sia facilmente realizzabile, in quanto richiede il funzionamento di numerosi nodi, può essere utilizzata da alcune società specializzate nell'analisi della blockchain.

L'analista ha anche la possibilità di basarsi su analisi precedentemente rese open-source o sulle proprie analisi precedenti. Forse potremo trovare un output che punta a un cluster di indirizzi che abbiamo già identificato. A volte è anche possibile fare affidamento su output che puntano a una piattaforma di scambio, poiché gli indirizzi di queste aziende sono generalmente noti.

Allo stesso modo, è possibile eseguire un'analisi per eliminazione. Ad esempio, se analizzando una transazione con due uscite, una di queste si riferisce a un cluster di indirizzi già noto, ma distinto dall'entità che stiamo tracciando, possiamo interpretare che l'altra uscita rappresenta probabilmente lo scambio.

L'analisi del canale comprende anche una componente OSINT (Open Source Intelligence) un po' più generale, che prevede ricerche su Internet. È per questo motivo che sconsigliamo di pubblicare indirizzi direttamente sui social network o su un sito web, che siano pseudonimi o meno.

Modelli temporali

Ci pensiamo meno, ma alcuni comportamenti umani sono riconoscibili su catena. Forse il più utile in un'analisi è il vostro modello di sonno! Sì, quando si dorme non si trasmettono transazioni Bitcoin. Ma in genere si dorme più o meno alla stessa ora. Ecco perché è prassi comune utilizzare l'analisi temporale nell'analisi della blockchain. In parole povere, si tratta di un censimento degli orari in cui le transazioni di una determinata entità vengono trasmesse alla rete Bitcoin. Analizzando questi schemi temporali, possiamo dedurre una grande quantità di informazioni.

Innanzitutto, un'analisi temporale può talvolta identificare la natura dell'entità tracciata. Se osserviamo che le transazioni vengono trasmesse in modo costante nell'arco delle 24 ore, allora questo tradisce un alto livello di attività economica. L'entità dietro queste transazioni è probabilmente un'azienda, potenzialmente internazionale e forse con procedure interne automatizzate.

Ad esempio, ho riconosciuto questo schema qualche mese fa quando ho analizzato la transazione che aveva erroneamente allocato 19 bitcoin in commissioni. Una semplice analisi temporale mi ha permesso di ipotizzare che si trattava di un servizio automatizzato, e quindi probabilmente di una grande entità come una piattaforma di scambio.

Infatti, pochi giorni dopo, si è scoperto che i fondi appartenevano a PayPal, tramite la piattaforma di scambio Paxos.

Al contrario, se vediamo che l'andamento temporale è piuttosto distribuito su 16 ore specifiche, allora possiamo stimare che si tratta di un singolo utente, o forse di un'azienda locale a seconda dei volumi scambiati.

Oltre alla natura dell'entità osservata, il modello temporale può anche dirci approssimativamente dove si trova l'utente, grazie ai fusi orari. In questo modo, possiamo confrontare altre transazioni e utilizzare i loro timestamp come un'ulteriore euristica da aggiungere alla nostra analisi.

Ad esempio, sull'indirizzo multiuso di cui ho parlato prima, possiamo vedere che le transazioni, sia in entrata che in uscita, sono concentrate in un intervallo di 13 ore.

bc1qqtmeu0eyvem9a85l3sghuhral8tk0ar7m4a0a0

Fonte : OXT.me

Questo intervallo corrisponde probabilmente all'Europa, all'Africa o al Medio Oriente. Possiamo quindi supporre che l'utente dietro queste transazioni viva in queste aree.

In un altro modo, un'analisi temporale di questo tipo ha anche portato all'ipotesi che Satoshi Nakamoto non operasse dal Giappone, ma dagli Stati Uniti: The Time Zones of Satoshi Nakamoto

Messa in pratica con l'esploratore a blocchi

In questo capitolo finale, metteremo in pratica i concetti studiati finora. Vi mostrerò esempi di transazioni Bitcoin reali e voi dovrete estrarre le informazioni che vi chiedo.

Idealmente, per eseguire questi esercizi, sarebbe preferibile l'uso di uno strumento professionale di analisi della catena. Tuttavia, dopo l'arresto dei creatori di Samourai Wallet, l'unico strumento di analisi gratuito OXT.me non è più disponibile. Per questi esercizi opteremo quindi per un classico block explorer. Consiglio di utilizzare Mempool.space per le sue numerose funzioni e la gamma di strumenti di analisi della catena, ma potete anche optare per un altro explorer come Bitcoin Explorer.

Per cominciare, vi presento gli esercizi. Utilizzate l'esploratore di blocchi per completarli e scrivete le vostre risposte su un foglio di carta. Poi, alla fine di questo capitolo, vi fornirò le risposte in modo che possiate controllare e correggere i vostri risultati.

Le transazioni selezionate per questi esercizi sono state scelte in modo casuale per le loro caratteristiche. Questo capitolo è destinato esclusivamente a scopi educativi e informativi. Vorrei chiarire che non sostengo né incoraggio l'uso di questi strumenti per scopi dannosi. Lo scopo è quello di insegnare a proteggersi dall'analisi delle stringhe, non di condurre analisi per esporre informazioni private di altre persone.

Esercizio 1

Identificatore della transazione da analizzare :

3769d3b124e47ef4ffb5b52d11df64b0a3f0b82bb10fd6b98c0fd5111789bef7

Come si chiama il modello di questa transazione e quali interpretazioni plausibili si possono trarre esaminando solo il suo modello, cioè la struttura della transazione?

Esercizio 2

Identificatore della transazione da analizzare :

baa228f6859ca63e6b8eea24ffad7e871713749d693ebd85343859173b8d5c20

Come si chiama il modello di questa transazione e quali interpretazioni plausibili si possono trarre esaminando solo il suo modello, cioè la struttura della transazione?

Esercizio 3

Identificatore della transazione da analizzare :

3a9eb9ccc3517cc25d1860924c66109262a4b68f4ed2d847f079b084da0cd32b

Qual è il modello per questa transazione?

Dopo aver identificato il suo modello, utilizzando l'euristica interna della transazione, quale output è probabile che rappresenti lo scambio?

Esercizio 4

Identificatore della transazione da analizzare :

35f0b31c05503ebfdf7311df47f68a048e992e5cf4c97ec34aa2833cc0122a12

Qual è il modello per questa transazione?

Dopo aver identificato il suo modello, utilizzando l'euristica interna della transazione, quale output è probabile che rappresenti lo scambio?

Esercizio 5

Immaginiamo che Loïc abbia pubblicato uno dei suoi indirizzi di ricezione di Bitcoin sul social network Twitter:

bc1qja0hycrv7g9ww00jcqanhfpqmzx7luqalum3vu

Sulla base di queste informazioni e utilizzando solo l'euristica del riutilizzo degli indirizzi, quali transazioni Bitcoin possono essere collegate all'identità di Loïc?

Ovviamente, non sono il vero proprietario di questo indirizzo di ricezione e non l'ho pubblicato sui social network. È un indirizzo che ho preso a caso dalla blockchain

Esercizio 6

Seguendo l'esercizio 5, grazie all'euristica del riutilizzo degli indirizzi, siete riusciti a identificare diverse transazioni Bitcoin in cui Loïc sembra essere coinvolto. Normalmente, tra le transazioni identificate, avreste dovuto individuare questa:

2d9575553c99578268ffba49a1b2adc3b85a29926728bd0280703a04d051eace

Questa transazione è la prima a inviare fondi all'indirizzo di Loïc. Da dove pensate che provengano i bitcoin ricevuti da Loïc tramite questa transazione?

Esercizio 7

Dopo l'esercizio 5, grazie all'euristica del riutilizzo degli indirizzi, siete riusciti a identificare diverse transazioni Bitcoin in cui Loïc sembra essere coinvolto. Ora si vuole scoprire la provenienza di Loïc. Sulla base delle transazioni trovate, eseguite un'analisi dell'orario per trovare il fuso orario più probabilmente utilizzato da Loïc. A partire da questo fuso orario, determinare la località in cui Loïc sembra vivere (paese, stato/regione, città...).

Esercizio 8

Ecco la transazione Bitcoin da studiare:

bb346dae645d09d32ed6eca1391d2ee97c57e11b4c31ae4325bcffdec40afd4f

Considerando solo questa transazione, quali informazioni possiamo interpretare?

Soluzioni per gli esercizi

Esercizio 1:

Il modello per questa transazione è il modello di pagamento semplice. Se studiamo solo la sua struttura, possiamo interpretare che un output rappresenta lo scambio e l'altro output rappresenta un pagamento effettivo. Sappiamo quindi che l'utente osservato probabilmente non è più in possesso di uno dei due UTXO in uscita (quello del pagamento), ma è ancora in possesso dell'altro UTXO (quello dello scambio).

Esercizio 2:

Il modello per questa transazione è quello della spesa raggruppata. Questo modello rivela probabilmente un'attività economica su larga scala, come una piattaforma di scambio. Possiamo dedurre che l'UTXO in ingresso proviene da un'azienda con un alto livello di attività economica e che gli UTXO in uscita saranno sparsi. Alcuni appartengono ai clienti dell'azienda che hanno ritirato i loro bitcoin in portafogli di autocustodia. Altri potranno essere destinati a società partner. Infine, ci sarà senza dubbio qualche scambio che tornerà alla società emittente.

Esercizio 3:

Il modello per questa transazione è il semplice pagamento. Possiamo quindi applicare l'euristica interna alla transazione per cercare di identificare lo scambio.

Personalmente ho individuato almeno due euristiche interne che sostengono la stessa ipotesi:

Il riutilizzo dello stesso tipo di script ;
La produzione più grande.

L'euristica più ovvia è quella di riutilizzare lo stesso tipo di script. Infatti, l'uscita 0 è un P2SH, riconoscibile per il suo indirizzo di ricezione che inizia con 3 :

3Lcdauq6eqCWwQ3UzgNb4cu9bs88sz3mKD

Mentre l'uscita 1 è un P2WPKH, identificabile dal suo indirizzo che inizia con bc1q :

bc1qya6sw6sta0mfr698n9jpd3j3nrkltdtwvelywa

Anche l'UTXO utilizzato come input per questa transazione utilizza uno script P2WPKH:

bc1qyfuytw8pcvg5vx37kkgwjspg73rpt56l5mx89k

Si può quindi ipotizzare che l'output 0 corrisponda a un pagamento e che l'output 1 sia lo scambio della transazione, il che significa che l'utente dell'input possiede sempre l'output 1.

Per sostenere o confutare questa ipotesi, possiamo cercare altre euristiche che confermino il nostro pensiero o diminuiscano la probabilità che la nostra ipotesi sia corretta.

Ho identificato almeno un'altra euristica. Si tratta dell'euristica di uscita più grande. L'uscita 0 misura 123.689 satelliti, mentre l'uscita 1 misura 505.839 satelliti. C'è quindi una differenza significativa tra questi due output. L'euristica dell'output più grande suggerisce che l'output più grande è probabilmente quello dei cambi. Questa euristica rafforza ulteriormente la nostra ipotesi iniziale.

Sembra quindi probabile che l'utente che ha fornito l'UTXO come input sia ancora in possesso dell'output `1', che sembra incarnare lo scambio della transazione.

Esercizio 4:

Il modello per questa transazione è il semplice pagamento. Possiamo quindi applicare l'euristica interna alla transazione per cercare di identificare lo scambio.

Personalmente ho individuato almeno due euristiche interne che sostengono la stessa ipotesi:

Il riutilizzo dello stesso tipo di script ;
L'uscita del palo rotondo.

L'euristica più ovvia è quella di riutilizzare lo stesso tipo di script. Infatti, l'uscita 0 è un P2SH, riconoscibile per il suo indirizzo di ricezione che inizia con 3 :

3FSH5Mnq6S5FyQoKR9Yjakk3X4KCGxeaD4

Mentre l'uscita 1 è un P2WPKH, identificabile dal suo indirizzo che inizia con bc1q :

bc1qvdywdcfsyavt4v8uxmmrdt6meu4vgeg439n7sg

Anche l'UTXO utilizzato come input per questa transazione utilizza uno script P2WPKH:

bc1qku3f2y294h3ks5eusv63dslcua2xnlzxx0k6kp

Si può quindi ipotizzare che l'output 0 corrisponda a un pagamento e che l'output 1 sia lo scambio della transazione, il che significa che l'utente dell'input possiede sempre l'output 1.

Per sostenere o confutare questa ipotesi, possiamo cercare altre euristiche che confermino il nostro pensiero o diminuiscano la probabilità che la nostra ipotesi sia corretta.

Ho identificato almeno un'altra euristica. Si tratta dell'uscita a quantità tonda. L'uscita 0 misura 70.000 sats, mentre l'uscita 1 misura 22.962 sats. Abbiamo quindi un'uscita perfettamente rotonda nell'unità di conto BTC. L'euristica dell'output rotondo suggerisce che l'UTXO con un importo rotondo è molto probabilmente quello di pagamento e che, per eliminazione, l'altro rappresenta uno scambio. Questa euristica rafforza ulteriormente la nostra ipotesi iniziale.

Tuttavia, in questo esempio, un'altra euristica potrebbe mettere in discussione la nostra ipotesi iniziale. Infatti, l'uscita 0 è maggiore dell'uscita 1. Sulla base dell'euristica secondo cui l'uscita maggiore è generalmente in valuta estera, potremmo dedurre che l'uscita 0 è in valuta estera. Tuttavia, questa contro-ipotesi non sembra plausibile, poiché le altre due euristiche appaiono sostanzialmente più convincenti dell'euristica dell'output maggiore. Di conseguenza, sembra ragionevole mantenere la nostra ipotesi iniziale nonostante questa apparente contraddizione.

Sembra quindi probabile che l'utente che ha fornito l'UTXO come input sia ancora in possesso dell'output `1', che sembra incarnare lo scambio della transazione.

Esercizio 5:

Possiamo vedere che 8 transazioni possono essere associate all'identità di Loïc. Di queste, 4 comportano la ricezione di bitcoin:

2d9575553c99578268ffba49a1b2adc3b85a29926728bd0280703a04d051eace
8b70bd322e6118b8a002dbdb731d16b59c4a729c2379af376ae230cf8cdde0dd
d5864ea93e7a8db9d3fb113651d2131567e284e868021e114a67c3f5fb616ac4
bc4dcf2200c88ac1f976b8c9018ce70f9007e949435841fc5681fd33308dd762

Gli altri 4 riguardano le spedizioni di bitcoin:

8b52fe3c2cf8bef60828399d1c776c0e9e99e7aaeeff721fff70f4b68145d540
c12499e9a865b9e920012e39b4b9867ea821e44c047d022ebb5c9113f2910ed6
a6dbebebca119af3d05c0196b76f80fdbf78f20368ebef1b7fd3476d0814517d
3aeb7ce02c35eaecccc0a97a771d92c3e65e86bedff42a8185edd12ce89d89cc

Esercizio 6:

Se osserviamo il modello di questa transazione, è chiaro che si tratta di una spesa aggregata. Infatti, la transazione ha un unico input e 51 output, il che indica un alto livello di attività economica. Possiamo quindi ipotizzare che Loïc abbia prelevato bitcoin da una piattaforma di scambio.

Diversi fattori rafforzano questa ipotesi. In primo luogo, il tipo di script utilizzato per proteggere l'ingresso UTXO è uno script P2SH 2/3 multisig, che indica un livello di sicurezza avanzato tipico delle piattaforme di scambio:

OP_PUSHNUM_2
OP_PUSHBYTES_33 03eae02975918af86577e1d8a257773118fd6ceaf43f1a543a4a04a410e9af4a59
OP_PUSHBYTES_33 03ba37b6c04aaf7099edc389e22eeb5eae643ce0ab89ac5afa4fb934f575f24b4e
OP_PUSHBYTES_33 03d95ef2dc0749859929f3ed4aa5668c7a95baa47133d3abec25896411321d2d2d
OP_PUSHNUM_3
OP_CHECKMULTISIG

Inoltre, l'indirizzo studiato 3PUv9tQMSDCEPSMsYSopA5wDW86pwRFbNF viene riutilizzato in oltre 220.000 transazioni diverse, il che è spesso caratteristico delle piattaforme di scambio, generalmente poco attente alla loro riservatezza.

L'euristica temporale applicata a questo indirizzo mostra anche una regolare trasmissione di transazioni quasi quotidiana per un periodo di 3 mesi, con orari prolungati oltre le 24 ore, suggerendo l'attività continua di una piattaforma di scambio.

Infine, i volumi gestiti da questa entità sono colossali. L'indirizzo ha ricevuto e inviato 44 BTC in 222.262 transazioni tra dicembre 2022 e marzo 2023. Questi grandi volumi confermano ulteriormente la probabile natura dell'attività di una piattaforma di scambio.

Esercizio 7:

Analizzando gli orari di conferma delle transazioni, è possibile identificare i seguenti orari UTC:

L'analisi di questi orari mostra che UTC-7 e UTC-8 sono coerenti con un intervallo di attività umana attuale (tra le 08:00 e le 23:00) per la maggior parte degli orari:

05:43 UTC > 22:43 UTC-7
20:51 UTC > 13:51 UTC-7
18:12 UTC > 11:12 UTC-7
17:16 UTC > 10:16 UTC-7
04:28 UTC > 21:28 UTC-7
23:38 UTC > 16:38 UTC-7
07:45 UTC > 00:45 UTC-7
21:55 UTC > 14:55 UTC-7
05:43 UTC > 21:43 UTC-8
20:51 UTC > 12:51 UTC-8
18:12 UTC > 10:12 UTC-8
17:16 UTC > 09:16 UTC-8
04:28 UTC > 20:28 UTC-8
23:38 UTC > 15:38 UTC-8
07:45 UTC > 23:45 UTC-8
21:55 UTC > 13:55 UTC-8

Il fuso orario UTC-7 è particolarmente rilevante in estate, in quanto comprende stati e regioni come :

California (con città come Los Angeles, San Francisco e San Diego);
Nevada (con Las Vegas) ;
Oregon (con Portland) ;
Washington (con Seattle) ;
La regione canadese della British Columbia (con città come Vancouver e Victoria).

Queste informazioni suggeriscono che Loïc risiede probabilmente sulla costa occidentale degli Stati Uniti o in Canada.

esercizio 8:***

L'analisi di questa transazione rivela 5 ingressi e un'unica uscita, il che suggerisce un consolidamento. Applicando l'euristica CIOH, possiamo ipotizzare che tutti gli UTXO di input siano di proprietà di un'unica entità e che anche l'UTXO di output appartenga a questa entità. Sembra che l'utente abbia scelto di raggruppare diversi UTXO di sua proprietà per formare un unico UTXO in uscita, con l'obiettivo di consolidare le sue parti. Questa mossa era probabilmente motivata dal desiderio di sfruttare i bassi costi di transazione dell'epoca, per ridurre i costi futuri.

Per la stesura di questa parte 3 sull'analisi di filiera, ho attinto alle seguenti risorse:

La serie di quattro articoli intitolata: Capire la privacy di Bitcoin con OXT, realizzata da Samourai Wallet nel 2021 ;*
I vari rapporti di OXT Research, così come il loro strumento gratuito di analisi della blockchain (per il momento non più disponibile in seguito all'arresto dei fondatori di Samourai Wallet) ;*
Più in generale, la mia conoscenza deriva da vari tweet e contenuti di @LaurentMT e @ErgoBTC ;*
Lo Space Kek #19 a cui ho partecipato in compagnia di @louneskmt, @TheoPantamis, @Sosthene___ e @LaurentMT.*

Vorrei ringraziare i loro autori, sviluppatori e produttori. Grazie anche ai correttori di bozze che hanno corretto meticolosamente l'articolo su cui si basa questa parte 3 e mi hanno dato i loro consigli da esperti :

Gilles Cadignan ;*
Ludovic Lars

Padroneggiare le migliori pratiche per proteggere la privacy

Riutilizzo dell'indirizzo

Dopo aver studiato le tecniche che possono rompere la vostra riservatezza su Bitcoin, in questa terza parte esamineremo le migliori pratiche da adottare per proteggervi. Lo scopo di questa parte non è quello di esplorare i metodi per migliorare la riservatezza, argomento che verrà trattato in seguito, ma piuttosto di capire come interagire correttamente con Bitcoin per mantenere la riservatezza che naturalmente offre, senza ricorrere a tecniche aggiuntive.

Ovviamente, per iniziare questa terza parte, parleremo del riutilizzo degli indirizzi. Questo fenomeno è la principale minaccia alla riservatezza degli utenti. Questo capitolo è sicuramente il più importante dell'intero corso.

Cos'è un indirizzo di ricezione?

Un indirizzo di ricezione Bitcoin è una stringa o un identificatore utilizzato per ricevere bitcoin su un portafoglio.

Tecnicamente, un indirizzo di ricezione Bitcoin non "riceve" bitcoin in senso letterale, ma serve piuttosto a definire le condizioni in cui i bitcoin possono essere spesi. In concreto, quando vi viene inviato un pagamento, la transazione del mittente crea un nuovo UTXO per voi come output dagli UTXO che ha consumato come input. Su questo output, appone uno script che definisce come questo UTXO può essere speso in un secondo momento. Questo script è noto come "ScriptPubKey" o "Locking Script". Il vostro indirizzo di ricezione, o più precisamente il suo payload, è integrato in questo script. In parole povere, questo script dice fondamentalmente:

"Per spendere questo nuovo UTXO, è necessario fornire una firma digitale utilizzando la chiave privata associata a questo indirizzo di ricezione."

Gli indirizzi Bitcoin sono di diversi tipi, a seconda del modello di scripting utilizzato. I primi modelli, noti come "Legacy*", comprendono gli indirizzi P2PKH (Pay-to-PubKey-Hash) e P2SH (Pay-to-Script-Hash). Gli indirizzi P2PKH iniziano sempre con 1, mentre P2SH con 3. Sebbene siano ancora sicuri, questi formati sono ormai obsoleti, poiché comportano costi di transazione più elevati e offrono una minore riservatezza rispetto ai nuovi standard.

Gli indirizzi SegWit V0 (P2WPKH e P2WSH) e Taproot / SegWit V1 (P2TR) rappresentano formati moderni. Gli indirizzi SegWit iniziano con bc1q e gli indirizzi Taproot, introdotti nel 2021, iniziano con bc1p.

Ad esempio, ecco l'indirizzo di ricezione di Taproot:

bc1ps5gd2ys8kllz9alpmcwxqegn7kl3elrpnnlegwkm3xpq2h8da07spxwtf5

Il modo in cui viene costruita la ScriptPubKey dipende dallo standard in uso:

| ScriptPubKey | Modello di script

| ---------------- | ----------------------------------------------------------- |

| P2PKH | OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG |

| P2SH | OP_HASH160 <scriptHash> OP_EQUAL |

| P2WPKH | 0 <pubKeyHash> |

| P2WSH | 0 <witnessScriptHash> |

| P2SH - P2WPKH | OP_HASH160 <redeemScriptHash> OP_EQUAL |

| P2SH - P2WSH | OP_HASH160 <redeemScriptHash> OP_EQUAL |

| P2TR | 1 <pubKey> |

La costruzione degli indirizzi di ricezione dipende anche dal modello di script scelto:

Per gli indirizzi P2PKH e P2WPKH, il payload, cioè il nucleo dell'indirizzo, rappresenta l'hash della chiave pubblica;
Per gli indirizzi P2SH e P2WSH, il payload rappresenta l'hash di un file ;
Come per gli indirizzi P2TR, il carico utile è una chiave pubblica modificata. Gli output P2TR combinano aspetti di Pay-to-PubKey e Pay-to-Script. La chiave pubblica modificata è il risultato dell'aggiunta di una chiave pubblica di spesa classica con un "tweak", derivato dalla radice Merkle di un insieme di script che possono essere utilizzati anche per spendere bitcoin.

Gli indirizzi visualizzati sul software di portafoglio includono anche una HRP (Human-Readable Part), tipicamente bc per gli indirizzi post-SegWit, un separatore 1 e un numero di versione q per SegWit V0 e p per Taproot/SegWit V1. Viene anche aggiunto un checksum per garantire l'integrità e la validità dell'indirizzo durante la trasmissione.

Infine, gli indirizzi vengono inseriti in un formato standard:

Base58check per vecchi indirizzi Legacy ;
Bech32 per indirizzi SegWit ;
Bech32m per gli indirizzi Taproot.

Ecco la matrice di addizione per i formati bech32 e bech32m (SegWit e Taproot) a partire da base 10:

| + | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |

| --- | --- | --- | --- | --- | --- | --- | --- | --- |

| 0 | q | p | z | r | y | 9 | x | 8 |

| 8 | g | f | 2 | t | v | d | w | 0 |

| 16 | s | 3 | j | n | 5 | 4 | k | h |

| 24 | c | e | 6 | m | u | a | 7 | l |

Che cos'è il riutilizzo degli indirizzi?

Il riutilizzo dell'indirizzo è l'uso dello stesso indirizzo di ricezione per bloccare diversi UTXO.

Come abbiamo visto nella sezione precedente, ogni UTXO ha una propria ScriptPubKey, che lo blocca e deve essere soddisfatta perché l'UTXO possa essere consumato come input in una nuova transazione. È all'interno di questa ScriptPubKey che vengono integrati gli indirizzi dei payload.

Quando diversi ScriptPubKey contengono lo stesso indirizzo di ricezione, si parla di riutilizzo dell'indirizzo. In pratica, ciò significa che un utente ha fornito ripetutamente lo stesso indirizzo ai mittenti per ricevere bitcoin tramite più pagamenti. Ed è proprio questa pratica che è disastrosa per la vostra privacy.

Perché il riutilizzo degli indirizzi è un problema?

Poiché la blockchain è pubblica, è facile vedere quali indirizzi bloccano quali UTXO e quanti bitcoin. Se lo stesso indirizzo viene utilizzato per diverse transazioni, diventa possibile dedurre che tutti i bitcoin associati a quell'indirizzo appartengono alla stessa persona. Questa pratica compromette la privacy degli utenti, consentendo di stabilire collegamenti deterministici tra le diverse transazioni e di rintracciare i bitcoin sulla blockchain. Lo stesso Satoshi Nakamoto aveva già evidenziato questo problema nel Libro Bianco di Bitcoin:

Come ulteriore firewall, si potrebbe utilizzare una nuova coppia di chiavi per ogni transazione, in modo da non collegarle a un proprietario comune

Fonte: S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf, 2009.

Con questa frase Satoshi intendeva creare un firewall aggiuntivo in caso di associazione tra l'identità di un utente e una coppia di chiavi su Bitcoin, per evitare che tutta la sua attività fosse pubblicamente collegata alla sua identità. Oggi, con la proliferazione delle società di analisi blockchain e delle normative KYC, l'uso di indirizzi univoci non è più un "firewall aggiuntivo", ma una pratica indispensabile per chiunque voglia preservare un minimo di privacy.

Quando si riutilizza un indirizzo, si crea un legame quasi innegabile tra tutte le transazioni associate a quell'indirizzo. Sebbene questo non metta direttamente a rischio i vostri fondi, poiché la crittografia a curva ellittica garantisce la sicurezza delle vostre chiavi private, rende più facile il monitoraggio delle vostre attività. Infatti, chiunque abbia un nodo può osservare le transazioni e i saldi degli indirizzi, compromettendo totalmente il vostro anonimato.

Per illustrare questo punto, prendiamo l'esempio di Bob, un utente che acquista regolarmente bitcoin in piccole quantità in DCA e li invia sempre allo stesso indirizzo. Dopo due anni, questo indirizzo contiene una notevole quantità di bitcoin. Se Bob utilizza questo indirizzo per effettuare un pagamento a un commerciante locale, quest'ultimo sarà in grado di vedere tutti i fondi associati e dedurre la ricchezza di Bob. Ciò può comportare rischi per la sicurezza personale, come tentativi di furto o estorsione. Se Bob avesse utilizzato un indirizzo vuoto per ricevere ogni acquisto periodico, avrebbe rivelato al commerciante un numero infinitamente inferiore di informazioni.

Nell'analisi delle stringhe, esistono due tipi di riutilizzo degli indirizzi:

Riutilizzo esterno ;
Riutilizzo interno a una transazione.

Il primo è quando un indirizzo viene riutilizzato in diverse transazioni Bitcoin. Questo è ciò di cui abbiamo parlato in precedenza: questa euristica deduce che tutti gli UTXO passati attraverso questo indirizzo appartengono a un'unica entità.

Il riutilizzo degli indirizzi interni non si verifica quando il riutilizzo avviene tra più transazioni, ma quando avviene all'interno di una singola transazione. Infatti, se lo stesso indirizzo utilizzato per bloccare un ingresso viene utilizzato come uscita di una transazione, si può dedurre che questa uscita appartiene ancora allo stesso utente (scambio) e che la seconda uscita rappresenta il pagamento effettivo. Quest'altra euristica permette di perpetuare una traccia dei fondi su più transazioni.

Il riutilizzo degli indirizzi è un vero flagello per Bitcoin. Secondo il sito web OXT.me (attualmente inaccessibile), il tasso complessivo di riutilizzo degli indirizzi su Bitcoin era di circa il 52% nel 2022:

Questo tasso è enorme, ma proviene in larga misura dalle piattaforme di scambio piuttosto che dai singoli utenti.

Come evitare il riutilizzo degli indirizzi?

Evitare il riutilizzo degli indirizzi è molto semplice: Usate un nuovo indirizzo vuoto per tutti i nuovi pagamenti al vostro portafoglio.

Grazie al BIP32, i portafogli moderni sono ora deterministici e gerarchici. Ciò significa che un utente può generare un gran numero di indirizzi a partire da un'unica informazione iniziale: il seme. Salvando questa singola informazione, è possibile ripristinare tutte le chiavi private del portafoglio, consentendo l'accesso ai fondi garantiti dagli indirizzi corrispondenti.

Per questo motivo, quando si preme il pulsante "ricevi" nel software del portafoglio, viene suggerito ogni volta un indirizzo di ricezione non utilizzato. Dopo aver ricevuto bitcoin a questo indirizzo, il software ne suggerisce automaticamente un altro.

PS: Recentemente, alcuni software di portafoglio hanno annunciato la loro intenzione di smettere di generare indirizzi vuoti, temendo che ciò venga percepito come una forma di riciclaggio di denaro da parte delle autorità. Se il vostro software è uno di questi, vi consiglio vivamente di sostituirlo immediatamente, poiché questo non è accettabile per l'utente. Se avete bisogno di un identificatore statico per ricevere pagamenti, come le donazioni, non è consigliabile utilizzare un indirizzo Bitcoin classico a causa del rischio di riutilizzo. Utilizzate invece un indirizzo Lightning o optate per un identificatore di pagamento statico onchain, come BIP47 o Silent Payments. Questi protocolli sono spiegati in dettaglio nella Parte 6 di questo corso di formazione.

Etichettatura e controllo dei pezzi

Come abbiamo scoperto nella sezione sull'analisi delle stringhe, esiste una moltitudine di euristiche e schemi che possono essere utilizzati per dedurre informazioni su una transazione. Come utente, è importante conoscere queste tecniche per proteggersi meglio da esse.

Ciò comporta una gestione rigorosa del portafoglio in autocustodia, il che significa conoscere l'origine dei propri UTXO e selezionare attentamente quali UTXO consumare quando si effettuano i pagamenti. Questa gestione efficiente del portafoglio si basa su due caratteristiche importanti dei buoni portafogli Bitcoin: il tagging e il controllo delle monete.

In questo capitolo esamineremo queste funzioni e vedremo come utilizzarle in modo intelligente, senza appesantire il carico di lavoro, per ottimizzare notevolmente la vostra privacy su Bitcoin.

Che cos'è l'etichettatura?

L'etichettatura è la pratica di assegnare un'annotazione o un'etichetta a un UTXO specifico in un portafoglio Bitcoin. Queste annotazioni sono memorizzate localmente dal software del portafoglio e non vengono mai trasmesse sulla rete Bitcoin. L'etichettatura è quindi uno strumento di gestione personale.

Ad esempio, se ho un UTXO proveniente da un acquisto P2P su Bisq con Charles, potrei etichettarlo come "Bisq Charles non KYC".

L'etichettatura è una buona pratica che aiuta a ricordare l'origine o la destinazione di un UTXO, facilitando così la gestione dei fondi e l'ottimizzazione della privacy. In effetti, il vostro portafoglio Bitcoin contiene sicuramente diversi UTXO. Se le fonti di questi UTXO sono diverse, è meglio non unire questi UTXO in futuro, altrimenti si potrebbe rivelare la loro proprietà comune. Etichettando correttamente tutti i vostri pezzi, potrete essere sicuri di ricordarvi da dove provengono quando dovrete usarli, anche se tra anni.

Cos'è il controllo degli angoli?

L'uso attivo dell'etichettatura diventa ancora più interessante se abbinato a un'opzione di controllo delle monete nel software di portafoglio.

Il controllo delle monete è una funzione presente in un buon software per portafogli Bitcoin, che consente di selezionare manualmente UTXO specifici da utilizzare come input per completare una transazione. Infatti, per soddisfare un pagamento in uscita, è necessario consumare un UTXO in entrata. Per una serie di ragioni, che vedremo più avanti, si può scegliere con precisione quali parti consumare come input per soddisfare un determinato pagamento. Questo è esattamente ciò che il controllo delle monete consente di fare. Per fare un'analogia, questa funzione è simile alla scelta di una moneta specifica dal portafoglio quando si paga la baguette.

L'uso di un software di portafoglio con controllo delle monete, abbinato all'etichettatura UTXO, consente agli utenti di distinguere e selezionare con precisione gli UTXO per le loro transazioni.

Come si etichettano gli UTXO?

Non esiste un metodo unico per etichettare gli UTXO. Sta a voi definire un sistema di etichettatura facile da capire per il vostro portafoglio. In ogni caso, tenete presente che una buona etichettatura è quella che potete capire quando ne avete bisogno. Se il vostro portafoglio Bitcoin è destinato principalmente al risparmio, le etichette potrebbero non esservi utili per decenni. Assicuratevi quindi che siano chiare, precise e complete.

È importante che i vostri cari possano identificare facilmente l'origine dei fondi se, un giorno, dovessero avere accesso al vostro portafoglio. Questo li aiuterà sia per motivi di riservatezza sia per scopi legali, nel caso in cui debbano giustificare l'origine dei fondi a un'autorità.

La cosa più importante da annotare sull'etichetta è la provenienza dell'UTXO. Dovreste semplicemente indicare come la moneta è arrivata nel vostro portafoglio. È il risultato di un acquisto su una piattaforma di scambio? Un pagamento di una fattura da parte di un cliente? Uno scambio peer-to-peer? Oppure rappresenta lo scambio di una spesa? Ad esempio, si può specificare:

rimuovere Exchange.com` ;
pagamento del cliente David` ;
acquistare P2P Charles`;
cambiare l'acquisto del divano

Per perfezionare la gestione degli UTXO e rispettare le strategie di segregazione dei fondi all'interno del portafoglio, potete arricchire le vostre etichette con un indicatore aggiuntivo che rifletta queste separazioni. Se il vostro portafoglio contiene due categorie di UTXO che volete evitare di mescolare, potete incorporare un indicatore nelle vostre etichette per distinguere chiaramente questi gruppi. Questi indicatori di separazione dipenderanno dai vostri criteri, come ad esempio la distinzione tra UTXO derivanti da un processo di acquisizione che comporta il KYC, o tra fondi professionali e personali. Riprendendo gli esempi di etichetta citati in precedenza, questo potrebbe tradursi in:

KYC - Withdrawal Exchange.com ;
kYC - Pagamento del cliente David" ;
NO KYC - Acquistare P2P Charles ;
NO KYC - Cambio divano d'acquisto

È inoltre consigliabile perpetuare l'etichettatura di una parte nel corso delle transazioni. Ad esempio, quando si consolida un UTXO no-KYC, assicurarsi di contrassegnare l'UTXO risultante non solo come "consolidamento", ma specificamente come "consolidamento no-KYC" per mantenere una chiara traccia della provenienza delle monete.

Infine, non è obbligatorio inserire una data su un'etichetta. La maggior parte dei software dei portafogli visualizza già la data della transazione ed è sempre possibile trovare questa informazione su un block explorer grazie al TXID.

Come scegliere le parti giuste?

Quando si esegue una transazione, il controllo delle monete consente di scegliere specificamente quali UTXO consumare come input per soddisfare l'output del pagamento. Questa scelta ha due aspetti:

La possibilità per il destinatario del pagamento di collegare parte della vostra identità agli UTXO utilizzati negli input;
La capacità di un osservatore esterno di stabilire collegamenti tra tutti gli UTXO consumati come input.

Per illustrare il primo punto, facciamo un esempio concreto. Supponiamo di acquistare una baguette in bitcoin dal nostro panettiere. Utilizzate uno o più UTXO in vostro possesso come input per pagare almeno il prezzo della baguette in output, oltre alle spese di transazione. Il panettiere potrebbe quindi associare il vostro volto, o qualsiasi altra parte della vostra identità che conosce, alle monete utilizzate come input. Sapendo dell'esistenza di questo legame, al momento del pagamento si potrebbe preferire scegliere un UTXO specifico piuttosto che un altro.

Ad esempio, se uno dei vostri UTXO proviene da una piattaforma di scambio e preferite che il panettiere non sappia del vostro conto su quella piattaforma, eviterete di usare quell'UTXO per il pagamento. Se avete un UTXO di alto valore che rivela una quantità significativa di bitcoin, potreste anche scegliere di non usarlo per evitare che il panettiere venga a conoscenza della vostra fortuna in BTC.

La scelta di quali UTXO utilizzare per questo primo punto è quindi una decisione personale, influenzata da ciò che si è disposti a rivelare o meno. Le etichette che assegnate ai vostri UTXO quando li ricevete vi aiuteranno a selezionare quelli che, una volta spesi, espongono solo le informazioni che vi sentite di rivelare al destinatario.

Oltre alle informazioni potenzialmente rivelate al destinatario, la scelta degli input influenza anche ciò che si rivela a tutti gli osservatori della blockchain. Infatti, utilizzando diversi UTXO come input della transazione, si rivela che sono di proprietà della stessa entità, secondo l'euristica CIOH (Common Input Ownership Heuristic).

Quando si selezionano i pezzi, quindi, bisogna essere consapevoli che la transazione che si sta per trasmettere creerà un collegamento tra tutti gli UTXO utilizzati. Questo collegamento può essere problematico per la privacy, soprattutto se gli UTXO provengono da fonti diverse.

Prendiamo l'esempio del mio UTXO no-KYC di Bisq; voglio evitare di combinarlo con un UTXO di una piattaforma di scambio regolamentata che conosce la mia identità. Infatti, se mai utilizzassi questi due UTXO come input per la stessa transazione, la piattaforma regolamentata sarebbe in grado di collegare la mia identità con l'UTXO che ho acquistato su Bisq, che non era precedentemente collegato alla mia identità.

Infine, quando si sceglie quali UTXO utilizzare come input di una transazione, la cosa più importante è evitare di utilizzare più UTXO. Al massimo, quando è possibile, selezionare una singola moneta abbastanza grande da soddisfare il pagamento. In questo modo, si evitano completamente i rischi associati al CIOH. Tuttavia, se un singolo UTXO non è sufficiente per il pagamento e dovete consumarne diversi, assicuratevi che provengano da fonti simili per ridurre al minimo il rischio di collegamenti indesiderati. Tenete inoltre presente che il destinatario potrebbe associare le informazioni in suo possesso su di voi con la storia delle monete utilizzate per gli ingressi.

Capire la selezione automatica dei pezzi

Nelle sezioni precedenti abbiamo parlato della selezione manuale degli UTXO da utilizzare per una transazione. Ma cosa succede quando il software del portafoglio esegue questa selezione automaticamente? Esistono diversi metodi per determinare quali monete consumare e la selezione degli UTXO costituisce un vero e proprio campo di ricerca su Bitcoin. Lo scopo principale di questo processo automatico è spesso quello di ridurre al minimo i costi di transazione per l'utente.

I metodi di selezione UTXO come FIFO (First In First Out) e LIFO (Last In First Out) sono tra i più semplici, ma anche i meno efficienti. Con il metodo FIFO, i titoli più vecchi del portafoglio vengono utilizzati per primi. Questo approccio è generalmente inefficiente sia per ridurre al minimo i costi di transazione sia per preservare la riservatezza, tranne nei casi in cui si utilizzano timelock relativi che devono essere rinnovati regolarmente. Al contrario, il LIFO dà priorità all'uso degli UTXO più recenti. Entrambi i metodi, per quanto semplici, si rivelano spesso inefficaci.

Un metodo più avanzato è il Knapsack Solver. Questo metodo è stato utilizzato nel portafoglio Bitcoin Core fino alla versione 0.17. Consiste nel selezionare iterativamente e casualmente gli UTXO dal portafoglio, sommarli in sottoinsiemi e mantenere la soluzione che riduce il più possibile il peso della transazione, al fine di ridurre il costo per l'utente.

Il Branch-and-Bound (BNB), spesso soprannominato "algoritmo di Murch" dal nome del suo inventore, ha sostituito il Knapsack Solver in Bitcoin Core a partire dalla versione 0.17. Questo metodo più avanzato mira a trovare un insieme di UTXO che corrisponda esattamente all'importo necessario per soddisfare gli output di una transazione. L'obiettivo di BNB è quello di minimizzare l'importo dello scambio e le commissioni, riducendo il cosiddetto criterio di spreco, che tiene conto sia dei costi immediati che dei costi futuri attesi dello scambio. Questo metodo deriva dal concetto originale di Branch-and-Bound, ideato nel 1960 da Ailsa Land e Alison Harcourt, e offre un'ottimizzazione più precisa delle commissioni rispetto al Knapsack Solver.

Tutti questi metodi di selezione automatica degli UTXO possono essere efficaci nel ridurre i costi di transazione, ma sono spesso inefficaci nel preservare la riservatezza dell'utente. Infatti, questi algoritmi possono unire diversi UTXO in input, rivelando così una proprietà comune di questi UTXO dovuta al CIOH. Ovviamente, questi metodi non possono tenere conto delle etichette apposte agli UTXO, che sono comunque fondamentali per scegliere consapevolmente quali parti rivelare al destinatario della transazione. Attualmente, l'unico modo per ottimizzare la riservatezza nella selezione delle monete è quello di farlo manualmente.

Esercitazione sull'etichettatura UTXO

Se volete scoprire come etichettare i vostri UTXO, abbiamo preparato un tutorial completo sui principali software per portafogli Bitcoin in circolazione:

https://planb.network/tutorials/privacy/on-chain/utxo-labelling-d997f80f-8a96-45b5-8a4e-a3e1b7788c52

KYC e identificazione delle chiavi

KYC sta per "Know Your Customer" (conosci il tuo cliente). Si tratta di una procedura normativa attuata da alcune società che operano nel settore dei Bitcoin. Lo scopo di questa procedura è quello di verificare e registrare l'identità dei propri clienti, con l'obiettivo dichiarato di combattere il riciclaggio di denaro e il finanziamento del terrorismo.

In termini pratici, il KYC comporta la raccolta di vari dati personali del cliente, che possono variare a seconda della giurisdizione, ma che in genere includono un documento d'identità, una fotografia e una prova di indirizzo. Queste informazioni vengono poi verificate e conservate per usi futuri.

Questa procedura è diventata obbligatoria per tutte le piattaforme di scambio regolamentate nella maggior parte dei Paesi occidentali. Ciò significa che chiunque desideri scambiare valute statali con bitcoin attraverso queste piattaforme deve rispettare i requisiti KYC.

Questa procedura non è priva di rischi per la privacy e la sicurezza degli utenti. In questo capitolo esamineremo questi rischi in dettaglio e analizzeremo gli impatti specifici dei processi di KYC e di identificazione sulla privacy degli utenti di Bitcoin.

Facilitare la tracciabilità onchain

Il primo rischio associato al KYC è che offre un punto di ingresso privilegiato per l'analisi della blockchain. Come abbiamo visto nella sezione precedente, gli analisti possono raggruppare e tracciare l'attività sulla blockchain utilizzando modelli di transazioni ed euristiche. Una volta che sono riusciti a raggruppare l'attività onchain di un utente, tutto ciò che devono fare è trovare un singolo punto di ingresso tra tutte le sue transazioni e chiavi per compromettere completamente la sua riservatezza.

Quando si esegue un KYC, si fornisce un punto di ingresso di alta qualità per l'analisi della blockchain, in quanto si associano gli indirizzi di ricezione utilizzati quando si prelevano i bitcoin da una piattaforma di scambio con la propria identità completa e verificata. In teoria, queste informazioni sono note solo all'azienda a cui le avete fornite, ma, come vedremo più avanti, il rischio di fuga di dati è reale. Inoltre, il solo fatto che una società detenga queste informazioni può essere problematico, anche se non le condivide.

Quindi, se non prendete altre misure per limitare l'aggregazione delle vostre attività sulla blockchain, chiunque sia a conoscenza di questo punto di ingresso KYC può potenzialmente collegare tutte le vostre attività su Bitcoin alla vostra identità. Dal punto di vista dell'azienda, il vostro utilizzo di Bitcoin perde ogni riservatezza.

Per illustrare questo concetto con un paragone, è come se il vostro banchiere della Banca X non solo avesse accesso a tutte le vostre transazioni con la Banca X, ma potesse anche osservare le vostre transazioni con la Banca Y e tutte le vostre transazioni in contanti.

Ricordiamo la prima parte di questo corso di formazione: Il modello di riservatezza di Bitcoin, così come concepito da Satoshi Nakamoto, si basa sulla separazione tra l'identità dell'utente e le sue coppie di chiavi. Anche se oggi questo livello di riservatezza non è più sufficiente, è comunque prudente limitarne il più possibile il degrado.

Esposizione alla sorveglianza dello Stato

Il secondo problema principale del KYC è che rivela allo Stato che avete posseduto bitcoin in un certo momento. Quando si acquistano bitcoin tramite un attore regolamentato, lo Stato può venire a conoscenza di questo possesso. Al momento questo può sembrare banale, ma è importante ricordare che il futuro politico ed economico del vostro Paese non è nelle vostre mani.

In primo luogo, lo Stato può adottare rapidamente una posizione autoritaria. La storia è piena di esempi in cui le politiche sono cambiate repentinamente. Oggi, in Europa, i Bitcoiners possono scrivere articoli su Bitcoin, partecipare a conferenze e gestire i loro portafogli in autocustodia. Ma chi può dire cosa ci riserverà il domani? Se il Bitcoin diventa improvvisamente il nemico pubblico numero uno, essere associati ad esso negli archivi governativi potrebbe rivelarsi problematico.

Poi, di fronte a gravi crisi economiche, lo Stato potrebbe prendere in considerazione il sequestro dei bitcoin detenuti dai cittadini. Forse un domani i bitcoiners saranno percepiti come profittatori della crisi e saranno tassati eccessivamente per le loro plusvalenze di fronte alla svalutazione della moneta fiat.

Si potrebbe pensare che questo non sia un problema, dato che i bitcoin sono misti e quindi non rintracciabili. Tuttavia, il problema non è la tracciabilità. Il vero problema è che lo Stato sa che possedete bitcoin. Questa informazione, da sola, potrebbe essere sufficiente per incriminarvi o chiedervi di rendere conto del vostro operato. Potreste provare a dichiarare di aver speso i vostri bitcoin, ma questo dovrebbe essere riportato nella vostra dichiarazione dei redditi e verreste scoperti. Potreste anche dire di aver perso le chiavi in un incidente in barca, ma al di là della battuta su Twitter, pensate davvero che sarebbe sufficiente a scagionarvi?

È quindi importante prendere in considerazione il rischio che lo Stato sappia che avete posseduto BTC, per quanto questo rischio possa sembrare oggi remoto.

Un altro problema posto dal KYC in termini di vigilanza statale è l'obbligo di segnalazione da parte delle piattaforme regolamentate. Sebbene non conosca le normative di altre giurisdizioni, in Francia i Prestataires de Services sur Actifs Numériques (PSAN) sono obbligati a segnalare alle autorità di vigilanza finanziaria qualsiasi movimento di fondi che considerano sospetto.

In Francia, nel 2023, sono stati segnalati dai PSAN 1.449 atti sospetti. Per il momento, la maggior parte di questi atti sono legati alla criminalità. Tuttavia, le autorità chiedono anche alle piattaforme regolamentate di segnalare eventuali transazioni sospette di Bitcoin solo sulla base della loro struttura. Se si effettua una transazione collaborativa, o anche solo una transazione con uno schema un po' atipico, e questa transazione si verifica non lontano dal prelievo dei propri Bitcoin da queste piattaforme, ci si potrebbe trovare segnalati alle autorità. Anche in assenza di illeciti e nel legittimo esercizio dei vostri diritti, tale segnalazione potrebbe portare a un aumento dei controlli e della sorveglianza, inconvenienti che avreste evitato senza KYC.

Il rischio di fuga di dati personali

Un altro problema del KYC è che richiede che tutti i vostri dati personali siano memorizzati sui server di una società privata.

Gli eventi recenti ci hanno ricordato che nessuno è immune da fallimenti finanziari o informatici. Nel 2022, i clienti di Celsius ne hanno subito le conseguenze. In seguito al fallimento dell'azienda, i tribunali americani hanno reso pubblici i nomi dei creditori e l'ammontare dei loro beni durante il procedimento amministrativo.

Poco più di due anni fa, un fiore all'occhiello della sicurezza informatica delle criptovalute si è visto rubare i dati personali dei propri clienti. Sebbene l'incidente non fosse direttamente collegato all'acquisto di bitcoin, tale rischio permane anche per le piattaforme di scambio. Esiste quindi un rischio preciso associato ai dati personali.

È vero che affidiamo già molti dei nostri dati personali a società private. Tuttavia, il rischio in questo caso è duplice, poiché questi dati non solo vi identificano, ma sono anche collegati all'attività su Bitcoin. Infatti, quando un hacker accede ai dati dei clienti di una piattaforma di scambio, può ragionevolmente presumere che questi clienti possiedano Bitcoin. Questo rischio è accentuato dal fatto che il Bitcoin, come qualsiasi altro bene di valore, attira l'attenzione dei ladri.

Nel caso di una fuga di dati, nella migliore delle ipotesi potreste essere oggetto di tentativi di phishing mirati. Nel peggiore dei casi, potreste trovarvi al centro di minacce fisiche alla vostra casa.

Oltre ai rischi specifici legati ai Bitcoin, vi sono anche i pericoli legati alla trasmissione di documenti d'identità. Infatti, in caso di fuga di dati, è possibile diventare vittima di un furto di identità. La posta in gioco non si limita quindi alla protezione della riservatezza delle transazioni, ma riguarda anche la sicurezza personale di ogni individuo.

Alcune idee preconcette sul KYC

È importante decostruire alcune idee preconcette sul KYC che spesso incontriamo su Twitter o nei nostri scambi tra bitcoiners.

Innanzitutto, non è corretto pensare che proteggere la propria privacy per i Bitcoin acquisiti tramite KYC sia inutile. Gli strumenti e i metodi di protezione della privacy su Bitcoin sono vari e servono a scopi diversi. Utilizzare le transazioni coinjoin sui Bitcoin acquisiti tramite KYC, ad esempio, non è una cattiva idea. Naturalmente bisogna fare attenzione alle piattaforme di scambio regolamentate per evitare che il proprio conto venga congelato o bannato, ma da un punto di vista strettamente tecnico queste pratiche non sono incompatibili. Coinjoin ha l'effetto di interrompere la storia di una moneta, aiutandovi così a sventare alcuni rischi di analisi della catena associati al KYC. Anche se non elimina tutti i rischi, rappresenta un vantaggio significativo.

La riservatezza su Bitcoin non deve essere vista in modo binario, come una distinzione tra bitcoin "anonimi" e altri che non lo sono. Possedere Bitcoin acquisiti tramite KYC non significa che tutto sia perduto; al contrario, l'uso di strumenti di riservatezza può rivelarsi ancora più vantaggioso.

Al contrario, l'acquisizione di bitcoin tramite un metodo non KYC non garantisce una perfetta riservatezza, né esime dalla necessità di adottare altre misure di protezione. Se si detengono bitcoin non KYC ma si riutilizzano più volte gli indirizzi di ricezione, le transazioni possono essere tracciate e aggregate. Il minimo collegamento con il mondo esterno a Bitcoin potrebbe compromettere l'unico livello di riservatezza di cui disponete. È quindi importante considerare tutti gli strumenti e i metodi di miglioramento della privacy su Bitcoin come complementari. Ogni tecnica affronta un rischio specifico e può aggiungere un ulteriore livello di protezione. Quindi, possedere Bitcoin non KYC non significa che non si debbano prendere altre precauzioni.

Il KYC può essere annullato?

A volte mi viene chiesto se è possibile "tornare indietro" dopo aver eseguito un KYC e, come potete immaginare dai paragrafi precedenti, la risposta è sfumata. Il modo più semplice per evitare i rischi associati al KYC è quello di non utilizzarlo per l'acquisizione di bitcoin. Analizzeremo questo argomento in modo più approfondito nel prossimo capitolo. Tuttavia, se il KYC è già stato effettuato e i bitcoin sono stati acquistati, ci sono modi per mitigare i rischi connessi?

Per quanto riguarda il rischio di rintracciare le transazioni, l'uso di coinjoin è una soluzione. Analizzeremo questo metodo in dettaglio più avanti nel corso, ma è bene sapere che coinjoin consente di interrompere la storia di una moneta e di impedirne la tracciabilità passato-presente e presente-passato. Anche per i BTC ottenuti tramite una piattaforma regolamentata, questa tecnica può impedirne la tracciabilità.

Tuttavia, coinjoin non cancella il secondo rischio associato al KYC: il fatto che lo Stato possa essere informato del vostro possesso di bitcoin. Infatti, anche se le vostre monete non sono più rintracciabili, lo Stato, a seconda della giurisdizione, può avere accesso alle vostre dichiarazioni di trasferimento di cripto-asset. Poiché questo rischio non è tecnico, ma amministrativo, non esistono soluzioni specifiche per Bitcoin per eliminarlo, a parte non esporsi al KYC in primo luogo. L'unico approccio legale per mitigare questo rischio è quello di vendere su piattaforme regolamentate i Bitcoin acquistati tramite piattaforme regolamentate, per poi riacquistarli con mezzi esenti da KYC. Vendendo e dichiarando il trasferimento, le autorità dovrebbero constatare che non li possedete più.

Per quanto riguarda il rischio di fuga dei dati personali e dei documenti d'identità, si tratta di un pericolo esterno a Bitcoin e non esiste una soluzione tecnica per evitarlo. Una volta che i vostri dati sono stati rivelati, è difficile annullare l'operazione. Si può provare a chiudere il conto sulla piattaforma, ma questo non garantisce la cancellazione dei dati KYC, soprattutto quando la verifica dell'identità è affidata all'esterno. La verifica della completa cancellazione delle informazioni è impossibile. Non esiste quindi una soluzione per prevenire completamente questo rischio e garantire che non esista più.

La differenza tra KYC e identificazione delle chiavi

A volte, alcuni bitcoiners tendono a estendere il termine "KYC" a qualsiasi scambio di BTC che preveda un bonifico bancario o un pagamento con carta di credito, poiché anche questi mezzi possono rivelare l'origine del pagamento, proprio come farebbe un KYC. Tuttavia, il KYC non deve essere confuso con l'identificazione delle chiavi. A titolo personale, devo ammettere che la mia percezione di questo argomento si è evoluta nel tempo.

Il termine KYC si riferisce in particolare a una procedura normativa attuata da alcune società per verificare e registrare l'identità dei propri clienti. È una cosa binaria: quando si acquisiscono i bitcoin, o si fa il KYC o non lo si fa. Tuttavia, l'identificazione delle chiavi, che riguarda il legame tra un aspetto dell'identità di un utente e l'attività onchain, non è così binaria, ma rappresenta piuttosto un continuum. In effetti, nel contesto dell'acquisizione o del trasferimento di bitcoin, tale identificazione è sempre possibile in varia misura.

Ad esempio, se si acquistano bitcoin su una piattaforma regolamentata in Svizzera, il KYC non è richiesto. Tuttavia, le vostre chiavi potrebbero essere identificate, poiché l'acquisto è stato effettuato tramite il vostro conto bancario. È qui che i primi due rischi associati al KYC - facilitazione del tracciamento onchain ed esposizione alla sorveglianza statale - possono manifestarsi anche in uno scambio senza KYC. Se l'entità svizzera segnala transazioni sospette alle autorità del vostro Paese, queste possono semplicemente controllare il conto bancario utilizzato per l'acquisto per scoprire la vostra identità. Pertanto, l'acquisto senza KYC su piattaforme regolamentate è piuttosto elevato nella scala dei rischi per l'identificazione delle chiavi.

Tuttavia, evitare le piattaforme regolamentate e optare per i metodi di acquisto P2P non elimina totalmente il rischio di identificazione delle chiavi, ma si limita a ridurlo. Prendiamo l'esempio di un acquisto su Bisq o su un'altra piattaforma P2P. Per pagare la vostra controparte, probabilmente userete il vostro conto bancario. Se le autorità interrogano la persona con cui avete scambiato e chiedono il vostro nome, siamo di nuovo ai rischi 1 e 2. Sebbene questi rischi siano molto più bassi rispetto all'acquisto su una piattaforma senza KYC, e ancora più bassi rispetto all'acquisto con KYC, sono comunque presenti in misura minore.

Infine, anche se acquistate i vostri bitcoin attraverso uno scambio fisico in contanti, non siete totalmente anonimi. La persona con cui avete effettuato lo scambio ha visto il vostro volto, che fa parte della vostra identità. Anche se minima in questo esempio, esiste comunque la possibilità di un'identificazione chiave.

In conclusione, quando i bitcoin vengono scambiati con altri beni, che si tratti di un acquisto in valuta statale o di una vendita a fronte di un bene reale, c'è sempre una forma di identificazione della chiave. A seconda del metodo di scambio scelto, questa identificazione può variare di intensità. È importante non confondere questa identificazione con il KYC, che è un processo normativo ben definito. Tuttavia, esiste un legame tra il KYC e lo spettro dell'identificazione, poiché il KYC si colloca all'estremità superiore dello spettro, in quanto facilita sistematicamente l'identificazione delle chiavi utente da parte delle autorità.

Metodi di vendita e di acquisizione

Dopo aver letto il capitolo precedente, vi starete chiedendo come potete acquistare o vendere bitcoin senza dovervi sottoporre a una procedura di verifica dell'identità, per evitare i rischi associati al KYC. Esistono diversi modi per negoziare bitcoin.

Scambi di denaro P2P

Come abbiamo visto, il metodo migliore in termini di riservatezza rimane lo scambio P2P (da persona a persona) con regolamento in contanti. Questo metodo consente di ridurre al minimo le tracce lasciate e riduce notevolmente la possibilità di identificazione delle chiavi, sia che si tratti di acquisto che di vendita.

Tuttavia, esistono dei rischi per la sicurezza personale. Il pericolo principale risiede nel fatto che, durante lo scambio, la controparte saprà che avete in mano una grossa somma di denaro, sia in contanti che in bitcoin. Questa informazione può attirare l'attenzione di persone malintenzionate. In effetti, è generalmente consigliabile essere discreti riguardo alle proprie disponibilità di bitcoin. Questo consiglio può essere applicato anche ai contanti. Tuttavia, quando si effettua uno scambio di persona, è inevitabile rivelare di possedere dei bitcoin e questo può attirare attenzioni indesiderate.

Per limitare questo rischio, vi consiglio di privilegiare le transazioni in contanti con persone fidate, come membri della famiglia o amici intimi. In alternativa, potreste anche prendere in considerazione la possibilità di fare trading ai local Bitcoin meetup, dopo avervi partecipato alcune volte. Questo vi permetterà di conoscere meglio gli altri partecipanti e di non essere soli durante lo scambio fisico. Tuttavia, è importante riconoscere che gli scambi di denaro P2P comportano intrinsecamente dei rischi per la vostra sicurezza personale che non esistono quando si acquista tramite una piattaforma regolamentata e il vostro conto bancario.

Inoltre, a seconda del luogo in cui si vive, trasportare e conservare grandi somme di denaro può essere rischioso, sia che si tratti di bitcoin che di contanti.

Lo scambio di contanti può anche comportare rischi legali in caso di controlli da parte della polizia o di altri enti. Sebbene nella maggior parte dei Paesi non vi siano restrizioni sulla quantità di contanti che si possono portare con sé, importi eccessivi possono destare sospetti. Fate quindi attenzione, soprattutto se dovete percorrere lunghe distanze, ed evitate di effettuare troppe transazioni importanti in una volta sola, per non dover giustificare il possesso di somme ingenti.

Infine, un altro svantaggio degli acquisti P2P è che il prezzo è spesso più alto rispetto alle piattaforme regolamentate. I venditori spesso applicano un ricarico che va dall'1% a volte più del 10%. Le ragioni di questa differenza di prezzo sono molteplici. In primo luogo, si tratta di una pratica comune tra i venditori P2P che si è consolidata nel tempo. In secondo luogo, i venditori devono pagare le commissioni associate alla transazione per inviare i fondi all'acquirente. Nelle vendite P2P c'è anche un maggior rischio di furto rispetto alle transazioni su piattaforma, il che giustifica una compensazione per il rischio corso. Infine, il costo aggiuntivo può essere legato alla domanda e alla qualità dello scambio in termini di riservatezza. Come acquirente, il guadagno in termini di riservatezza ha un prezzo che si riflette nel ricarico applicato dal venditore. Alcuni bitcoiners ritengono inoltre che il prezzo di ricarico del BTC acquistato su P2P rifletta il suo prezzo reale e sostengono che i prezzi più bassi sulle piattaforme regolamentate siano il risultato di un compromesso sulla riservatezza dei dati personali.

Scambi P2P attraverso una piattaforma di matchmaking

Un'alternativa meno rischiosa in termini di sicurezza personale è quella di effettuare gli scambi P2P esclusivamente online, tramite metodi di pagamento elettronici come PayPal, bonifici bancari o Revolut.

Questo approccio evita molti dei rischi associati alle transazioni in contanti. Tuttavia, il rischio di inadempienza della controparte in uno scambio online è maggiore. Infatti, in uno scambio fisico, se consegnate del denaro al venditore che non vi invia i bitcoin in cambio, potete immediatamente chiamarlo a rispondere, dato che si trova di fronte a voi. Online, invece, è spesso impossibile rintracciare chi vi ha derubato.

Per mitigare questo rischio, è possibile utilizzare piattaforme specializzate per gli scambi P2P. Queste piattaforme utilizzano meccanismi di risoluzione dei conflitti per proteggere gli utenti danneggiati. In genere, offrono un sistema di deposito a garanzia, in cui i bitcoin vengono trattenuti fino alla conferma del pagamento in valuta fiat da parte del venditore.

In termini di sicurezza personale, questo metodo di acquisto è notevolmente più sicuro di uno scambio fisico di contanti. Tuttavia, come già detto, gli scambi P2P online lasciano più tracce rispetto a uno scambio fisico, il che può essere dannoso per la privacy su Bitcoin. Utilizzando un metodo di pagamento fiat online, come una banca, si espongono più informazioni che potrebbero facilitare l'identificazione delle chiavi.

Ancora una volta, non consiglierei di effettuare troppe operazioni di grandi dimensioni in un'unica transazione su queste piattaforme. Suddividendo le transazioni, si distribuisce il rischio di furto della controparte.

Ancora una volta, un altro svantaggio degli acquisti P2P è che il prezzo è spesso più alto di quello osservato sulle piattaforme regolamentate. I venditori spesso applicano un ricarico che va dall'1% a volte più del 10%. Le ragioni di questa differenza di prezzo sono molteplici. In primo luogo, si tratta di una pratica comune tra i venditori P2P che si è consolidata nel tempo. In secondo luogo, i venditori devono pagare le commissioni associate alla transazione per inviare i fondi all'acquirente. Nelle vendite P2P c'è anche un maggior rischio di furto rispetto alle transazioni su piattaforma, il che giustifica una compensazione per il rischio corso. Infine, il costo aggiuntivo può essere legato alla domanda e alla qualità dello scambio in termini di riservatezza. Come acquirente, il guadagno in termini di riservatezza ha un prezzo che si riflette nel ricarico applicato dal venditore. Alcuni bitcoiners ritengono inoltre che il prezzo di ricarico del BTC acquistato su P2P rifletta il suo vero prezzo e sostengono che i prezzi più bassi sulle piattaforme regolamentate siano il risultato di un compromesso sulla riservatezza dei dati personali.

Per quanto riguarda le soluzioni, personalmente ho sempre utilizzato Bisq e ne sono molto soddisfatto. Il loro sistema è collaudato e sembra affidabile. Tuttavia, Bisq è disponibile solo su PC e la sua interfaccia potrebbe essere troppo complessa per i principianti. Un altro inconveniente è che Bisq opera solo con transazioni onchain, che possono diventare costose nei periodi in cui le commissioni delle transazioni Bitcoin sono elevate.

-> Vedere il nostro tutorial su Bisq.

https://planb.network/tutorials/exchange/peer-to-peer/bisq-fe244bfa-dcc4-4522-8ec7-92223373ed04

Per un'opzione più semplice, potete provare Peach, un'applicazione mobile che mette in contatto acquirenti e venditori con un sistema di risoluzione dei conflitti integrato. Il processo è più intuitivo di quello di Bisq.

-> Consultate il nostro tutorial su Peach.

https://planb.network/tutorials/exchange/peer-to-peer/peach-c6143241-d900-4047-9b73-1caba5e1f874

Un'altra opzione online è HodlHodl, una piattaforma consolidata che offre una buona liquidità, anche se non l'ho testata personalmente.

-> Vedere la nostra esercitazione su HodlHodl.

https://planb.network/tutorials/exchange/peer-to-peer/hodlhodl-d7344cd5-6b18-40f5-8e78-2574a93a3879

Per le soluzioni basate su Lightning Network, provate RoboSats e LNP2PBot. RoboSats è accessibile tramite un sito web ed è relativamente semplice da usare. LNP2PBot è più atipico, poiché funziona tramite un sistema di scambio sull'applicazione di messaggistica Telegram.

-> Vedere il nostro tutorial sui RoboSats.

-> Vedere la nostra esercitazione su LNP2PBot.

https://planb.network/tutorials/exchange/peer-to-peer/robosats-b60e4f7c-533a-4295-9f6d-5368152e8c06

https://planb.network/tutorials/exchange/peer-to-peer/lnp2pbot-v2-e6bcb210-610b-487d-970c-7cce85273e3c

Piattaforme regolamentate senza KYC

A seconda del Paese in cui si vive, si può avere accesso a piattaforme regolamentate che non richiedono procedure KYC per acquistare o vendere bitcoin. In Svizzera, ad esempio, è possibile utilizzare piattaforme come Relai e MtPelerin.

-> Vedere il nostro tutorial su Relai.

https://planb.network/tutorials/exchange/centralized/relai-v2-30a9671d-e407-459d-9203-4c3eae15b30e

Come abbiamo visto nel capitolo precedente, questo tipo di piattaforma evita i rischi associati alle procedure KYC, ma presenta un livello di rischio più elevato per l'identificazione delle chiavi. In termini di riservatezza dei Bitcoin, quindi, queste piattaforme offrono una protezione migliore rispetto ai metodi di acquisto con KYC, ma rimangono meno interessanti degli scambi P2P.

Tuttavia, in termini di sicurezza personale, l'utilizzo di queste piattaforme è molto meno rischioso rispetto agli scambi P2P. Inoltre, sono spesso più semplici da usare rispetto alle piattaforme P2P.

Bancomat

Un'altra opzione per acquistare o vendere bitcoin senza KYC sono i bancomat per criptovalute. Personalmente, non ho mai avuto l'opportunità di testare questa soluzione, poiché nel mio Paese non ce ne sono. Ma questo metodo può essere molto interessante, a seconda del luogo in cui si vive.

Il problema degli sportelli bancomat è che sono vietati in alcuni Paesi o fortemente regolamentati in altri. Se un bancomat richiede una procedura di verifica dell'identità, è esposto agli stessi rischi insiti nelle piattaforme regolamentate KYC. D'altra parte, se il bancomat consente transazioni senza verifica dell'identità per piccoli importi, il suo utilizzo può offrire un livello di riservatezza paragonabile a quello di uno scambio di contanti P2P, evitando la maggior parte dei rischi associati a questo tipo di scambio.

Lo svantaggio principale degli sportelli automatici è rappresentato dalle commissioni di cambio spesso elevate, che vanno da pochi punti percentuali fino a un massimo del 15% dell'importo scambiato.

Carte regalo

Infine, volevo anche presentarvi una soluzione che funziona bene per coloro che vogliono usare i loro bitcoin su base quotidiana per fare acquisti piuttosto che venderli contro valute fiat.

Il modo migliore per spendere BTC è, ovviamente, utilizzare Bitcoin o la Lightning Network direttamente per acquistare un bene o un servizio. Tuttavia, in molti Paesi il numero di commercianti che accettano Bitcoin è ancora limitato. Un'alternativa pratica è quella di utilizzare le carte regalo.

Diverse piattaforme che non richiedono procedure KYC offrono la possibilità di scambiare bitcoin con carte regalo utilizzabili presso i principali rivenditori. Tra queste, CoinsBee, The Bitcoin Company e Bitrefill. Queste piattaforme rendono molto più semplice l'utilizzo quotidiano dei bitcoin, dando accesso a un'ampia gamma di prodotti e servizi senza doverli convertire in valuta fiat.

https://planb.network/tutorials/exchange/centralized/bitrefill-8c588412-1bfc-465b-9bca-e647a647fbc1

Altri metodi di acquisizione

Altri modi per acquisire bitcoin proteggendo la propria privacy sono, ovviamente, il mining. Per iniziare l'attività di mining non è necessario rivelare la propria identità; è sufficiente trovare una prova di lavoro valida e inviarla alla rete. Se si opta per il mining in pool, alcuni pool richiedono una forma di identificazione, come un KYC, mentre altri non lo fanno.

Un altro metodo è quello di lavorare in cambio di bitcoin. Questo metodo di acquisizione può essere interessante, ma il grado di identificazione richiesto varia notevolmente a seconda delle circostanze.

*Per scrivere questo capitolo, ho utilizzato il corso di formazione BTC205 tenuto da @pivi___ sulla rete Plan ₿ (per ora disponibile solo in francese)

Consolidamento, gestione UTXO e CIOH

Uno degli aspetti più complicati della gestione di un portafoglio in autocustodia è il consolidamento. Dovete consolidare? Qual è lo scopo? Quale dimensione di UTXO si dovrebbe rispettare? Quali sono i compromessi in termini di riservatezza? Ecco cosa vedremo in questa sezione.

Che cos'è il consolidamento?

Bitcoin funziona come un mercato di aste, con i minatori che danno la preferenza alle transazioni che offrono le tariffe più basse. Tuttavia, ogni blocco ha un peso massimo, che limita il numero di transazioni che possono essere incluse. Poiché un blocco viene prodotto in media ogni 10 minuti, lo spazio disponibile in ogni blocco è una risorsa scarsa.

I minatori, le cui attività generano costi significativi in termini di elettricità, immobilizzazioni e manutenzione, cercano naturalmente di massimizzare la propria redditività. Pertanto, tendono a favorire le transazioni che generano le commissioni più elevate rispetto al loro peso.

Non tutte le transazioni Bitcoin hanno lo stesso peso. Quelle con più entrate e uscite avranno un peso maggiore. Ad esempio, immaginiamo 2 transazioni:

La transazione A comprende 1 ingresso e 1 uscita. Alloca 1.994 satelliti di tasse e ha un peso di 141 vB ;
La transazione B, una transazione più complessa con 2 ingressi e 2 uscite, assegna 2.640 satelliti in tasse per un peso di 220 vB.

In questo esempio, sebbene la transazione B offra una tariffa totale più alta, i minatori preferiranno la transazione A, in quanto offre un miglior rapporto tra tariffa e peso. Ecco il calcolo per ogni transazione, espresso in sat per byte virtuale (sat/vB):

TXA : 1994 / 141 = 14 sats/vB
TXB : 2640 / 220 = 12 sats / vB

Ciò significa che per ogni unità di peso, la transazione A offre più costi della transazione B, anche se la transazione B offre più costi in termini assoluti.

È quindi sempre più interessante per l'utente consumare il minor numero possibile di input nelle sue transazioni. Tuttavia, è necessario consumare quantità sufficienti per poter soddisfare il pagamento in uscita. Nella gestione del portafoglio, è necessario disporre di UTXO sufficientemente grandi.

Il principio del consolidamento consiste proprio nell'approfittare dei periodi in cui le commissioni sono basse su Bitcoin per fondere i suoi UTXO più piccoli in un unico più grande. In questo modo, quando le commissioni aumenteranno su Bitcoin, sarà possibile effettuare transazioni con un minimo di input, e quindi spendere meno in commissioni in termini assoluti. L'obiettivo è quindi quello di anticipare le transazioni obbligatorie da effettuare durante i periodi di commissioni elevate.

Oltre a risparmiare sui costi di transazione, il consolidamento degli UTXO aiuta a prevenire la formazione di "polvere". Per "polvere" si intendono gli UTXO il cui valore in saturazione è talmente basso da non essere sufficiente a coprire i costi di transazione necessari per spenderli. Ciò rende economicamente irrazionale l'uso di questi UTXO finché i costi di transazione rimangono elevati. Mettendo in comune in modo proattivo i vostri UTXO, eviterete che si trasformino in polvere, garantendo che tutti i vostri fondi rimangano utilizzabili.

Qual è la dimensione minima dei vostri UTXO?

A volte mi viene chiesto quale sia il valore minimo consigliato per un UTXO. Purtroppo non esiste una risposta universale, poiché dipende dalle vostre preferenze e dalle condizioni del mercato delle commissioni. Tuttavia, ecco una formula che può aiutarvi a determinare una soglia adatta alle vostre esigenze:

 $\frac {P \times F}T = M$

Dove:

p$ è il peso della transazione;
$F$ rappresenta il tasso di carica massimo in satoshis per vbyte (sats/vB) contro il quale ci si copre;
t$ è la percentuale della commissione di transazione che si è disposti a pagare rispetto al valore totale dell'UTXO ;
m$ è l'importo minimo in satoshi per ogni UTXO.

Supponiamo che si intenda coprire le commissioni per una transazione SegWit standard con 1 ingresso e 2 uscite, del peso di 141 vB. Se state coprendo fino a 800 sats/vB, e siete disposti a spendere fino al 12% del valore UTXO in commissioni al massimo, allora il calcolo sarebbe:

 $\frac{141 \times 800}{0.12} = 940\ 000$

In questo esempio, sarebbe quindi saggio mantenere un valore minimo di 940.000 saturazioni per gli UTXO nel proprio portafoglio.

Consolidamento e CIOH

Una delle euristiche più utilizzate nell'analisi della blockchain è la CIOH (Common Input Ownership Heuristic), che presuppone che tutti gli input di una transazione Bitcoin appartengano alla stessa entità. Il principio stesso del consolidamento consiste nel consumare diversi UTXO come input e creare un unico UTXO come output. Il consolidamento consente quindi di applicare l'ICOH.

In pratica, ciò significa che un osservatore esterno può dedurre che tutti gli UTXO consolidati appartengono probabilmente alla stessa persona e che anche l'output unico generato appartiene a quest'ultima. Questa situazione può mettere a repentaglio la vostra riservatezza, associando diverse cronologie di transazioni. Ad esempio, supponiamo che io consolidi 3 UTXO acquisiti tramite P2P con un UTXO ottenuto tramite una piattaforma che richiede il KYC:

In questo modo, qualsiasi entità che abbia accesso ai dati della piattaforma di scambio, comprese potenzialmente le agenzie governative, sarà in grado di identificare che possiedo altre quantità di BTC. In precedenza, questi UTXO non erano direttamente collegati alla mia identità; ora lo sono. Inoltre, rivelano a tutte le fonti che sono in possesso di una certa quantità di bitcoin.

Quando si tratta di gestire gli UTXO, le considerazioni economiche, che spingono al consolidamento per ridurre i costi, entrano in conflitto con le buone pratiche di privacy, che raccomandano di non fondere mai gli UTXO. La scelta tra economia e riservatezza dipende quindi dalle priorità di ciascun utente.

L'ideale è riuscire a evitare il consolidamento, mantenendo al tempo stesso un consistente UTXO. A tal fine, ottimizzate i vostri metodi di acquisizione. Se acquistate i bitcoin in DCA, cercate di scaglionare il più possibile gli acquisti una tantum per consolidare il valore su un minor numero di UTXO. Sarà più facile gestire un acquisto unico di 1.000 euro ogni 2 mesi, piuttosto che un acquisto di 120 euro ogni settimana. In questo modo si riduce il numero di UTXO generati e si semplifica la gestione del portafoglio, preservando la riservatezza.

Se vi trovate a dover consolidare i vostri bitcoin, preferite innanzitutto consolidare gli UTXO provenienti dalla stessa fonte. Ad esempio, l'unione di 10 UTXO provenienti da un'unica piattaforma inciderà meno sulla vostra riservatezza rispetto all'unione di 5 UTXO provenienti dalla piattaforma A con 5 UTXO provenienti dalla piattaforma B. Se il consolidamento di diverse fonti è inevitabile, cercate di separarle in base alle loro caratteristiche. Ad esempio, raggruppate gli UTXO acquisiti tramite KYC in una transazione e quelli ottenuti tramite P2P in un'altra.

In ogni caso, non dimenticate che qualsiasi consolidamento comporta inevitabilmente una perdita di riservatezza. Valutate quindi attentamente la necessità di questa operazione e il potenziale impatto sulla vostra privacy, tenendo conto del CIOH.

Altre migliori pratiche

Vediamo alcune altre buone pratiche per ottimizzare la vostra privacy su Bitcoin.

Il nodo completo

Possedere i propri bitcoin in autocustodia è fantastico, ma utilizzare il proprio nodo completo è ancora meglio! Ecco perché avere un proprio nodo è fondamentale per un uso pienamente sovrano di Bitcoin:

Resistenza alla censura**: Le vostre transazioni non possono essere bloccate da nessuno;
Indipendenza da terzi**: Non dipendete più da alcun servizio esterno per verificare i dati della blockchain;
Partecipazione attiva**: È possibile definire le proprie regole di convalida e partecipare direttamente al consenso;
Contributo alla rete**: Gestendo un nodo, si contribuisce a rafforzare e distribuire la rete Bitcoin;
Formazione tecnica**: La gestione di un nodo completo è un ottimo modo per approfondire la conoscenza tecnica di Bitcoin.

Oltre a questi vantaggi, l'utilizzo di un nodo completo migliora anche la riservatezza durante la trasmissione delle transazioni. Quando si emette una transazione, questa viene prima creata e firmata tramite il proprio portafoglio. Per diffonderla sulla rete Bitcoin, deve essere conosciuta da almeno un nodo. Utilizzando il proprio nodo, si ha il controllo diretto su questa distribuzione, rafforzando così la propria riservatezza e limitando il rischio di fuga di dati.

Se non si dispone di un proprio nodo Bitcoin, si è costretti a utilizzarne uno di terze parti, come quello offerto dal fornitore del software del portafoglio. Oltre a trasmettere le transazioni, il vostro portafoglio richiede l'accesso a varie informazioni, come le transazioni in sospeso, i saldi associati ai vostri indirizzi e il numero di conferme delle vostre transazioni. Per accedere a tutti questi dati, è necessario interrogare un nodo.

Il rischio principale quando non si utilizza il proprio nodo Bitcoin è che l'operatore del nodo di terze parti possa osservare le vostre attività sulla blockchain, o addirittura condividere queste informazioni con altre entità. Per limitare questo rischio, una soluzione intermedia è quella di utilizzare un software di portafoglio che maschera le connessioni tramite Tor. Questo può ridurre l'esposizione dei vostri dati. Tuttavia, la soluzione ottimale è avere un proprio nodo Bitcoin e usarlo per trasmettere le proprie transazioni. Naturalmente, dovrete anche fare attenzione a non far trapelare alcuna informazione attraverso il vostro nodo, ma questo è un altro argomento che esamineremo nelle sezioni successive.

Oltre all'ovvio vantaggio per la vostra privacy, avere un proprio nodo completo vi assicura anche della veridicità dei dati sulla blockchain, vi protegge dalla censura e vi permette di partecipare attivamente alla governance di Bitcoin. Utilizzando il proprio nodo, si contribuisce con il proprio peso economico alla catena di propria scelta, il che è importante durante i conflitti all'interno della comunità, come ad esempio durante la Blocksize War dal 2015 al 2017. In caso di fork, l'utilizzo di un nodo di terze parti potrebbe portarvi a sostenere una catena che non volete favorire, poiché l'operatore del nodo effettua la scelta al posto vostro.

Come si può notare, nell'interesse della riservatezza e della sovranità individuale, è essenziale gestire e utilizzare il proprio nodo completo!

Euristica di analisi ingannevole

Più in generale, è importante comprendere le euristiche di cui abbiamo parlato nella sezione precedente, in modo da evitarle o ingannarle meglio. L'adozione di una serie di buone pratiche può essere vantaggiosa, anche se non essenziale. Esse offrono un ulteriore livello di protezione che può essere importante per mantenere la riservatezza quando si utilizza Bitcoin.

Il primo consiglio che potrei dare è quello di mescolarsi alla folla più folta. Su Bitcoin, questo significa utilizzare i modelli di script più diffusi. Ad esempio, gli script P2WSH, spesso utilizzati per le configurazioni SegWit V0 multisig, sono molto poco comuni. Non consentono di nascondersi in un ampio set di anonimato. Lo stesso vale per i modelli più vecchi, come P2PKH o P2SH. Sebbene siano ampiamente presenti nell'insieme UTXO, vengono utilizzati sempre meno per le nuove transazioni.

In generale, è più saggio optare per lo standard di scripting più recente, purché sia stato sufficientemente adottato. Quindi, se nel 2022 avrei sconsigliato l'uso di P2TR (Taproot) a causa della sua scarsa adozione, nel 2024 consiglierei invece di optare per questo tipo di script o, in mancanza, per lo script SegWit V0, dato che il numero di transazioni che utilizzano P2TR inizia a rappresentare una percentuale molto significativa.

Fonte : txstats.com

Un altro consiglio per preservare la riservatezza è quello di cercare di aggirare l'euristica delle transazioni interne. Ad esempio, quando si effettua un pagamento, si può cercare di evitare di creare un'uscita con un importo rotondo, in quanto ciò potrebbe segnalare che l'altra uscita rappresenta valuta estera. Se dovete inviare 100 k sats a un amico, considerate la possibilità di trasferire un importo leggermente superiore per evitare questa euristica. Allo stesso modo, cercate di non creare uscite in valuta estera che siano sproporzionatamente alte rispetto al pagamento effettuato, perché anche questo potrebbe rivelare quale delle uscite rappresenta valuta estera.

Infine, se eseguite transazioni Bitcoin regolarmente, assicuratevi di non trasmetterle sempre negli stessi orari. Distribuendo la trasmissione delle transazioni nell'arco della giornata e della settimana, si evita di dare agli osservatori esterni l'opportunità di rilevare uno schema temporale basato sulla fascia oraria che potrebbe rafforzare la loro analisi.

Oltre a tutte queste buone pratiche da adottare quotidianamente, esistono metodi ancora più efficaci per interrompere completamente la tracciabilità dei bitcoin. Questi includono, naturalmente, le transazioni coinjoin, che analizzeremo in modo approfondito nella prossima sezione.

Comprendere le transazioni coinjoin

Cos'è una transazione coinjoin?

Dopo aver studiato i fondamenti della protezione della privacy, ora esamineremo tecniche più sofisticate volte a difendere attivamente la vostra riservatezza, in particolare disaggregando la vostra cronologia dei bitcoin. Nella prossima parte esamineremo tutta una serie di piccole tecniche, ma prima vorrei parlarvi di coinjoin.

Coinjoin è spesso considerato il metodo più efficace per proteggere la privacy degli utenti Bitcoin. Ma cos'è esattamente una transazione coinjoin? Scopriamolo.

I principi di base della coinjoin

Coinjoin è una tecnica per rompere la tracciabilità dei bitcoin sulla blockchain. Si basa su una transazione collaborativa con una struttura specifica che porta lo stesso nome: la transazione coinjoin.

Come abbiamo visto nelle prime parti di questo corso, le transazioni Bitcoin sono note a tutti gli utenti attraverso il loro nodo. È quindi facile controllare la catena di firme elettroniche di ogni moneta e osservarne la storia. Ciò significa che tutti gli utenti possono cercare di analizzare le transazioni di altri utenti. Di conseguenza, l'anonimato a livello di transazione è impossibile. Tuttavia, l'anonimato è preservato a livello di identificazione individuale. A differenza del sistema bancario convenzionale, dove ogni conto è collegato a un'identità personale, in Bitcoin i fondi sono associati a coppie di chiavi crittografiche (o script), offrendo agli utenti una forma di pseudonimato dietro a identificatori crittografici.

La riservatezza di Bitcoin è minata quando osservatori esterni sono in grado di associare UTXO specifici a utenti identificati. Una volta stabilita questa associazione, diventa possibile tracciare le loro transazioni e analizzare la loro storia Bitcoin. Coinjoin è proprio una tecnica sviluppata per rompere la tracciabilità degli UTXO, al fine di offrire agli utenti Bitcoin un certo livello di riservatezza a livello di transazione.

Le Coinjoin rafforzano la riservatezza degli utenti Bitcoin rendendo più complessa l'analisi della catena per gli osservatori esterni. La loro struttura consente di unire più monete di utenti diversi in un'unica transazione, confondendo le linee di demarcazione e rendendo difficile determinare i collegamenti tra gli indirizzi di ingresso e di uscita.

È importante capire che lo scopo di una transazione coinjoin è quello di interrompere la storia di una moneta. Questa tecnica non conferisce un anonimato permanente né blocca definitivamente la tracciabilità dei bitcoin, contrariamente a quanto si potrebbe pensare. Coinjoin mira a interrompere la cronologia solo nel momento in cui viene effettuata la transazione coinjoin. Tuttavia, prima e dopo questa operazione, la moneta rimane soggetta agli stessi rischi in termini di riservatezza.

Come funzionano le coinjoin?

Il principio coinjoin si basa su un approccio collaborativo: diversi utenti che desiderano mescolare i propri bitcoin depositano importi identici come input della stessa transazione. Questi importi vengono poi ridistribuiti in output di pari valore per ciascun utente.

Al termine della transazione, diventa impossibile associare un output specifico a un utente noto come input. Non esiste un legame diretto tra ingressi e uscite, il che interrompe l'associazione tra gli utenti e i loro UTXO, nonché la storia di ogni parte.

Prendiamo l'esempio di Alice. Vuole inviare circa 100.000 sats a sua sorella Eve per il suo compleanno. Tuttavia, Alice non vuole che Eve sia in grado di tracciare la cronologia delle sue transazioni, poiché non vuole rivelare quanti bitcoin possiede o come li ha ottenuti. A tal fine, Alice decide di interrompere la sua cronologia UTXO con una transazione coinjoin. Si organizza con Bob, Charles, David e Frank per effettuare una transazione collaborativa:

Alice, Bob, Charles, David e Frank impegnano ciascuno un UTXO di 105.000 sats (con 5.000 sats per le tasse di estrazione) come input della transazione:

In cambio del consumo di questi input, ciascuno genera un indirizzo vuoto per creare cinque uscite identiche di 100.000 saturazioni ciascuna. Ciascuno recupera un'uscita:

Alice si ritrova con un UTXO di 100.000 satelliti la cui storia è confusa. Utilizza questo UTXO in una nuova transazione per inviare l'importo a Eve per il suo compleanno:

Se Eve cerca di analizzare questa transazione per estrarre informazioni, si troverà di fronte alla transazione coinjoin che coinvolge Alice, Bob, Charles, David e Frank. Non potendo distinguere quale input appartiene a chi a causa dell'uniformità degli importi, Eve non può tracciare la storia UTXO di Alice, né determinare quanti bitcoin possiede la sorella o come li ha acquisiti:

In questo caso, Alice ha utilizzato la tecnica coinjoin per aumentare la riservatezza rispetto all'analisi retrospettiva. In effetti, Alice si sta proteggendo da una possibile analisi da parte di Eve, che partirebbe da una transazione specifica e lavorerebbe a ritroso attraverso la storia dell'UTXO. Questa protezione contro l'analisi dal presente al passato è nota come anonset retrospettiva. Analizzeremo questo concetto in modo più dettagliato negli ultimi capitoli di questa sezione.

Tuttavia, coinjoin offre anche la possibilità di rafforzare la riservatezza a fronte di un'analisi dal passato al presente, nota come prospective anonset. Torniamo all'esempio in cui Alice ha inviato a Eve 98.000 chat per il suo compleanno, ma a ruoli invertiti. Immaginiamo ora che sia Eve a preoccuparsi della sua privacy. Infatti, Alice potrebbe essere tentata di tracciare la moneta che ha inviato a Eve per estrarne informazioni. Eve potrebbe consolidare l'UTXO appena ricevuto con tutti gli altri UTXO, il che potrebbe rivelare ad Alice la quantità di bitcoin che ha nel suo portafoglio. Per evitare ciò, Eve può anche interrompere la cronologia della moneta appena ricevuta:

Eve, Grace, Mallory, Oscar e Victor hanno inserito un UTXO di 98.000 saturazioni come input per una transazione Bitcoin:

In cambio del consumo di questi input, ogni utente fornisce un indirizzo vuoto da utilizzare per creare 5 output di 97.500 satelliti perfettamente uguali. Ogni utente riceve un output:

Eve possiede ora un UTXO di 97.500 saturazioni la cui storia è stata interrotta. Può usarlo senza timore per effettuare transazioni future. Infatti, se Alice cerca di rintracciare i bitcoin che ha inviato a Eve, si troverà di fronte a una transazione coinjoin. Non sarà in grado di determinare quale UTXO in uscita appartiene a Eve. L'analisi diventa impossibile:

Nel primo esempio abbiamo visto come il coinjoin possa proteggere la privacy di una stanza in relazione al suo passato e, nel secondo esempio, come possa anche proteggere la storia di una stanza in relazione al suo futuro. Ecco perché ho detto che il coinjoin dovrebbe essere visto come un evento unico che segmenta una parte di storia in entrambe le direzioni:

Mixer, coinjoin, mixer... Qual è la differenza?

Le coinjoin sono talvolta descritte come "mixer", un termine che alcuni bitcoiners rifiutano, temendo che possa essere confuso con i mixer custodiali. Ritengo, tuttavia, che tale timore sia infondato, poiché, in un contesto matematico, la coinjoin incarna proprio il concetto di miscelazione.

Nel campo della matematica generale, la mescolanza si riferisce alla proprietà di un sistema dinamico in cui, dopo un certo periodo di tempo, tutte le porzioni dello spazio iniziale possono teoricamente mescolarsi con qualsiasi altra porzione. Il mescolamento implica che la posizione di una particella o lo stato di un sistema si evolva in modo tale che la sua distribuzione futura sia indipendente dalla distribuzione iniziale, raggiungendo così uno stato in cui le caratteristiche dello stato iniziale sono uniformemente distribuite nello spazio del sistema. Questo è esattamente ciò che accade in una coinjoin con i bitcoin. Quindi, a mio parere, coinjoin è davvero un metodo di miscelazione di monete.

D'altra parte, è importante distinguere coinjoin dagli shuffler. Uno shuffler è un servizio in cui gli utenti inviano i loro bitcoin per essere mescolati. Questi servizi erano popolari negli anni 2010, ma il loro utilizzo è diminuito a causa di due principali svantaggi rispetto a coinjoin:

Richiedono agli utenti di rinunciare alla custodia dei propri fondi durante il processo di miscelazione, esponendoli al rischio di furto;
Non c'è garanzia che il mixer non registri i dettagli delle transazioni o che non venda queste informazioni a società di analisi della catena.

Gli utenti di oggi preferiscono quindi coinjoin, in quanto consente loro di mantenere il controllo totale sui propri fondi durante l'intero processo. I partecipanti a Coinjoin non corrono il rischio che i loro bitcoin vengano rubati dalle altre parti coinvolte. Vediamo come tutto questo è possibile nel prossimo capitolo.

Zerolink e coinjoin chaumian

La privacy fornita da un coinjoin è guadagnata dalla dimensione del gruppo in cui il nostro pezzo è nascosto. Ciò significa trovare il maggior numero possibile di partecipanti. È perfettamente possibile creare una coinjoin manualmente, con utenti che abbiamo trovato noi stessi, ma è un processo complesso e non vi farà guadagnare grandi anonset.

Per questo motivo su Bitcoin si sono sviluppati i coordinatori di coinjoin. Il loro ruolo è quello di mettere in contatto i vari utenti e trasmettere le informazioni necessarie per completare la transazione collaborativa.

Ma come possiamo assicurarci che il coordinatore non metta mai le mani sui bitcoin degli utenti e, nonostante sia la persona che crea la transazione coinjoin, come possiamo assicurarci che non possa collegare gli input e gli output degli utenti, il che potrebbe costituire una perdita di riservatezza?

Le firme cieche di Chaum

Le moderne implementazioni di coinjoin utilizzano le firme cieche di David Chaum per evitare la fuga di informazioni. Diamo una rapida occhiata a come funzionano queste firme cieche.

Le firme cieche di Chaum sono una forma di firma digitale in cui l'emittente della firma non conosce il contenuto del messaggio che sta firmando. Ma la firma può essere verificata rispetto al messaggio originale. Questa tecnica è stata sviluppata dal crittografo David Chaum nel 1983.

Prendiamo l'esempio di un'azienda che desidera autenticare un documento riservato, come un contratto, senza rivelarne il contenuto. L'azienda applica un processo di mascheramento che trasforma crittograficamente il documento originale in modo reversibile. Il documento modificato viene inviato a un'autorità di certificazione, che appone una firma cieca senza conoscere il contenuto sottostante. Dopo aver ricevuto il documento firmato, l'azienda smaschera la firma. Il risultato è un documento originale autenticato dalla firma dell'autorità, senza che quest'ultima abbia mai visto il contenuto originale.

Le firme cieche di Chaum possono quindi certificare l'autenticità di un documento senza conoscerne il contenuto, garantendo così sia la riservatezza dei dati dell'utente che l'integrità del documento firmato.

Chaumian coinjoins

Le cosiddette coinjoin "chaumiane" combinano l'uso di Tor e delle firme cieche di David Chaum per garantire che il coordinatore non possa sapere quale output appartiene a quale utente.

Il processo di costruzione della transazione coinjoin prevede 3 fasi principali: la registrazione degli input, la registrazione degli output e la firma della transazione. Vediamo questo processo attraverso l'esempio di Alice, uno dei partecipanti al coinjoin. Tutti gli altri partecipanti seguono gli stessi passi di Alice, ognuno per conto proprio.

**Fase 1: registrazione dell'ingresso

Alice trasmette al coordinatore l'UTXO che desidera utilizzare come input per la transazione, nonché l'indirizzo di ricezione mascherato che desidera utilizzare come output per ricevere i suoi bitcoin. Il coordinatore non ha quindi modo di conoscere l'indirizzo di Alice. Vede solo la sua versione mascherata:

Il coordinatore controlla la validità degli input, quindi firma l'indirizzo mascherato di Alice con la sua chiave privata. Restituisce la firma cieca ad Alice:

Fase 2: registrazione delle uscite

Alice può smascherare il suo indirizzo, ora firmato dalla chiave privata del coordinatore. Stabilirà una nuova connessione con una diversa identità Tor. Il coordinatore non può identificare che è Alice a connettersi con questa nuova identità:

Alice invia l'indirizzo smascherato e la firma al coordinatore (che ancora non sa che si tratta di Alice):

Fase 3: firma della transazione

Allo stesso modo, il coordinatore recupera gli output non mascherati da tutti i partecipanti. Grazie alle firme associate, può verificare che ogni output anonimo presentato sia stato firmato in precedenza dalla sua chiave privata, garantendone così la legittimità. È quindi pronto a costruire la transazione coinjoin e la invia ai partecipanti per la firma:

Alice, come gli altri partecipanti, controlla che i suoi input e output siano correttamente inclusi nella transazione costruita dal coordinatore. Se tutto è soddisfacente, invia al coordinatore la firma che sblocca il suo script di input:

Dopo aver raccolto le firme di tutti i partecipanti al coinjoin, il coordinatore può trasmettere la transazione sulla rete Bitcoin, in modo che possa essere aggiunta a un blocco.

In questo sistema, il coordinatore non è in grado di collegare un input a un output specifico. Inoltre, non può appropriarsi dei fondi dei partecipanti, poiché non ha mai accesso alle chiavi private necessarie per sbloccare i loro UTXO. Durante tutto il processo, fino alla fine della fase 3, non ha nemmeno accesso alle firme. Quando Alice e gli altri partecipanti firmano la transazione globale, dopo aver controllato che tutto sia corretto, il coordinatore non può più modificare la transazione, compresi gli output, senza invalidarla. Questo impedisce al coordinatore di rubare bitcoin.

Infine, quando registra il suo output nella transazione, l'utente di coinjoin desidera avere garanzie simili a quelle di un cittadino che vota alle elezioni. Esiste una dualità tra gli aspetti pubblici e privati di queste azioni. Da un lato, c'è ciò che si vuole mantenere privato: per l'elettore, non vuole che il suo voto sia collegato alla sua identità; per l'utente coinjoin, non vuole che il suo output sia associato al suo input. Infatti, se il coordinatore, o qualsiasi altra parte, riesce a stabilire un collegamento tra un input e un output, la coinjoin perde ogni interesse. Come spiegato in precedenza, il coinjoin deve funzionare come una pausa nella storia di una moneta. Questo arresto avviene proprio a causa dell'impossibilità di associare uno specifico input a uno specifico output nella transazione coinjoin (anonset prospettico) e viceversa (anonset retrospettivo).

D'altra parte, c'è l'aspetto pubblico: l'elettore vuole essere sicuro che la sua scheda sia inclusa nell'urna; allo stesso modo, l'utente di coinjoin vuole essere sicuro che il suo output sia incluso nella transazione coinjoin. Infatti, i partecipanti a coinjoin devono assolutamente essere in grado di verificare la presenza del loro output prima di firmare la transazione, altrimenti il coordinatore potrebbe rubare i fondi.

Sono proprio questi due aspetti, pubblico e privato, abilitati dall'uso delle firme cieche di David Chaum, a garantire ai partecipanti alle coinjoin chaumiane che i loro bitcoin non saranno rubati e che i loro fondi non potranno essere rintracciati.

Chi ha inventato il concetto di coinjoin?

È difficile stabilire con certezza chi abbia introdotto per primo l'idea del coinjoin in Bitcoin e chi abbia avuto l'idea di utilizzare le firme cieche di David Chaum in questo contesto. Spesso si pensa che sia stato Gregory Maxwell a parlarne per primo in un messaggio su BitcoinTalk del 2013 :

*"Utilizza le firme cieche di Chaum: Gli utenti si collegano e forniscono gli input (e si scambiano gli indirizzi) e una versione crittograficamente blindata dell'indirizzo a cui desiderano inviare le loro parti private; il server firma i token e li invia indietro. Gli utenti si riconnettono in modo anonimo, smascherano i loro indirizzi di uscita e li inviano nuovamente al server. Il server può vedere che tutti gli output sono stati firmati da lui e che, di conseguenza, tutti gli output provengono da partecipanti validi. In seguito, le persone si riconnettono e si registrano Maxwell, G. (2013, 22 agosto). CoinJoin: La privacy dei Bitcoin per il mondo reale. Forum BitcoinTalk. https://bitcointalk.org/index.php?topic=279249.0

Tuttavia, ci sono altre menzioni precedenti, sia per le firme Chaum come parte del mixaggio, ma anche per le coinjoin. Nel giugno 2011, Duncan Townsend ha presentato su BitcoinTalk un mixer che utilizza le firme Chaum in modo del tutto simile alle moderne coinjoin chaumiane.

Nello stesso thread, possiamo trovare un messaggio di hashcoin in risposta a Duncan Townsend per migliorare il suo mixer. Il processo descritto in questo messaggio è esattamente l'obiettivo delle coinjoin. Una menzione di un sistema simile si trova anche in un messaggio di Alex Mizrahi del 2012, quando consigliava i creatori di Tenebrix, una delle prime altcoin che è servita come base per la successiva creazione di Litecoin. Anche il termine stesso "coinjoin" non sarebbe stato coniato da Greg Maxwell, ma sarebbe nato da un'idea di Peter Todd.

Zerolink

Zerolink è un protocollo di miscelazione completo che incorpora coinjoin chaumiani e varie strategie per proteggere l'anonimato degli utenti da diverse forme di analisi della catena, in particolare riducendo al minimo gli errori associati alla gestione del portafoglio. Questo protocollo è stato introdotto da nopara73 e TDevD nel 2017.

Come suggerisce il nome, il principio alla base di Zerolink è quello di creare transazioni coinjoin che garantiscano l'impossibilità di rintracciare i collegamenti tra entrate e uscite. Ciò si ottiene garantendo che tutte le uscite abbiano importi perfettamente identici.

Un'importante misura preventiva adottata da Zerolink consiste nel tenere completamente separati gli UTXO non miscelati da quelli miscelati, utilizzando set di chiavi crittografiche separati o addirittura portafogli separati. Questo differenzia il portafoglio "pre-mix", destinato alle parti prima della miscelazione, dal portafoglio "post-mix", riservato alle parti miscelate.

Questa rigorosa separazione degli UTXO serve soprattutto a prevenire associazioni accidentali tra un UTXO misto e un UTXO non misto. Infatti, se si verificano tali legami, l'efficacia del coinjoin sull'UTXO misto viene annullata senza che l'utente se ne renda conto, compromettendo così la riservatezza di un UTXO di cui pensava di aver interrotto la storia. Questi legami possono verificarsi sia attraverso il riutilizzo dell'indirizzo nella messa in sicurezza di un UTXO misto con uno non misto, sia attraverso l'applicazione della CIOH (Common-Input-Ownership Heuristic), se l'utente consuma UTXO misti e non misti come input della stessa transazione. Separando i portafogli pre-mix e post-mix, evitiamo queste associazioni accidentali e proteggiamo l'utente da errori non intenzionali.

Questa separazione offre anche la possibilità di applicare regole distinte tra portafogli pre-mix e post-mix a livello di software di portafoglio. Ad esempio, nel portafoglio post-mixing, il software può vietare la fusione di UTXO in ingressi per evitare l'applicazione di CIOH, che comprometterebbe l'anonset dell'utente. È inoltre possibile standardizzare l'uso di script e opzioni di transazione (come ad esempio il reporting RBF) per impedire l'identificazione tramite le impronte digitali del portafoglio.

Attualmente, Whirlpool è l'unica implementazione di coinjoin che applica rigorosamente il protocollo Zerolink. Nel prossimo capitolo esamineremo le varie implementazioni di coinjoin esistenti e i vantaggi e gli svantaggi di ciascuna.

Implementazioni di Coinjoin

*Nel 2024 stiamo assistendo a grandi cambiamenti negli strumenti a disposizione degli utenti che desiderano effettuare coinjoin su Bitcoin. Siamo attualmente a un punto di svolta e il mercato delle coinjoin sta subendo una profonda ristrutturazione. Questo capitolo sarà sicuramente aggiornato nel tempo

Al momento esistono principalmente 3 diverse implementazioni di coinjoin su Bitcoin:

Whirlpool;
Wabisabi;
JoinMarket.

Ciascuna di queste implementazioni mira a interrompere la storia degli UTXO attraverso le transazioni coinjoin. Tuttavia, i loro meccanismi variano notevolmente. È quindi essenziale capire come funzionano, in modo da poter scegliere l'opzione più adatta alle proprie esigenze.

Iscriviti al mercato

JoinMarket, fondata nel 2015 da Adam Gibson e Chris Belcher, si distingue nettamente dalle altre implementazioni di coinjoin grazie al suo modello unico di connessione tra gli utenti. Il sistema si basa su un mercato di scambio P2P in cui alcuni utenti, i "makers", mettono a disposizione i loro bitcoin per la miscelazione, mentre altri, i "takers", utilizzano questo denaro per effettuare coinjoin in cambio di una commissione.

In questo modello, i "maker" mettono i loro bitcoin a disposizione dei "taker" e ricevono una tariffa per il loro servizio. I taker, a loro volta, pagano per utilizzare i bitcoin dei maker per effettuare le proprie transazioni coinjoin. Le commissioni per il servizio variano a seconda del ruolo occupato: i "maker" accumulano commissioni per offrire liquidità, mentre i "taker" pagano le commissioni. Il mercato opera liberamente, senza condizioni d'uso.

Uno dei principali svantaggi di JoinMarket è la sua complessità d'uso, che richiede un certo grado di familiarità con i terminali per operare in modo efficace. Sebbene questa complessità non rappresenti un ostacolo per gli utenti esperti, può limitare l'accesso al grande pubblico. Tuttavia, la recente introduzione di un'interfaccia web chiamata JAM ha reso l'utilizzo un po' più semplice.

Fonte : JAM

Tuttavia, la barriera tecnica rimane un ostacolo importante. Nell'ecosistema delle coinjoin, dove la riservatezza è rafforzata dal numero di partecipanti, qualsiasi limitazione che riduca l'accessibilità influisce direttamente sulla liquidità disponibile, che è un fattore cruciale per l'efficienza del mix. Bitcoin, essendo già una nicchia nelle transazioni finanziarie, vede l'uso delle coinjoin come una sotto-nicchia, e JoinMarket ne rappresenta una frazione ancora più specializzata, il che limita quindi il suo potenziale per aumentare le anonset dei suoi utenti.

Nonostante l'innovativo modello di collegamento P2P per i coinjoiner, JoinMarket presenta alcuni svantaggi significativi, soprattutto in termini di struttura transazionale. A differenza di altre implementazioni come Whirlpool, JoinMarket non garantisce una perfetta uguaglianza tra le uscite ed è possibile tracciare collegamenti deterministici tra ingressi e uscite. Inoltre, non dispone di strumenti per impedire che parti già mescolate tra loro vengano nuovamente mescolate, il che potrebbe compromettere la riservatezza ricercata dagli utenti.

Infine, mentre il concetto di JoinMarket è interessante, soprattutto per chi è interessato a un mercato dinamico della liquidità, le sue debolezze strutturali e la sua complessità tecnica lo rendono, a mio parere, meno interessante sia per i principianti che per gli esperti alla ricerca di un'implementazione di coinjoin.

Wabisabi

Wabisabi è un'altra implementazione di coinjoin, con un approccio che centralizza il coordinamento delle transazioni. Questo modello è stato concepito da Ádám Ficsór (nopara73), Yuval Kogman, Lucas Ontivero e István András Seres nel 2021 ed è stato integrato nel software Wasabi 2.0 l'anno successivo. Wabisabi è proprio un'evoluzione del modello di coinjoin del software Wasabi lanciato nel 2018.

Verso la fine degli anni 2010, Wasabi ha adottato una struttura di transazioni coinjoin radicalmente diversa da quella di Whirlpool. Wasabi utilizzava transazioni coinjoin molto grandi che coinvolgevano decine di partecipanti per aumentare gli anonset dei suoi partecipanti. Al contrario, Whirlpool ha optato per transazioni multiple di piccole dimensioni, consentendo agli anonset di crescere esponenzialmente a ogni ciclo.

Anche i metodi di gestione dei cambi distinguevano le due implementazioni. Con Whirlpool, la valuta estera veniva esclusa e isolata dagli UTXO prima dei cicli coinjoin grazie a TX0, un concetto che spiegherò meglio nel prossimo capitolo. Con Wasabi, invece, la valuta estera costituiva uno degli output della transazione coinjoin, mantenendo legami deterministici tra alcuni input e output.

Con Wabisabi, la versione 2.0 di Wasabi ha adattato il suo approccio alle coinjoin a quello di Whirlpool. Sebbene le transazioni coinjoin rimangano molto grandi, è ora possibile concatenare più cicli successivi, seguendo il modello Whirlpool. Particolare attenzione è stata posta anche alla gestione del tasso di cambio: a differenza di Wasabi 1.0, dove il tasso di cambio era direttamente legato agli input dell'utente, Wabisabi cerca di suddividere il tasso di cambio in diverse piccole somme, divise in tagli uguali per tutti i partecipanti.

Illustriamo questo aspetto con un esempio semplificato che coinvolge solo 2 utenti: Alice desidera mescolare 115.000 sats e Bob 210.000 sats. Ignorando le commissioni, con Wasabi 1.0, una transazione coinjoin avrebbe generato 3 uscite di 100.000 sats, più 1 scambio di 15.000 sats per Alice e 1 scambio di 10.000 sats per Bob. Gli output dello scambio sarebbero ancora collegati agli input:

Secondo Wabisabi, la stessa transazione avrebbe prodotto 3 output da 100.000 sats e 5 output da 5.000 sats, disperdendo così lo scambio in modo che non potesse essere direttamente collegato a uno specifico input:

Personalmente, trovo che la gestione dei cambi di Wabisabi presenti diversi rischi che potrebbero compromettere la sua efficacia in termini di riservatezza:

Quando un utente contribuisce con un UTXO significativamente più grande di quello degli altri partecipanti, inevitabilmente si ritrova con un importo di scambio legato al suo contributo. Ciò è in contrasto con l'obiettivo originario del protocollo, che è quello di eliminare tutti gli scambi identificabili;
La moltiplicazione delle denominazioni con l'obiettivo di frammentare lo scambio può paradossalmente essere dannosa per l'efficienza della miscelazione. Questo processo può portare a una riduzione degli anonset per alcuni output, in quanto diventano più facilmente identificabili;
Questo metodo genera anche UTXO di basso valore che pongono un problema di gestione per l'utente. Questi piccoli UTXO, se diventano troppo costosi da spendere rispetto al loro valore, possono diventare "polvere". Questo fenomeno porta l'utente a fondere diversi UTXO in input per transazioni future, oppure a consolidarli. In entrambi i casi, a causa del CIOH, ciò può ridurre gli anonset ottenuti o annullare completamente i vantaggi di riservatezza acquisiti con la coinjoin iniziale.

A differenza di Whirlpool, che implementa il protocollo ZeroLink garantendo una rigorosa separazione tra UTXO pre-mix e post-mix, Wabisabi non mantiene questa rigorosa segregazione. Si sono inoltre verificati problemi di riutilizzo degli indirizzi da parte di alcuni clienti Wasabi, che sono ovviamente molto dannosi per l'utente.

Nella versione 2.0 di Wasabi è stata implementata una nuova politica di commissioni per le coinjoin. D'ora in poi, le commissioni di coordinamento sono fissate allo 0,3% per gli UTXO superiori a 0,01 bitcoin, mentre per gli UTXO più piccoli queste commissioni sono offerte per intero. Inoltre, i remix per questi UTXO più piccoli sono gratuiti, anche se le commissioni di estrazione restano a carico dell'utente per tutte le transazioni, compresi i remix.

Questo contrasta con la politica di Whirlpool, dove le commissioni rimangono fisse, indipendentemente dalle dimensioni degli anonset ottenuti. Con Wasabi 2.0, anche se le tariffe di coordinamento sono esentate per i piccoli UTXO, l'utente deve comunque pagare le tariffe di estrazione per tutte le transazioni, compresi i remix.

Mentre scrivo queste righe, l'uso di Wabisabi è diventato significativamente più complesso a seguito di eventi recenti. In seguito all'arresto dei fondatori di Samourai Wallet, zkSNACKs, la società che finanzia e gestisce lo sviluppo di Wasabi, ha annunciato che il suo servizio di coinjoin coordinator sarà interrotto il 1° giugno 2024. Questo coordinatore, impostato di default su Wasabi, era responsabile della maggior parte della liquidità.

Con l'interruzione di questo coordinatore principale, gli utenti devono ora collegarsi a nuovi coordinatori indipendenti. Questo cambiamento solleva una serie di preoccupazioni: da un lato, i nuovi coordinatori potrebbero non avere sufficiente liquidità, riducendo l'efficacia delle coinjoin in termini di riservatezza. Dall'altro, c'è il rischio di imbattersi in un coordinatore malintenzionato. Questa situazione aggiunge nuovi rischi significativi per chi cerca di utilizzare Wabisabi.

Al di là delle questioni tecniche, la decisione di zkSNACKs, la società dietro Wasabi, di utilizzare i servizi di una società di analisi delle stringhe per filtrare i partecipanti alle coinjoin solleva seri interrogativi etici e strategici. L'idea iniziale era quella di impedire l'uso di coinjoin su Wasabi da parte di criminali, una mossa che può sembrare legittima. Tuttavia, solleva un paradosso: pagare le tasse a un coordinatore la cui missione principale è quella di rafforzare la riservatezza degli utenti, solo per fargli finanziare una società il cui scopo è quello di compromettere la stessa riservatezza.

Ancora più preoccupante è il principio del filtraggio, che contrasta radicalmente con la filosofia di Bitcoin di offrire un sistema finanziario aperto e senza censure. Se da un lato può sembrare giustificato voler escludere le attività criminali, dall'altro questo filtraggio potrebbe colpire anche individui le cui azioni, pur essendo classificate come illegali in certi contesti, potrebbero essere moralmente giustificabili o socialmente utili. L'esempio di Edward Snowden illustra perfettamente questa dicotomia: considerato un criminale da alcuni governi per le sue rivelazioni, è visto da altri come un whistleblower che ha agito nell'interesse pubblico. Questa complessità sottolinea il potenziale pericolo di un filtraggio che, per quanto animato da buone intenzioni, può in ultima analisi minare i diritti e la sicurezza degli utenti legittimi. Avrei potuto citare anche attivisti e giornalisti perseguitati da alcuni regimi autoritari.

Come ormai avrete capito, la mia preferenza va decisamente al modello Whirlpool per le coinjoin su Bitcoin. Questo sistema si distingue per il suo rigore e offre garanzie superiori di riservatezza. È anche l'unico a offrire un mix considerato perfetto in un contesto matematico. A mio avviso, questo modello rappresenta il futuro delle coinjoin su Bitcoin. Vi invito ad approfondire questo modello nel prossimo capitolo.

Come funziona Whirlpool

Ciò che distingue Whirlpool da altri metodi di coinjoin è l'uso di transazioni "ZeroLink", che assicurano che non vi sia alcun legame tecnico possibile tra tutti gli input e gli output. Questo mix perfetto si ottiene attraverso una struttura in cui ogni partecipante contribuisce con una quantità identica di input (ad eccezione delle commissioni di estrazione), generando output di quantità perfettamente uguali.

Questo approccio restrittivo agli input conferisce alle transazioni coinjoin di Whirlpool una caratteristica unica: la totale assenza di legami deterministici tra input e output. In altre parole, ogni output ha la stessa probabilità di essere attribuito a qualsiasi partecipante, rispetto a tutti gli altri output della transazione.

Come funziona Whirlpool

Inizialmente, il numero di partecipanti a ogni coinjoin di Whirlpool era limitato a 5, con 2 nuovi entranti e 3 remixer (spiegheremo questi concetti più avanti). Tuttavia, l'aumento delle commissioni sulle transazioni on-chain osservato nel 2023 ha spinto i team di Samourai a ripensare il modello per migliorare la riservatezza e ridurre i costi. Pertanto, tenendo conto della situazione del mercato delle commissioni e del numero di partecipanti, il coordinatore può ora organizzare coinjoin con 6, 7 o 8 partecipanti. Queste sessioni potenziate sono note come "Surge Cycles". È importante notare che, qualunque sia la configurazione, ci sono sempre solo 2 nuovi partecipanti alle coinjoin Whirlpool.

Pertanto, le transazioni Whirlpool sono caratterizzate da un numero identico di ingressi e uscite, che possono essere :

5 ingressi e 5 uscite ;

6 ingressi e 6 uscite ;

7 ingressi e 7 uscite ;

8 ingressi e 8 uscite.

Il modello di Whirlpool si basa su piccole transazioni coinjoin. A differenza di Wabisabi e JoinMarket, dove la robustezza degli anonset si basa sul volume dei partecipanti a un singolo ciclo (o a pochi cicli), Whirlpool si basa sulla sequenza di diversi piccoli cicli.

In questo modello, gli utenti pagano le tasse solo quando si uniscono per la prima volta a un pool, consentendo loro di partecipare a una moltitudine di remix senza costi aggiuntivi. I nuovi utenti pagano le tariffe di estrazione dei remixer.

Con ogni coinjoin aggiuntivo a cui un pezzo partecipa, così come con i suoi pari incontrati in passato, gli anonset cresceranno esponenzialmente. L'obiettivo è sfruttare questi remix gratuiti che, ogni volta che si verificano, contribuiscono a rafforzare la densità degli anonset associati a ciascun pezzo mixato.

Whirlpool è stato progettato tenendo conto di due importanti requisiti:

L'accessibilità dell'implementazione sui dispositivi mobili, dato che Samourai Wallet è prima di tutto un'applicazione per smartphone;
Cicli di rimescolamento rapidi per promuovere un aumento significativo degli anonset.

Questi imperativi hanno guidato le scelte degli sviluppatori di Samourai Wallet nella progettazione di Whirlpool, portandoli a limitare i partecipanti a un numero limitato per ciclo. Un numero troppo basso avrebbe compromesso l'efficienza delle coinjoin, riducendo drasticamente gli anonset generati per ciclo, mentre un numero eccessivo avrebbe posto problemi di gestione sulle applicazioni mobili e ostacolato il flusso del ciclo.

Infine, su Whirlpool non è necessario avere un numero elevato di partecipanti per coinjoin, poiché gli anonset vengono effettuati sull'accumulo di diversi cicli di coinjoin. Il principio più importante è l'omogeneità degli UTXO di tutti i partecipanti, che garantisce una perfetta miscelazione e quindi il pieno beneficio dei cicli di miscelazione e rimescolamento.

Piscine e tariffe Coinjoin

Affinché questi cicli multipli aumentino gli anonset delle parti miste, è necessario un certo quadro per limitare le quantità di UTXO utilizzate. Whirlpool definisce diversi pool.

Un pool rappresenta un gruppo di utenti che desiderano mescolarsi tra loro e che si accordano sulla quantità di UTXO da utilizzare per ottimizzare il processo di coinjoin mantenendo una perfetta omogeneità dei pezzi. Ogni pool specifica una quantità fissa di UTXO, che l'utente deve rispettare per poter partecipare. Quindi, per effettuare coinjoin con Whirlpool, è necessario selezionare un pool. Attualmente sono disponibili i seguenti pool:

0.5 bitcoin ;
0.05 bitcoin ;
0.01 bitcoin ;
0.001 bitcoin (= 100.000 sats).

Quando si entra in una pool con i propri bitcoin, questi vengono suddivisi per generare UTXO perfettamente omogenei con quelli degli altri partecipanti alla pool. Ogni pool ha un limite massimo, quindi per importi superiori a questo limite, dovrete effettuare due ingressi separati nello stesso pool, oppure passare a un altro pool con un importo superiore:

| Pool (bitcoin) | Importo massimo per iscrizione (bitcoin)

|----------------|--------------------------------------|

| 0,5 | 35 |

| 0,05 | 3,5 |

| 0,01 | 0,7 |

| 0,001 | 0,025 |

Un UTXO è considerato appartenente a un pool quando è pronto per essere integrato in una coinjoin. Tuttavia, questo non significa che l'utente ne perda il possesso. Come abbiamo visto nei primi capitoli di questa sezione, attraverso i vari cicli di miscelazione, l'utente mantiene il pieno controllo delle proprie chiavi e, di conseguenza, dei propri bitcoin. Questo è ciò che differenzia la tecnica coinjoin da altre tecniche di miscelazione centralizzate.

Per entrare a far parte di un pool di coinjoin, è necessario pagare una quota di servizio e una quota di estrazione. Le quote di servizio sono fisse per ogni pool e sono destinate a remunerare i team responsabili dello sviluppo e della manutenzione di Whirlpool.

La quota di servizio per l'utilizzo di Whirlpool deve essere pagata una sola volta al momento dell'iscrizione alla piscina. Una volta iscritti, è possibile partecipare a un numero illimitato di remix senza alcun costo aggiuntivo. Ecco le tariffe fisse attuali per ogni pool:

| Pool (bitcoin) | Quota di iscrizione (bitcoin) |

|----------------|---------------------------------|

| 0,5 | 0,0175 |

| 0,05 | 0,00175 |

| 0,01 | 0,0005 (50.000 saturazioni) |

| 0,001 | 0,00005 (5.000 saturazioni) |

Queste commissioni fungono essenzialmente da biglietto d'ingresso al pool prescelto, indipendentemente dall'importo versato in coinjoin. Quindi, sia che si entri nel pool 0,01 con esattamente 0,01 BTC o 0,5 BTC, le commissioni rimarranno le stesse in termini assoluti.

Prima di procedere con i coinjoin Whirlpool, l'utente può scegliere tra due strategie:

Opta per un pool più piccolo per ridurre al minimo i costi di servizio, sapendo che in cambio otterrà diversi UTXO più piccoli;
Oppure optare per un pool più ampio, disposto a pagare commissioni più elevate, solo per ritrovarsi con un numero inferiore di UTXO di valore superiore.

In genere non è consigliabile unire più UTXO misti dopo i cicli di coinjoin, poiché ciò potrebbe compromettere la riservatezza acquisita, in particolare a causa dell'euristica della proprietà comune degli input (CIOH: Common-Input-Ownership-Heuristic). Di conseguenza, potrebbe essere opportuno scegliere un pool più grande, anche se ciò significa pagare di più, per evitare di avere troppi UTXO di piccolo valore in uscita. L'utente deve valutare questi compromessi per scegliere il pool che preferisce.

Oltre alla commissione per il servizio, è necessario tenere conto anche della commissione di mining specifica per ogni transazione Bitcoin. L'utente di Whirlpool dovrà pagare la commissione di mining per la transazione di preparazione (Tx0) e per il primo coinjoin. Tutti i remix successivi saranno gratuiti, grazie al modello di Whirlpool basato sul pagamento dei nuovi iscritti.

Infatti, in ogni coinjoin di Whirlpool, 2 utenti tra gli input sono nuovi entranti. Gli altri input provengono da remixer. Di conseguenza, i costi di estrazione per tutti i partecipanti alla transazione sono sostenuti da questi due nuovi entranti, che possono quindi beneficiare di remix gratuiti:

Grazie a questo sistema di commissioni, Whirlpool si distingue dalle altre implementazioni di coinjoin, poiché gli anonset degli UTXO non sono proporzionali al prezzo pagato dall'utente. Di conseguenza, è possibile ottenere livelli di anonimato notevolmente più elevati pagando solo la quota di ingresso al pool e la quota di mining per 2 transazioni (il Tx0 e la miscela iniziale).

È importante notare che l'utente dovrà anche pagare le tasse di estrazione per ritirare i suoi UTXO dal pool dopo aver completato i suoi coinjoin multipli, a meno che non abbia selezionato l'opzione "mix to", che fornisce un indirizzo esterno che riceverà i fondi direttamente da coinjoin, senza alcuna transazione aggiuntiva.

Conti di portafoglio HD

Per creare un coinjoin tramite Whirlpool, il portafoglio deve generare diversi conti separati. Questo è il principio alla base del protocollo ZeroLink. Un conto, nel contesto di un portafoglio HD (Hierarchical Deterministic), costituisce una sezione completamente isolata dalle altre; questa separazione avviene al livello della terza profondità della gerarchia del portafoglio, cioè al livello xpub.

Un portafoglio HD può teoricamente derivare fino a 2^(31) conti diversi. Il conto iniziale, utilizzato per impostazione predefinita in tutti i portafogli Bitcoin, corrisponde all'indice 0'.

Per i portafogli adattati a Whirlpool, vengono utilizzati 4 conti per soddisfare le esigenze del processo ZeroLink:

Il conto deposito, identificato dall'indice 0' ;
Il conto della cattiva banca (o "cambio doxxico"), identificato dall'indice 2.147.483.644' ;
Il conto premix, identificato dall'indice 2 147 483 645' ;
Il conto postmix, identificato dall'indice 2 147 483 646'.

Ognuno di questi conti svolge una funzione particolare nel processo di coinjoin, che analizzeremo nelle sezioni seguenti.

Tutti questi conti sono collegati a un unico seed, che consente all'utente di recuperare l'accesso a tutti i suoi bitcoin utilizzando la sua frase di recupero e, se del caso, la sua passphrase. Durante l'operazione di recupero, tuttavia, il software deve essere informato dei vari indici dei conti utilizzati.

Vediamo le diverse fasi di un coinjoin Whirlpool all'interno di questi conti.

Il TX0

Il punto di partenza di ogni coinjoin Whirlpool è il conto deposito. Si tratta del conto che viene utilizzato automaticamente quando si crea un nuovo portafoglio Bitcoin. Questo conto dovrà essere accreditato con i bitcoin che si desidera miscelare.

Tx0" è la prima fase del processo di miscelazione di Whirlpool. Il suo scopo è quello di preparare e uniformare gli UTXO per il coinjoin, dividendoli in unità corrispondenti alla quantità del pool selezionato, per garantire una miscelazione omogenea. Le UTXO così equalizzate vengono poi inviate al conto premix. La differenza che non può entrare nel pool viene separata in un conto specifico: il bad bank (o "doxxic change").

Questa transazione iniziale Tx0 viene utilizzata anche per pagare la quota di servizio dovuta al coordinatore di coinjoin. A differenza delle fasi successive, questa transazione non è collaborativa, quindi l'utente deve sostenere l'intero costo del mining:

In questo esempio di transazione Tx0, un ingresso di 372.000 sats dal nostro conto deposito viene suddiviso in diversi UTXO di uscita, che si suddividono come segue:

Un importo di 5.000 sats per il coordinatore per le spese di servizio, corrispondente all'ingresso nel pool di 100.000 sats;
3 UTXO preparati per la miscelazione, reindirizzati al nostro conto premix e registrati presso il coordinatore. Questi UTXO sono equiparati a 108.000 sats ciascuno, per coprire i costi di estrazione per la loro futura miscela iniziale;
L'eccedenza, che non può entrare nel pool perché troppo piccola, viene considerata come valuta estera tossica. Viene inviato al suo conto specifico. In questo caso, questo scambio ammonta a 40.000 sats;
Infine, rimangono 3.000 satelliti, che non costituiscono un output, ma sono i costi di estrazione necessari per confermare Tx0.

Ad esempio, ecco un vero Whirlpool Tx0 (non il mio): edef60744f539483d868caff49d4848e5cc6e805d6cdc8d0f9bdbbaedcb5fc46

Le alterazioni doxiche

L'eccedenza che non ha potuto essere integrata nel pool, qui equivalente a 40.000 sats, viene reindirizzata al conto della cattiva banca, noto anche come "scambio doxxico", per garantire una rigorosa separazione dagli altri UTXO in portafoglio.

Questo UTXO è pericoloso per la riservatezza dell'utente, perché non solo è ancora legato al suo passato, e quindi forse all'identità del suo proprietario, ma è anche notato come appartenente a un utente che ha effettuato una coinjoin.

Se questo UTXO viene unito a uscite miste, queste ultime perderanno tutta la riservatezza acquisita durante i cicli coinjoin, in particolare a causa del CIOH (Common-Input-Ownership-Heuristic). Se viene unito ad altre modifiche doxxiche, l'utente rischia di perdere la riservatezza, poiché collegherà le varie voci del ciclo coinjoin. Va quindi trattata con cautela. Approfondiremo la gestione di questi UTXO doxxic nell'ultima sezione di questo capitolo.

La miscela iniziale

Dopo Tx0, gli UTXO equalizzati vengono inviati al conto premix del nostro portafoglio, pronti per essere introdotti nel loro primo ciclo di coinjoin, noto anche come "mix iniziale". Se, come nel nostro esempio, il Tx0 genera diversi UTXO da miscelare, ciascuno di essi sarà integrato in un mix iniziale separato.

Al termine di questi primi mix, il conto premix sarà vuoto, mentre le nostre monete, avendo pagato le tariffe di mining per questo primo coinjoin, saranno adeguate esattamente all'importo definito dal pool scelto. Nel nostro esempio, i nostri UTXO iniziali di 108.000 sats saranno stati ridotti esattamente a 100.000 sats.

Remix

Dopo il mix iniziale, gli UTXO vengono trasferiti all'account postmix. Questo conto raccoglie gli UTXO già miscelati e quelli in attesa di essere rimescolati. Quando il cliente Whirlpool è attivo, gli UTXO che si trovano nel conto postmix sono automaticamente disponibili per i rimescolamenti e saranno selezionati a caso per partecipare a questi nuovi cicli.

Come promemoria, i remix sono gratuiti al 100%: non sono richiesti costi di servizio aggiuntivi o commissioni di estrazione. Mantenendo gli UTXO nel conto postmix si mantiene quindi intatto il loro valore e si migliora allo stesso tempo la loro anonset. Ecco perché è importante consentire a queste monete di partecipare a diversi cicli di coinjoin. Non vi costa assolutamente nulla e aumenta il loro livello di anonimato.

Quando si decide di spendere UTXO misti, lo si può fare direttamente da questo conto postmix. Si consiglia di mantenere gli UTXO misti in questo conto per beneficiare dei remix gratuiti e per evitare che escano dal circuito Whirlpool, il che potrebbe ridurne la riservatezza.

Come gestite i postmix?

Dopo aver eseguito cicli di coinjoin, la strategia migliore è quella di conservare gli UTXO nel conto postmix, in attesa di un utilizzo futuro. È persino consigliabile lasciarli rimescolare indefinitamente fino a quando non si ha bisogno di spenderli.

Alcuni utenti potrebbero pensare di trasferire i loro bitcoin misti in un portafoglio protetto da un hardware wallet. Questo è possibile, ma è importante seguire scrupolosamente le raccomandazioni di Samourai Wallet per non compromettere la riservatezza acquisita.

La fusione di UTXO è l'errore più comune. Per evitare il CIOH (Common-Input-Ownership-Heuristic), bisogna evitare di combinare UTXO misti con UTXO non misti nella stessa transazione. Ciò richiede un'attenta gestione degli UTXO all'interno del portafoglio, soprattutto in termini di etichettatura.

Occorre prestare attenzione anche al consolidamento di UTXO misti. Un consolidamento moderato è possibile se i vostri UTXO misti hanno anonset significativi, ma questo ridurrà inevitabilmente la riservatezza delle vostre parti. Assicuratevi che i consolidamenti non siano troppo estesi né eseguiti dopo un numero insufficiente di rimescolamenti, con il rischio di stabilire legami deducibili tra i vostri UTXO prima e dopo i cicli di coinjoin. In caso di dubbi su queste manipolazioni, la pratica migliore è quella di non consolidare gli UTXO post-miscelazione, ma di trasferirli uno per uno nel proprio portafoglio hardware, generando ogni volta un nuovo indirizzo vuoto. Ancora una volta, ricordate di etichettare ogni UTXO ricevuto.

È inoltre sconsigliabile trasferire i propri UTXO postmix in un portafoglio utilizzando script poco diffusi. Ad esempio, se si entra in Whirlpool da un portafoglio multisig utilizzando gli script P2WSH, ci sono poche possibilità di essere mescolati con altri utenti che originariamente avevano lo stesso tipo di portafoglio. Se si rimescolano i postmix in questo stesso portafoglio multisig, il livello di riservatezza dei bitcoin mescolati sarà notevolmente ridotto. Oltre agli script, ci sono molte altre impronte digitali di portafogli che possono giocare brutti scherzi.

Come per ogni transazione Bitcoin, è importante non riutilizzare l'indirizzo di ricezione. Ogni nuova transazione deve essere ricevuta su un nuovo indirizzo vuoto.

La soluzione più semplice e sicura è quella di lasciare gli UTXO misti a riposo nel loro conto postmix, lasciandoli rimescolare e toccandoli solo per spendere. I portafogli Samurai e Sparrow offrono protezioni aggiuntive contro tutti questi rischi di analisi della catena. Queste protezioni vi aiutano a non commettere errori.

Come si gestiscono gli scambi tossici?

Successivamente, dovrete prestare attenzione alla gestione dei doxxic exchange, gli scambi che non sono stati inseriti nel pool di coinjoin. Questi UTXO tossici, derivanti dall'uso di Whirlpool, rappresentano un rischio per la vostra privacy, poiché stabiliscono un legame tra voi e l'utente di coinjoin. È quindi indispensabile gestirli con cura e non combinarli con altri UTXO, soprattutto quelli misti.

Ecco alcune strategie per utilizzarli:

Miscelare in vasche più piccole:** Se l'UTXO tossico è abbastanza grande da poter essere inserito da solo in una vasca più piccola, si può pensare di miscelarlo. Questa è spesso l'opzione migliore. Tuttavia, non è consigliabile unire più UTXO tossici per accedere a una piscina, poiché ciò potrebbe collegare le diverse voci;
Contrassegnarli come "non spendibili":** Un altro approccio è quello di smettere di usarli, contrassegnarli come "non spendibili" nel loro conto dedicato e limitarsi ad hodl. In questo modo si evita di spenderli accidentalmente. Se il valore del bitcoin aumenta, potrebbero emergere nuovi pool più adatti ai vostri UTXO tossici;
Fare donazioni:** Considerate la possibilità di fare donazioni, per quanto modeste, agli sviluppatori che lavorano su Bitcoin e sul software correlato. Potete anche fare donazioni alle associazioni che accettano BTC. Se la gestione degli UTXO tossici sembra troppo complicata, potete semplicemente sbarazzarvene e fare una donazione;
Acquistare carte regalo:** Piattaforme come Bitrefill consentono di scambiare bitcoin con carte regalo che possono essere utilizzate presso vari commercianti. Questo può essere un modo per separarsi dai propri UTXO tossici senza perdere il valore associato;
Consolidarli su Monero:** Samourai Wallet offre un servizio di scambio atomico tra BTC e XMR. Questo è ideale per gestire gli UTXO tossici consolidandoli su Monero, senza compromettere la riservatezza tramite CIOH, prima di rimandarli in Bitcoin. Tuttavia, questa opzione può essere costosa in termini di commissioni di mining e di premio a causa dei vincoli di liquidità;
Trasferire questi UTXO alla rete Lightning: ** Trasferire questi UTXO alla rete Lightning per beneficiare di commissioni di transazione ridotte può essere un'opzione interessante. Tuttavia, questo metodo può rivelare alcune informazioni a seconda dell'uso che si fa di Lightning e deve quindi essere usato con cautela.

Come si usa Whirlpool?

In seguito all'arresto dei fondatori di Samourai Wallet e al sequestro dei loro server il 24 aprile 2024, lo strumento Whirlpool non funziona più, nemmeno per chi ha un proprio Dojo. In precedenza era disponibile su Samourai Wallet e Sparrow Wallet.

Resta comunque possibile che questo strumento venga riattivato nelle prossime settimane, a seconda dell'esito delle prove, o rilanciato in modo diverso. In ogni caso, non credo che il mercato dei coinjoin Bitcoin rimarrà a lungo senza offerta, perché la domanda c'è. Inoltre, poiché il modello di Whirlpool è il più avanzato in termini di riservatezza, sarà sicuramente il modello di scelta per altre implementazioni in futuro.

Stiamo tenendo d'occhio questo caso e gli sviluppi degli strumenti associati. Vi assicuriamo che aggiorneremo questo corso di formazione non appena saranno disponibili nuove informazioni.

Nel prossimo capitolo scopriremo cosa sono gli "anonset", come vengono calcolati questi indicatori e come possono aiutarci a stimare l'efficienza dei cicli coinjoin.

https://planb.network/tutorials/privacy/on-chain/coinjoin-sparrow-wallet-84def86d-faf5-4589-807a-83be60720c8b

https://planb.network/tutorials/privacy/on-chain/coinjoin-samourai-wallet-e566803d-ab3f-4d98-9136-5462009262ef

https://planb.network/tutorials/privacy/on-chain/coinjoin-dojo-c4b20263-5b30-4c74-ae59-dc8d0f8715c2

Set di anonimato

Dopo aver studiato come funzionano le coinjoin e i problemi legati a una miscelazione efficace, ora scopriremo come misurarne l'efficacia. Come possiamo determinare se un processo di coinjoining è stato efficace e quale grado di anonimato ha acquisito una parte? È quanto scopriremo in questo capitolo con gli insiemi di anonimato o "anonset".

Un promemoria dell'utilità di coinjoin

L'utilità di coinjoin risiede nella sua capacità di produrre una negazione plausibile, incorporando la propria parte in un gruppo di parti indistinguibili. L'obiettivo di questa azione è rompere i legami di tracciabilità, sia dal passato al presente che dal presente al passato.

In altre parole, un analista che conosce la transazione iniziale (Tx0) all'ingresso dei cicli coinjoin non dovrebbe essere in grado di identificare con certezza l'UTXO all'uscita dei cicli remix (analisi dell'ingresso nel ciclo e dell'uscita dal ciclo).

Al contrario, un analista che conosce il vostro UTXO all'uscita dei cicli coinjoin non può determinare la transazione originale all'entrata dei cicli (analisi dall'uscita del ciclo all'entrata del ciclo).

Per valutare quanto sia difficile per un analista collegare il passato al presente e viceversa, dobbiamo quantificare la dimensione dei gruppi di parti omogenee all'interno dei quali si nasconde la vostra parte. Questa misura ci dice quante analisi hanno la stessa probabilità. Quindi, se l'analisi corretta è annegata tra altre 3 analisi di uguale probabilità, il vostro livello di occultamento è molto basso. D'altra parte, se l'analisi corretta si trova all'interno di un insieme di 20.000 analisi ugualmente probabili, la vostra parte è molto ben nascosta. La dimensione di questi gruppi rappresenta degli indicatori noti come "anonset".

Comprendere gli anonset

Gli insiemi sono utilizzati come indicatori per valutare il grado di riservatezza di un particolare UTXO. Più precisamente, misurano il numero di UTXO indistinguibili all'interno dell'insieme che comprende la parte in esame. Il requisito di un insieme omogeneo di UTXO significa che gli anonset sono solitamente calcolati su cicli coinjoin. L'uso di questi indicatori è particolarmente rilevante per le coinjoint Whirlpool, a causa della loro uniformità.

Se necessario, gli anonset possono essere utilizzati per giudicare la qualità delle coinjoin. Un anonset ampio significa un alto livello di anonimato, poiché diventa difficile distinguere un UTXO specifico all'interno dell'insieme omogeneo.

esistono 2 tipi di anonset:

L'anonset prospettico ;**
Retrospettiva anonset.**

L'anonset prospettico

Il forward-looking anonset indica la dimensione del gruppo tra cui si nasconde l'UTXO studiato alla fine del ciclo, dato l'UTXO all'inizio, cioè il numero di parti indistinguibili presenti all'interno di questo gruppo. Il nome di questo indicatore è "metrica previsionale".

Questo indicatore misura la resistenza della riservatezza del locale a un'analisi dal passato al presente (input-to-output).

Questa metrica viene utilizzata per stimare la misura in cui l'UTXO è protetto dai tentativi di ricostruire la sua storia dal punto di ingresso al punto di uscita nel processo di coinjoin.

Ad esempio, se la transazione ha partecipato al suo primo ciclo di coinjoin e sono stati completati altri due cicli discendenti, l'anonset prospettico della moneta sarà 13:

Per esempio, immaginiamo che la nostra moneta all'inizio del ciclo di coinjoin abbia un anonset prospettico di 86.871. In termini pratici, ciò significa che è nascosta tra 86.871 parti indistinguibili. Per un osservatore esterno che conosca questa moneta all'inizio del ciclo di coinjoin e cerchi di tracciarne l'uscita, si troverà di fronte a 86.871 possibili UTXO, ognuno con una probabilità identica di essere la moneta che sta cercando.

L'anonset retrospettivo

L'anonset retrospettivo indica il numero di possibili fonti per un dato pezzo, conoscendo l'UTXO alla fine del ciclo. Questo indicatore misura la resistenza della riservatezza del pezzo a un'analisi dal presente al passato (dall'uscita all'ingresso), cioè quanto è difficile per un analista risalire all'origine del pezzo, prima dei cicli di coinjoin. Il nome di questo indicatore è "backward anonset" o "backward-looking metrics".

Conoscendo il vostro UTXO all'uscita dei cicli, l'anonset retrospettivo determina il numero di potenziali transazioni Tx0 che avrebbero potuto costituire il vostro ingresso nei cicli coinjoin. Nel diagramma sottostante, ciò corrisponde alla somma di tutte le bolle arancioni.

Ad esempio, immaginiamo che la nostra parte coinjoin abbia un anonset retrospettivo di 42.185. In termini pratici, ciò significa che ci sono 42.185 potenziali fonti per questo UTXO. Se un osservatore esterno identifica questa moneta alla fine dei cicli e cerca di risalire alla sua origine, si troverà di fronte a 42.185 possibili fonti, tutte con uguale probabilità di essere l'origine cercata.

Come si calcolano gli anonset?

È possibile calcolare manualmente gli anonset utilizzando un block explorer per piccoli ensemble. Tuttavia, per anonset più grandi, diventa indispensabile l'uso di uno strumento specializzato. Per quanto ne so, l'unico software in grado di svolgere questo compito è Whirlpool Stats Tool, uno strumento in Python sviluppato dai team di Samourai e OXT. Purtroppo, questo strumento è attualmente fuori servizio in seguito all'arresto dei fondatori di Samourai e all'interruzione di OXT, che veniva utilizzato per estrarre i dati dalla blockchain.

Come abbiamo visto in questo capitolo, gli anonset possono essere calcolati solo se esiste una certa omogeneità nella struttura della coinjoin. Nel prossimo capitolo scopriremo come quantificare questa omogeneità su una transazione Bitcoin, sia essa una coinjoin o una transazione più tradizionale.

https://planb.network/tutorials/privacy/analysis/wst-anonsets-0354b793-c301-48af-af75-f87569756375

Entropia

Come abbiamo visto in questa sezione sulle coinjoin, l'omogeneità degli UTXO in ingresso e in uscita svolge un ruolo importante nel migliorare la riservatezza di una transazione Bitcoin. Questo parametro crea una plausibile negabilità di fronte all'analisi della blockchain. Per misurare questa omogeneità si possono utilizzare diversi metodi, ma uno dei più efficaci, a mio avviso, è l'utilizzo degli indicatori forniti dallo strumento Boltzmann, sviluppato dai team di OXT e Samourai Wallet, e in particolare l'entropia della transazione. È questo l'aspetto che analizzeremo in dettaglio in questo capitolo.

A differenza degli anonset, che sono calcolati su un insieme di transazioni, gli indicatori qui presentati si concentrano su una singola transazione, sia essa una coinjoin o una transazione più tradizionale.

Il numero di interpretazioni

Il primo indicatore che si può osservare su una transazione Bitcoin è il numero totale di interpretazioni possibili di fronte all'analisi di un osservatore esterno. Tenendo conto dei valori degli UTXO coinvolti nella transazione, questo indicatore mostra il numero di modi in cui gli input possono essere associati agli output. In altre parole, determina il numero di possibili interpretazioni che una transazione può suscitare nei flussi di bitcoin dal punto di vista di un osservatore esterno che la analizza.

Ad esempio, una semplice transazione di pagamento con 1 ingresso e 2 uscite avrà una sola interpretazione, ovvero che l'ingresso #0 ha finanziato l'uscita #0 e l'uscita #1. Non ci sono altre interpretazioni possibili:

D'altra parte, un angolo Whirlpool 5x5 ha 1.496$ combinazioni possibili:

Un ciclo di sovratensione Whirlpool 8x8 ha 9.934.563 $ di possibili interpretazioni:

Entropia

Dal numero di interpretazioni di una transazione Bitcoin, possiamo calcolare la sua entropia.

Nel contesto generale della crittografia e dell'informazione, l'entropia è una misura quantitativa dell'incertezza o dell'imprevedibilità associata a una fonte di dati o a un processo casuale. In altre parole, l'entropia è un modo per misurare quanto sia difficile prevedere o indovinare un'informazione.

Nel contesto specifico dell'analisi della blockchain, l'entropia è anche il nome di un indicatore, derivato dall'entropia di Shannon e inventato da LaurentMT, che può essere calcolato su una transazione Bitcoin.

Quando una transazione presenta un gran numero di possibili interpretazioni, è spesso più rilevante fare riferimento alla sua entropia. Questo indicatore misura la mancanza di conoscenza da parte degli analisti dell'esatta configurazione della transazione. In altre parole, più alta è l'entropia, più difficile diventa per gli analisti identificare il flusso di bitcoin tra ingressi e uscite.

In pratica, l'entropia rivela se, dal punto di vista di un osservatore esterno, una transazione presenta molteplici interpretazioni possibili, basate esclusivamente sulle quantità di input e output, senza tenere conto di altri modelli ed euristiche esterne o interne. Un'entropia elevata è quindi sinonimo di maggiore riservatezza della transazione.

L'entropia è definita come il logaritmo binario del numero di combinazioni possibili. Ecco la formula utilizzata con $E$ l'entropia della transazione e $C$ il numero di interpretazioni possibili:

 $E = \log_2(C)$

In matematica, il logaritmo binario (logaritmo in base 2) è l'operazione inversa dell'esponenziazione di 2. In altre parole, il logaritmo binario di $x$ è l'esponente a cui bisogna elevare $2$ per ottenere $x$ . Questo indicatore è quindi espresso in bit.

Prendiamo l'esempio del calcolo dell'entropia per una transazione coinjoin strutturata secondo il modello Whirlpool 5x5, che, come detto nella sezione precedente, ha un numero di interpretazioni possibili pari a $1\,496$ :

 $\begin{align*} C &= 1\,496 \\ E &= \log_2(1\,496) \\ E &= 10.5469 \text{ bits} \end{align*}$

Pertanto, questa transazione coinjoin ha un'entropia di 10,5469 $ bit, che è considerata molto soddisfacente. Più alto è questo valore, più diverse interpretazioni ammette la transazione, rafforzando così il suo livello di riservatezza.

Per una transazione coinjoin 8x8 con 9.934.563$ interpretazioni, l'entropia sarebbe :

 $\begin{align*} C &= 9\,934\,563 \\ E &= \log_2(9\,934\,563) \\ E &= 23.244 \text{ bits} \end{align*}$

Facciamo un altro esempio con una transazione di pagamento classica, con 1 ingresso e 2 uscite: 1b1b0c3f0883a99f1161c64da19471841ed12a1f78e77fab128c69a5f578ccce

Nel caso di questa transazione, l'unica interpretazione possibile è: (In.0) > (Out.0 ; Out.1). Di conseguenza, la sua entropia è pari a $0$ :

 $\begin{align*} C &= 1 \\ E &= \log_2(1) \\ E &= 0 \text{ bits} \end{align*}$

Efficienza

Sulla base dell'entropia della transazione, possiamo anche calcolarne l'efficienza in termini di riservatezza. Questo indicatore valuta l'efficienza della transazione confrontandola con la transazione ottimale che potrebbe essere prevista in una configurazione identica.

Questo ci porta al concetto di massima entropia, che corrisponde alla massima entropia che una specifica struttura di transazione può teoricamente raggiungere. L'efficienza della transazione viene quindi calcolata confrontando questa entropia massima con l'entropia effettiva della transazione in esame.

La formula utilizzata è la seguente con :

e_R$: l'entropia effettiva della transazione espressa in bit;
e_M$: la massima entropia possibile per una struttura di transazione, anch'essa espressa in bit;
$Ef$ : efficienza della transazione in bit :

 $Ef = E_R - E_M$

Ad esempio, per una struttura Whirlpool 5x5 coinjoin, l'entropia massima è di $10,5469$ :

 $\begin{align*} E_R &= 10.5469 \\ E_M &= 10.5469 \\ Ef &= E_R - E_M \\ Ef &= 10.5469 - 10.5469 \\ Ef &= 0 \text{ bits} \end{align*}$

Anche questo indicatore è espresso in percentuale. La formula utilizzata è la seguente: :

c_R$ : il numero di possibili interpretazioni reali ;
c_M$: il numero massimo di interpretazioni possibili della stessa struttura;
$Ef$ : efficienza espressa in percentuale:

 $\begin{align*} E_f &= \frac{C_R}{C_M} \\ E_f &= \frac{1\,496}{1\,496} \\ E_f &= 100 \% \end{align*}$

Un'efficienza di 100 dollari indica che la transazione sta sfruttando al massimo il suo potenziale di riservatezza, a seconda della sua struttura.

Densità di entropia

L'entropia è un buon indicatore per misurare la riservatezza di una transazione, ma dipende in parte dal numero di input e output della transazione. Per confrontare l'entropia di due transazioni diverse con un numero diverso di ingressi e uscite, possiamo calcolare la densità di entropia. Questo indicatore fornisce una prospettiva sull'entropia relativa a ciascun ingresso o uscita della transazione. La densità è utile per valutare e confrontare l'efficienza di transazioni di dimensioni diverse.

Per calcolarla, basta dividere l'entropia totale della transazione per il numero totale di ingressi e uscite coinvolti nella transazione:

e_D$: densità di entropia espressa in bit;
e$: l'entropia della transazione espressa in bit;
t$: numero totale di ingressi e uscite nella transazione:

 $E_D = \frac{E}{T}$

Prendiamo l'esempio di un coinjoin Whirlpool 5x5:

 $\begin{align*} T &= 5 + 5 = 10 \\ E &= 10.5469 \\ E_D &= \frac{E}{T} \\ E_D &= \frac{10.5469}{10} \\ E_D &= 1.054 \text{ bits} \end{align*}$

Calcoliamo anche la densità di entropia di un coinjoin Whirlpool 8x8:

 $\begin{align*} T &= 8 + 8 = 16 \\ E &= 23.244 \\ E_D &= \frac{E}{T} \\ E_D &= \frac{23.244}{16} \\ E_D &= 1.453 \text{ bits} \end{align*}$

Analizzando la densità di entropia di questi due tipi di coinjoin, risulta chiaro che, anche normalizzando l'entropia in base al numero di elementi, il coinjoin "Surge Cycle 8x8" genera maggiore incertezza per l'analisi.

Il punteggio di Boltzmann

Un'altra informazione analizzata in una transazione è il punteggio di Boltzmann di ciascun elemento rispetto a un altro. Si tratta della tabella delle probabilità di corrispondenza tra input e output. Questa tabella indica, attraverso il punteggio di Boltzmann, la probabilità condizionata che uno specifico input sia collegato a un determinato output. Si tratta quindi di una misura quantitativa della probabilità condizionata che si verifichi un'associazione tra un input e un output in una transazione, basata sul rapporto tra il numero di occorrenze favorevoli di questo evento e il numero totale di occorrenze possibili, in un insieme di interpretazioni.

Utilizzando l'esempio di una coinjoin Whirlpool, la tabella delle probabilità condizionali evidenzierebbe le probabilità di un collegamento tra ciascun input e output, offrendo una misura quantitativa dell'ambiguità delle associazioni nella transazione:

| ------- | -------- | -------- | -------- | -------- | -------- |

ingresso 0 | 34% | 34% | 34% | 34% | 34% | 34% | 34% |

| Ingresso 1 | 34% | 34% | 34% | 34% | 34% | 34% | 34% | Ingresso 1

| Ingresso 2 | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34

| Ingresso 3 | 34% | 34% | 34% | 34% | 34% | 34% | 34% | Ingresso 3

| Ingresso 4 | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34% | 34

Chiaramente, ogni input ha la stessa possibilità di essere associato a qualsiasi output, il che rafforza la riservatezza della transazione.

Il punteggio di Boltzmann si calcola dividendo il numero di interpretazioni in cui si verifica un certo evento per il numero totale di interpretazioni disponibili. Quindi, per determinare il punteggio che associa l'ingresso #0 all'uscita #3 (evento presente in $512$ interpretazioni), si procede come segue:

 $\begin{align*} \text{Interpretations (IN.0 > OUT.3)} &= 512 \\ \text{Interpretations totales} &= 1496 \\ \text{Score} &= \frac{512}{1496} \\ \text{Score} &= 34 \% \end{align*}$

Se prendiamo l'esempio di un coinjoin del ciclo di sovralimentazione Whirlpool 8x8, la tabella di Boltzmann avrebbe il seguente aspetto:

| OUT.0 | OUT.1 | OUT.2 | OUT.3 | OUT.4 | OUT.5 | OUT.6 | OUT.7 |

|-------|-------|-------|-------|-------|-------|-------|-------|-------|

iN.0 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

iN.1 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

iN.2 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

iN.3 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

iN.4 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

iN.5 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

iN.6 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

iN.7 | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% | 23% |

Tuttavia, nel caso di una semplice transazione con un singolo ingresso e 2 uscite, la situazione è diversa:

| Uscita 0 | Uscita 1 |

|---------|----------|----------|

ingresso 0 | 100% | 100% | 100% |

In questo caso, vediamo che la probabilità che ogni output provenga dall'input #0 è del 100%. Una probabilità più bassa riflette quindi una maggiore riservatezza, diluendo i legami diretti tra input e output.

Collegamenti deterministici

Possiamo anche calcolare il numero di collegamenti deterministici in una transazione. Questo indicatore rivela quante connessioni tra ingressi e uscite nella transazione analizzata sono indiscutibili, con una probabilità del 100%. Questo indicatore può essere completato calcolando il rapporto tra i collegamenti deterministici. Il rapporto fornisce una prospettiva sul peso di questi collegamenti deterministici all'interno dei collegamenti totali della transazione.

Ad esempio, una transazione di coinjoin Whirlpool non ha legami deterministici tra ingressi e uscite, e quindi mostra un indicatore di 0 legami e un rapporto dello 0%. Al contrario, nella seconda transazione di pagamento semplice esaminata (con un ingresso e 2 uscite), l'indicatore ci dice che ci sono 2 collegamenti deterministici e il rapporto raggiunge il 100%. In altre parole, un indicatore pari a zero indica un'ottima riservatezza, grazie all'assenza di legami diretti e indiscutibili tra input e output.

Come si calcolano questi indicatori?

Calcolare manualmente questi indicatori utilizzando le equazioni che ho fornito è relativamente semplice. La difficoltà sta soprattutto nel determinare il numero di possibili interpretazioni di una transazione. Per una transazione classica, questo calcolo può essere fatto a mano. Per una coinjoin, invece, il compito è molto più complesso.

In precedenza, esisteva uno strumento Python chiamato Boltzmann Calculator, sviluppato dai team OXT e Samourai, che calcolava automaticamente tutti questi indicatori per una transazione Bitcoin:

Per queste analisi è stato possibile utilizzare anche il sito web KYCP.org:

Purtroppo, dopo l'arresto dei fondatori di Samourai, questi strumenti non sono più operativi.

Dopo aver trattato in dettaglio le coinjoin, nella sezione finale del corso esamineremo le altre tecniche di privacy disponibili su Bitcoin. Analizzeremo le payjoin, i tipi specifici di transazioni pseudo-coinjoin, i protocolli di indirizzi statici e le misure per rafforzare la riservatezza non a livello delle transazioni stesse, ma a livello della rete di nodi.

https://planb.network/tutorials/privacy/analysis/boltzmann-entropy-738e45af-18a6-4ce6-af1a-1bf58e15f1fe

Comprendere le sfide di altre tecniche avanzate di confidenzialità

Transazioni Payjoin

Coinjoin è attualmente il metodo più efficace per introdurre l'incertezza nel tracciamento delle parti in un'analisi di catena. Come abbiamo visto nei capitoli precedenti, per ottenere un mix ad alte prestazioni, gli input e gli output devono essere il più possibile omogenei. Inoltre, è importante che le parti siano integrate in un gruppo il più ampio possibile per massimizzare gli insiemi. Quindi, per essere efficaci, i coinjoin devono coinvolgere un gran numero di parti uniformi. Questa moltitudine di requisiti significa che le transazioni coinjoin hanno una struttura molto rigida: gli importi sono fissati in anticipo e tutti i partecipanti devono rispettarli per garantire l'uniformità del processo. Inoltre, le coinjoin richiedono la sincronizzazione tra tutti i partecipanti e il coordinatore durante la costruzione della transazione.

Questi requisiti rendono coinjoin inadatto ai pagamenti diretti. Ad esempio, se si dispone di una moneta da 1 milione di sats in un pool di coinjoin, utilizzarla direttamente come pagamento sarebbe complesso. Sarebbe necessario sincronizzarsi con gli altri partecipanti e con il coordinatore per costruire la transazione collaborativa proprio nel momento in cui si ha bisogno di effettuare un pagamento, e l'importo dell'acquisto dovrebbe corrispondere esattamente al valore della propria moneta, il che è praticamente irrealizzabile. La transazione coinjoin è quindi per sua natura una transazione collaborativa a tappeto, cioè di solito sono gli stessi proprietari degli input che troviamo negli output.

Tuttavia, sarebbe interessante disporre di strutture di transazione che permettano di effettuare pagamenti in modo pratico, introducendo allo stesso tempo il dubbio nell'analisi della catena. È proprio questo l'obiettivo di questo e del prossimo capitolo.

Cos'è una transazione payjoin?

Il payjoin è una struttura di transazione Bitcoin specifica che migliora la privacy dell'utente quando spende collaborando con il destinatario del pagamento.

Nel 2015 LaurentMT parlò per la prima volta di questo metodo con il nome di "steganographic transactions", secondo un documento disponibile qui. Questa tecnica fu successivamente adottata dal wallet Samourai, che nel 2018 fu il primo client a implementarla tramite lo strumento Stowaway. Il concetto di payjoin si ritrova anche nei BIP79, BIP78 e BIP77. Diversi termini vengono usati per designare un payjoin:

Payjoin ;
Viaggiatore clandestino;
P2EP (Pay-to-End-Point) ;
Transazione steganografica.

La particolarità di payjoin sta nella sua capacità di generare una transazione che a prima vista sembra ordinaria, ma che in realtà è una mini Coinjoin tra due persone. Per ottenere questo risultato, la struttura della transazione coinvolge il destinatario del pagamento negli input accanto al mittente effettivo. Il destinatario include quindi un pagamento a se stesso nel mezzo della transazione che gli consente di essere pagato.

Facciamo un esempio per capire meglio questo processo. Alice acquista una baguette per 4.000 sats utilizzando un UTXO di 10.000 sats e opta per un payjoin. Il suo panettiere, Bob, aggiunge come input un UTXO di 15.000 sats di sua proprietà, che recupera interamente come output, oltre ai 4.000 sats di Alice.

In questo esempio, il panettiere Bob immette 15.000 sats in input e ne esce con 19.000 sats, con una differenza di esattamente 4.000 sats, ovvero il prezzo della baguette. Dal canto suo, Alice immette 10.000 sati e ne ottiene 6.000 in uscita, il che rappresenta un saldo di -4.000 sati, cioè il prezzo della baguette. Per semplificare l'esempio, ho deliberatamente omesso i costi di estrazione in questa transazione.

A cosa serve il payjoin?

La transazione payjoin soddisfa due obiettivi, consentendo agli utenti di migliorare la riservatezza del loro pagamento.

In primo luogo, payjoin mira a ingannare un osservatore esterno creando un'esca nell'analisi della catena. Ciò è reso possibile dall'euristica CIOH (Common Input Ownership Heuristic). Come abbiamo visto nella parte 3, di solito, quando una transazione sulla blockchain ha diversi input, si presume che tutti questi input appartengano alla stessa entità o utente.

Pertanto, quando un analista esamina una transazione payjoin, è portato a credere che tutti gli input provengano dalla stessa persona. Tuttavia, questa percezione è errata, perché anche il beneficiario contribuisce agli input insieme al pagatore effettivo. L'analisi della catena viene quindi deviata verso un'interpretazione che si rivela errata.

Prendiamo l'esempio di una transazione payjoin per il pagamento di una baguette:

Vedendo questa transazione sulla blockchain, un osservatore esterno che seguisse le consuete euristiche di analisi della blockchain darebbe la seguente interpretazione: "Alice ha unito 2 UTXO come input della transazione per pagare 19.000 sats a Bob".

Questa interpretazione è ovviamente errata, perché, come già sapete, i due UTXO in ingresso non appartengono alla stessa persona. Uno proviene da Alice, l'acquirente di baguette, e l'altro da Bob, il panettiere.

In questo modo, l'analisi dell'osservatore esterno viene indirizzata verso una conclusione errata, garantendo la riservatezza degli stakeholder.

La transazione steganografica

Il secondo scopo di payjoin è quello di ingannare un osservatore esterno sull'importo effettivo del pagamento effettuato. Esaminando la struttura della transazione, l'analista potrebbe credere che il pagamento sia equivalente all'importo di una delle uscite.

Se torniamo all'esempio dell'acquisto di una baguette, l'analista penserà che l'importo del pagamento corrisponda o all'UTXO di 6.000 satt, o all'UTXO di 19.000 satt. In questo caso, l'analista penserà piuttosto che l'importo del pagamento sia di 19.000 sats, perché ci sono 2 UTXO in uscita, di cui almeno uno è maggiore di 6.000 sats (non c'è alcuna ragione logica per usare 2 UTXO per pagare 6.000 sats quando un solo UTXO sarebbe stato sufficiente per soddisfare questo pagamento).

In realtà, però, questa analisi è errata. L'importo del pagamento non corrisponde a nessuno degli output. È infatti la differenza tra l'UTXO del beneficiario in uscita e l'UTXO del beneficiario in entrata.

In questo senso, la transazione payjoin rientra nel campo della steganografia. Essa consente di nascondere l'importo reale di una transazione all'interno di una transazione fittizia che funge da esca.

La steganografia è una tecnica per nascondere informazioni all'interno di altri dati o oggetti, in modo che la presenza dell'informazione nascosta non sia percepibile. Ad esempio, un messaggio segreto può essere nascosto all'interno di un punto in un testo non correlato, rendendolo impercettibile a occhio nudo (questa è la tecnica del microdot).

A differenza della crittografia, che rende le informazioni incomprensibili senza la chiave di decrittazione, la steganografia non modifica le informazioni. Queste rimangono visualizzate in chiaro. Il suo scopo è piuttosto quello di nascondere l'esistenza stessa del messaggio segreto, mentre la crittografia rivela chiaramente la presenza di informazioni nascoste, anche se inaccessibili senza la chiave. Per questo motivo il nome originale di payjoin era "transazioni steganografiche".

È possibile tracciare un'analogia tra crittografia e coinjoin e tra steganografia e payjoin. La coinjoin ha caratteristiche simili alla crittografia: il metodo è riconoscibile, ma le informazioni sono indecifrabili. Al contrario, il payjoin è simile alla steganografia: le informazioni sono teoricamente accessibili, ma poiché il metodo di occultamento non è riconoscibile, diventano inaccessibili.

Come si usa payjoin?

I programmi software più noti che supportano payjoin includono Sparrow Wallet, Wasabi Wallet, Mutiny, BitMask, BlueWallet e JoinMarket, oltre al processore di pagamento BTCPay.

L'implementazione più avanzata di payjoin era solo Stowaway su Samourai Wallet. Tuttavia, dopo l'arresto dei fondatori del software, questo strumento è ora solo parzialmente funzionante. Il vantaggio di Stowaway è che si tratta di un protocollo completo e facile da usare, che supporta sia la ricezione che l'invio di payjoin. Le transazioni parzialmente firmate possono essere scambiate manualmente tramite la scansione di diversi codici QR, oppure automaticamente tramite Tor via Soroban. Quest'ultima opzione di comunicazione è attualmente fuori servizio.

La difficoltà nell'utilizzo di payjoin risiede nella sua dipendenza dalla partecipazione dell'esercente. Il cliente non può utilizzare payjoin se il commerciante non lo supporta. Questo aggiunge un'ulteriore difficoltà al processo di acquisto: non solo è difficile trovare commercianti che accettano bitcoin, ma se si cercano anche quelli che supportano payjoin, la cosa diventa ancora più complicata.

Una soluzione potrebbe essere quella di utilizzare strutture di transazione che introducano ambiguità nell'analisi della catena senza richiedere la cooperazione del destinatario. Questo ci permetterebbe di migliorare la riservatezza dei nostri pagamenti senza dipendere dalla partecipazione attiva dei commercianti. Questo è esattamente ciò che vedremo nel prossimo capitolo.

https://planb.network/tutorials/privacy/on-chain/payjoin-sparrow-wallet-087a0e49-61cd-41f5-8440-ac7b157bdd62

https://planb.network/tutorials/privacy/on-chain/payjoin-samourai-wallet-48a5c711-ee3d-44db-b812-c55913080eab

Pagamento mini-coinjoin

Quando si vuole effettuare una transazione di pagamento mantenendo un certo grado di riservatezza, payjoin è una buona opzione. Ma come abbiamo appena visto, payjoin richiede il coinvolgimento del destinatario. Cosa fare quindi se il destinatario si rifiuta di partecipare a una payjoin, o se semplicemente si preferisce non coinvolgerlo? Un'alternativa è quella di utilizzare una transazione Stonewall o Stonewall x2. Diamo un'occhiata più da vicino a questi due tipi di transazione.

La transazione Stonewall

Stonewall è una forma specifica di transazione Bitcoin progettata per aumentare la riservatezza dell'utente quando spende, imitando una pseudo-coinjoin tra due persone, senza esserlo realmente. In realtà, questa transazione non è collaborativa. Un utente può costruirla da solo, utilizzando come input solo gli UTXO che possiede. È quindi possibile creare una transazione Stonewall per qualsiasi occasione, senza bisogno di sincronizzarsi con un altro utente o con il destinatario.

La transazione Stonewall funziona come segue: come input della transazione, l'emittente utilizza 2 UTXO che gli appartengono. In uscita, la transazione produce 4 UTXO, di cui 2 esattamente dello stesso importo. Gli altri 2 UTXO costituiranno valuta estera. Delle due uscite dello stesso importo, solo una andrà effettivamente al beneficiario.

Quindi ci sono solo 2 ruoli in una transazione Stonewall:

L'emittente, che effettua il pagamento ;
Il destinatario, che potrebbe non essere a conoscenza della natura specifica della transazione e si aspetta semplicemente il pagamento da parte del mittente.

Facciamo un esempio per capire questa struttura di transazione. Alice va da Bob, il panettiere, per comprare la sua baguette, che costa 4.000 sats. Vuole pagare in bitcoin, mantenendo una forma di riservatezza sul pagamento. Decide quindi di creare una transazione Stonewall per il pagamento.

Analizzando questa transazione, possiamo vedere che Bob il panettiere ha effettivamente ricevuto 4.000 sats come pagamento per la baguette. Alice ha utilizzato 2 UTXO come input: uno per 10.000 sats e uno per 15.000 sats. In uscita, ha recuperato 3 UTXO: uno per 4.000 sats, uno per 6.000 sats e uno per 11.000 sats. Alice ha quindi un saldo netto di -4.000 sats su questa transazione, che corrisponde al prezzo della baguette.

In questo esempio, ho intenzionalmente trascurato le commissioni di estrazione per rendere più facile la comprensione. In realtà, i costi di transazione sono interamente a carico dell'emittente.

Quali sono gli obiettivi di una transazione Stonewall?

La struttura Stonewall aggiunge un'enorme quantità di entropia alla transazione, confondendo le linee di analisi della catena. Vista dall'esterno, una transazione di questo tipo potrebbe essere interpretata come una mini-coinjoin tra due persone. Ma in realtà si tratta di un pagamento. Questo metodo crea quindi incertezze nell'analisi della catena, o addirittura porta a false piste.

Prendiamo l'esempio di Alice che si reca da Bob il fornaio. La transazione sulla blockchain avrebbe il seguente aspetto:

Un osservatore esterno che si affidi alla comune euristica dell'analisi della catena potrebbe concludere erroneamente che "due persone hanno effettuato una piccola coinjoin, con un UTXO ciascuno in ingresso e due UTXO ciascuno in uscita". Analizzare questa transazione dall'esterno non porta all'applicazione del CIOH, in quanto la presenza di due uscite dello stesso importo suggerisce un modello di coinjoin. Da un punto di vista esterno, il CIOH non è quindi applicabile in questo caso specifico.

Questa interpretazione è imprecisa, perché, come è noto, un UTXO è stato inviato a Bob il panettiere, i 2 UTXO in ingresso provengono da Alice, che ha recuperato 3 output di scambio.

L'aspetto particolarmente interessante della struttura della transazione Stonewall è che, dal punto di vista di un osservatore esterno, assomiglia in tutto e per tutto a quella di una transazione Stonewall x2 .

La transazione Stonewall x2

Stonewall x2 è un'altra forma specifica di transazione Bitcoin che mira anch'essa ad aumentare la riservatezza dell'utente quando effettua una spesa, ma questa volta collaborando con una terza persona non coinvolta nella spesa. Questo metodo funziona come una pseudo-coinjoin tra due partecipanti, effettuando contemporaneamente un pagamento a una terza persona.

Il funzionamento della transazione Stonewall x2 è relativamente semplice: utilizziamo un UTXO in nostro possesso per effettuare il pagamento e chiediamo l'aiuto di una terza persona che contribuisce anch'essa con un UTXO di sua proprietà. La transazione si conclude con quattro uscite: due di uguale importo, una destinata all'indirizzo del beneficiario, l'altra a un indirizzo del collaboratore. Un terzo UTXO viene restituito a un altro indirizzo del collaboratore, permettendogli di recuperare l'importo iniziale (un'azione neutra per lui, oltre ai costi di estrazione), e un ultimo UTXO ritorna a un indirizzo di nostra proprietà, che costituisce lo scambio di pagamento.

Nelle transazioni Stonewall x2 vengono quindi definiti tre ruoli diversi:

L'emittente, che effettua il pagamento effettivo ;
Il destinatario, che potrebbe non essere a conoscenza della natura specifica della transazione e si aspetta semplicemente il pagamento da parte del mittente;
Il collaboratore, che mette a disposizione i bitcoin per mettere in dubbio l'analisi della transazione, recuperando alla fine i suoi fondi (un'azione neutra per lui, modulo i costi di mining).

Torniamo all'esempio di Alice, che si trova dal fornaio Bob per acquistare la sua baguette, che costa 4.000 sats. Vuole pagare in bitcoin, mantenendo un certo livello di riservatezza sul pagamento. Si rivolge quindi al suo amico Charles, che la aiuterà in questo processo.

Analizzando questa transazione, possiamo vedere che Bob, il panettiere, ha ricevuto 4.000 sats come pagamento per la baguette. Alice ha utilizzato 10.000 sats in input e ha recuperato 6.000 sats in output, cioè un saldo netto di -4.000 sats, che corrisponde al prezzo della baguette. Quanto a Charles, ha fornito 15.000 sats in input e ha ricevuto due output: uno di 4.000 sats e l'altro di 11.000 sats, ottenendo un saldo di 0.

In questo esempio, ho intenzionalmente tralasciato le commissioni per rendere più facile la comprensione. In realtà, le commissioni di estrazione sono generalmente suddivise in parti uguali tra l'emittente del pagamento e il contribuente.

Quali sono gli obiettivi di una transazione Stonewall x2?

Come la struttura Stonewall, la struttura Stonewall x2 aggiunge una grande quantità di entropia alla transazione e confonde l'analisi della catena. Vista dall'esterno, una transazione di questo tipo può essere interpretata come una piccola unione di monete tra due persone. Ma in realtà si tratta di un pagamento. Questo metodo crea quindi incertezze nell'analisi della catena, o addirittura porta a false piste.

Prendiamo l'esempio di Alice, Bob il fornaio e Charles. La transazione sulla blockchain avrebbe il seguente aspetto:

Un osservatore esterno che si affidasse alla comune euristica dell'analisi della catena potrebbe concludere erroneamente che "Alice e Charles hanno eseguito una piccola coinjoin, con un UTXO ciascuno in ingresso e due UTXO ciascuno in uscita". Anche in questo caso, l'analisi di questa transazione dall'esterno non porta all'applicazione dell'ICOH, poiché la presenza di due uscite dello stesso importo suggerisce un modello di coinjoin. Da un punto di vista esterno, il CIOH non è quindi applicabile in questo caso specifico.

Questa interpretazione non è corretta, perché, come è noto, un UTXO è stato inviato a Bob il fornaio, Alice ha una sola uscita di scambio e Charles ne ha due.

E ancora una volta, ciò che è particolarmente interessante della struttura della transazione Stonewall x2 è che, dal punto di vista di un osservatore esterno, essa assomiglia in tutto e per tutto a una transazione Stonewall.

Qual è la differenza tra Stonewall e Stonewall x2?

Una transazione StonewallX2 funziona esattamente come una transazione Stonewall, con la differenza che la prima è collaborativa, mentre la seconda no. Come abbiamo visto, una transazione Stonewall x2 prevede la partecipazione di una terza parte (Charles), esterna al pagamento, che metterà a disposizione i suoi bitcoin per aumentare la riservatezza della transazione. In una transazione Stonewall classica, il ruolo di collaboratore è assunto dal mittente.

Da un punto di vista esterno, il modello di transazione è esattamente lo stesso.

Il fatto che queste due strutture di transazione condividano esattamente lo stesso schema significa che anche se un osservatore esterno riesce a identificare uno schema "Stonewall(x2)", non avrà tutte le informazioni. Non sarà in grado di determinare quale dei due UTXO di pari importo corrisponda al pagamento. Inoltre, non sarà in grado di stabilire se i due UTXO con ingressi provengono da due persone diverse (Stonewall x2) o se appartengono a un'unica persona che li ha uniti (Stonewall).

Quest'ultimo punto è dovuto al fatto che le transazioni Stonewall x2 seguono esattamente lo stesso schema delle transazioni Stonewall. Viste dall'esterno, e senza ulteriori informazioni contestuali, è impossibile distinguere una transazione Stonewall da una transazione Stonewall x2. Le prime non sono transazioni collaborative, mentre le seconde lo sono. Questo aggiunge ulteriori dubbi all'analisi di una di queste transazioni.

Quando devono essere utilizzate le transazioni Stonewall e Stonewall x2?

La logica dovrebbe essere la seguente quando si vuole utilizzare uno strumento di riservatezza per una spesa:

Come priorità, possiamo scegliere di effettuare un payjoin;
Se il commerciante non supporta i payjoin, è possibile effettuare una transazione collaborativa con un'altra persona al di fuori del pagamento utilizzando la struttura Stonewall x2;
Se non si riesce a trovare nessuno che faccia una transazione Stonewall x2, si può fare una transazione solo Stonewall, che imiterà il comportamento di una transazione Stonewall x2.

Come si utilizzano le transazioni Stonewall e Stonewall x2?

Le transazioni Stonewall e Stonewall x2 sono disponibili sia sull'applicazione Samourai Wallet che sul software Sparrow Wallet.

Tuttavia, come per le payjoin, in seguito all'arresto dei fondatori di Samourai, le transazioni Stonewall x2 funzionano ora solo con lo scambio manuale di PSBT tra le parti interessate. Purtroppo, lo scambio automatico tramite Soroban non è più disponibile.

È anche possibile effettuare questo tipo di transazione manualmente da qualsiasi software di portafoglio Bitcoin.

Nel prossimo capitolo vedremo un'altra tecnica di riservatezza relativamente sconosciuta, ma molto utile come complemento a quelle già studiate.

https://planb.network/tutorials/privacy/on-chain/stonewall-033daa45-d42c-40e1-9511-cea89751c3d4

https://planb.network/tutorials/privacy/on-chain/stonewall-x2-05120280-f6f9-4e14-9fb8-c9e603f73e5b

I rimbalzi

L'uso di strutture di transazione Bitcoin che aggiungono ambiguità all'analisi della catena, come le coinjoin, è particolarmente vantaggioso per la protezione della privacy. Tuttavia, come abbiamo discusso nel capitolo sulle payjoin, le transazioni coinjoin sono naturalmente identificabili sulla catena. Ricordate l'analogia che abbiamo tracciato tra la crittografia e le coinjoin: quando un file è crittografato, una terza parte che scopre il file crittografato non può accedere al suo contenuto, ma può chiaramente identificare che il file è stato modificato per nasconderne il contenuto. Lo stesso vale per le coinjoin: quando un analista esamina una transazione coinjoin, sebbene non possa stabilire collegamenti diretti tra input e output (e viceversa), può comunque riconoscere che la transazione osservata è una coinjoin.

A seconda di come si intende utilizzare la moneta dopo i cicli di coinjoin, il fatto che sia stata sottoposta a questo processo può essere problematico. Ad esempio, se si intende vendere la propria moneta su una piattaforma di scambio regolamentata, ma questa è stata recentemente sottoposta a coinjoin, lo strumento di analisi della catena della piattaforma rileverà questo fatto. La piattaforma potrebbe quindi rifiutarsi di accettare il vostro UTXO coinjoined, o addirittura richiedere una spiegazione da parte vostra, con il rischio che il vostro conto venga sospeso o i vostri fondi congelati. In alcuni casi, la piattaforma può anche segnalare il vostro comportamento alle autorità statali (questo è, ad esempio, ciò che TRACFIN richiede alle PSAN in Francia).

Per evitarlo abbiamo bisogno di uno strumento in grado di cancellare le tracce del passato di una moneta Bitcoin, al fine di ripristinare una forma di fungibilità. È proprio questo lo scopo di ricochet.

Cos'è un rimbalzo?

Il ricochet è una tecnica che consiste nell'eseguire diverse transazioni fittizie verso se stessi (sweep) per simulare un trasferimento di proprietà di bitcoin. Questo strumento si differenzia dalle altre strutture di transazione di cui abbiamo parlato, in quanto non consente di ottenere un anonimato prospettico, ma piuttosto una forma di anonimato retrospettivo. In effetti, il rimbalzo offusca le specificità che possono compromettere la fungibilità di una moneta Bitcoin a causa del suo passato.

Per attenuare l'impronta lasciata da un evento passato su una moneta, come i cicli di coinjoin, ricochet esegue quattro transazioni successive in cui l'utente trasferisce fondi a se stesso a diversi indirizzi.

Dopo questa sequenza di transazioni, lo strumento di ricochet instrada infine i bitcoin verso la loro destinazione finale, ad esempio una piattaforma di scambio.

L'obiettivo è creare una distanza che influisca sulla fungibilità della moneta, come nel caso di una transazione di coinjoin, e l'atto finale di spesa, che potrebbe rifiutare questa moneta a causa del suo passato. In questo modo, gli strumenti di analisi della catena potrebbero concludere che probabilmente c'è stato un cambio di proprietà dopo l'evento e considerare questa moneta fungibile. Nel caso di un coinjoin, gli strumenti di analisi della catena di blocchi potrebbero quindi ritenere che non sia stata la stessa persona a inviare i bitcoin e a effettuare il coinjoin, e che quindi non abbia senso agire contro il mittente.

Perché funziona?

Di fronte a questo metodo di rimbalzo, si potrebbe immaginare che il software di analisi della catena approfondisca l'esame oltre i quattro rimbalzi. Tuttavia, queste piattaforme si trovano di fronte a un dilemma nell'ottimizzare la soglia di rilevamento. Devono stabilire un limite al numero di hop dopo il quale accettano che probabilmente è avvenuta una modifica della proprietà e che il legame con un evento precedente (come una coinjoin) deve essere ignorato.

Tuttavia, la definizione di questa soglia è rischiosa: ogni estensione del numero di salti osservati aumenta esponenzialmente il volume di falsi positivi, ossia di individui erroneamente contrassegnati come partecipanti a un evento, mentre in realtà l'operazione è stata eseguita da qualcun altro. Questo scenario rappresenta un grosso rischio per queste aziende, in quanto i falsi positivi portano all'insoddisfazione, che può spingere i clienti interessati a rivolgersi alla concorrenza. A lungo termine, una soglia di rilevamento troppo alta porta una piattaforma a perdere più clienti rispetto ai suoi concorrenti, il che potrebbe minacciare la sua redditività. È quindi complicato per queste piattaforme aumentare il numero di rimbalzi osservati, e 4 è spesso un numero sufficiente per contrastare le loro analisi.

Il fenomeno osservato è in qualche modo analogo alla teoria dei sei gradi di separazione.

La teoria dei sei gradi di separazione suggerisce che ogni persona sulla Terra è collegata a qualsiasi altra da una catena di relazioni che comprende al massimo sei intermediari. Sarebbe quindi sufficiente passare attraverso una serie di sei persone, ognuna delle quali conosce personalmente l'altra, per raggiungere qualsiasi individuo nel mondo.

Nel caso delle transazioni Bitcoin, troviamo un fenomeno simile. Tracciando un numero sufficiente di transazioni Bitcoin, ci si imbatte inevitabilmente in un coinjoin. Il metodo ricochet sfrutta questo principio utilizzando un numero di hop superiore a quello che le piattaforme di scambio possono ragionevolmente tracciare. Se le piattaforme decidono di tracciare un numero maggiore di transazioni, è possibile aggiungere semplicemente un hop in più per aggirare questa misura.

Quando e come usare il rimbalzo?

Il caso d'uso più comune del rimbalzo si verifica quando è necessario nascondere una precedente partecipazione a una coinjoin su un UTXO di proprietà. Idealmente, è meglio evitare di trasferire bitcoin che hanno subito una coinjoin a entità regolamentate. Tuttavia, nel caso in cui non si abbia altra scelta, in particolare nell'urgenza di liquidare i bitcoin in valuta statale, il ricochet offre una soluzione efficace.

Questo metodo è efficace non solo per le coinjoin, ma anche per qualsiasi altro segno che potrebbe compromettere la fungibilità di un pezzo.

L'idea di questo metodo di ricochet è nata dai team di Samourai Wallet, che l'hanno integrato nella loro applicazione per automatizzare il processo. Il servizio non è gratuito su Samourai, in quanto un rimbalzo comporta una tassa di servizio di 100.000 sats, oltre ai costi di estrazione. Il suo utilizzo è quindi consigliato per trasferimenti di importi significativi.

L'applicazione Samurai offre due varianti di rimbalzo:

Ricochet rinforzato, o "consegna scaglionata", che offre il vantaggio di distribuire il costo del servizio Samurai sulle cinque transazioni successive. Questa opzione garantisce inoltre che ogni transazione venga trasmessa in un momento distinto e registrata in un blocco diverso, imitando il più possibile il comportamento di un cambio di proprietario. Anche se più lento, questo metodo è preferibile per chi non ha fretta, in quanto massimizza l'efficienza del ricochet rafforzando la sua resistenza all'analisi della catena;

Il classico ricochet, che è progettato per eseguire l'operazione con velocità, trasmette tutte le transazioni in un intervallo di tempo ridotto. Questo metodo, quindi, offre meno riservatezza e meno resistenza all'analisi rispetto al metodo rinforzato. Dovrebbe essere utilizzato solo per le spedizioni urgenti.

Rimbalzare significa semplicemente inviare bitcoin a se stessi. È perfettamente possibile rimbalzare i bitcoin manualmente su qualsiasi software di portafoglio, senza utilizzare uno strumento specializzato. Tutto ciò che dovete fare è trasferire successivamente la stessa moneta a voi stessi, utilizzando ogni volta un nuovo indirizzo vuoto.

Nel prossimo capitolo esamineremo diverse tecniche per il trasferimento segreto della proprietà. Questi metodi differiscono radicalmente da quelli esaminati finora, sia in termini di funzionamento che di risultati.

https://planb.network/tutorials/privacy/on-chain/ricochet-e0bb1afe-becd-44a6-a940-88a463756589

Trasferimenti segreti di proprietà

Un'altra delle tecniche di riservatezza di Bitcoin è il trasferimento segreto della proprietà. Questo metodo mira a trasferire la proprietà dei Bitcoin da una persona a un'altra, e viceversa, senza che la transazione sia esplicitamente visibile sulla blockchain. Vediamo le diverse tecniche disponibili, con i relativi vantaggi e svantaggi.

Lo scambio di monete

Coinwap si basa su un concetto relativamente semplice: utilizza contratti intelligenti per facilitare il trasferimento della proprietà di bitcoin tra due utenti, senza bisogno di fiducia e senza che questo trasferimento sia esplicitamente visibile sulla blockchain.

Immaginiamo un esempio ingenuo con Alice e Bob. Alice possiede 1 BTC protetto con la chiave privata $A$ e anche Bob possiede 1 BTC protetto con la chiave privata $B$ . In teoria, i due potrebbero scambiarsi le loro chiavi private attraverso un canale di comunicazione esterno per effettuare un trasferimento segreto.

Tuttavia, questo metodo ingenuo presenta un rischio elevato in termini di fiducia. Nulla impedisce ad Alice di conservare una copia della chiave privata di $A$ dopo lo scambio e di usarla in seguito per rubare i bitcoin, una volta che la chiave è nelle mani di Bob.

Inoltre, non c'è alcuna garanzia che Alice non riceva la chiave privata di Bob $B$ e non trasmetta mai la sua chiave privata $A$ in cambio. Questo scambio si basa quindi su un'eccessiva fiducia tra le parti ed è inefficace nel garantire un trasferimento segreto sicuro della proprietà.

Per risolvere questi problemi e consentire scambi tra parti che non si fidano l'una dell'altra, utilizzeremo invece sistemi di smart contract. Un contratto intelligente è un programma che viene eseguito automaticamente quando si verificano condizioni predefinite. Nel nostro caso, questo garantisce che lo scambio di proprietà avvenga automaticamente, senza bisogno di fiducia reciproca.

Questo può essere ottenuto utilizzando i protocolli HTLC (Hash Time-Locked Contracts) o PTLC (Point Time-Locked Contracts). Questi due protocolli funzionano in modo simile, utilizzando un sistema di blocco temporale che garantisce che lo scambio sia completato con successo o annullato completamente, proteggendo così l'integrità dei fondi di entrambe le parti. La differenza principale tra HTLC e PTLC è che HTLC utilizza hash e preimmagini per proteggere la transazione, mentre PTLC utilizza le firme degli adattatori.

In uno scenario di scambio di monete che utilizza HTLC o PTLC tra Alice e Bob, lo scambio avviene in modo sicuro: o riesce e ciascuno riceve il BTC dell'altro, o fallisce e ciascuno conserva il proprio BTC. In questo modo è impossibile per una delle due parti imbrogliare o rubare i BTC dell'altra.

HTLC è anche il meccanismo utilizzato per instradare in modo sicuro i pagamenti attraverso i canali bidirezionali di Lightning Network L'uso delle firme adattatore è particolarmente interessante in questo contesto, in quanto consente di rinunciare agli script tradizionali (un meccanismo talvolta definito "script senza script"). Questa caratteristica riduce i costi associati allo scambio. Un altro grande vantaggio delle Firme adattatore è che non richiedono l'uso di un hash comune per entrambe le parti della transazione, evitando così la necessità di rivelare un legame diretto tra loro in alcuni tipi di scambio.

Firme degli adattatori

Le firme adattatore sono un metodo crittografico che integra una firma valida con una firma aggiuntiva, chiamata "firma adattatore", per rivelare dati segreti. Questo meccanismo è progettato in modo tale che la conoscenza di 2 dei 3 elementi seguenti: la firma valida, la firma adattatore e il segreto, ci permette di dedurre il terzo elemento mancante. Una proprietà interessante di questo metodo è che, se conosciamo la firma dell'adattatore di un nostro pari e il punto specifico della curva ellittica associata al segreto usato per calcolare la firma dell'adattatore, possiamo ricavare la nostra firma dell'adattatore che sarà compatibile con lo stesso segreto, senza avere accesso diretto al segreto stesso.

In un coinswap, l'uso delle firme adattatore consente la divulgazione simultanea di due informazioni sensibili tra i partecipanti, evitando così la necessità di una fiducia reciproca. Facciamo un esempio per illustrare questo processo con Alice e Bob, che desiderano scambiarsi il possesso di 1 BTC ciascuno, ma non si fidano l'uno dell'altro. Per eliminare la necessità di fidarsi l'uno dell'altro in questo scambio, utilizzano le firme adattatore. Ecco come fare:

Alice avvia lo scambio creando una transazione $m_A$ che invia 1 BTC a Bob. Genera una firma $s_A$ , che convalida questa transazione, utilizzando la sua chiave privata $p_A$ ( $P_A = p_A \cdot G$ ), un nonce $n_A$ ( $N_A = n_A \cdot G$ ) e un segreto $t$ ( $T = t \cdot G$ ) :

$s_A = n_A + t + H(N_A + T \parallelo P_A \parallelo m_A) \cdot p_A$

Alice calcola la firma dell'adattatore $s_A'$ sottraendo il segreto $t$ dalla sua vera firma $s_A$ :

$$s_A' = s_A - t$$$

Alice invia a Bob il suo adattatore di firma $s'_A$ , la sua transazione non firmata $m_A$ , il punto corrispondente al segreto ( $T$ ) e il punto corrispondente al nonce ( $N_A$ ). Questi elementi costituiscono il cosiddetto "adattatore". È importante notare che, con queste sole informazioni, Bob non può recuperare il BTC di Alice.
Tuttavia, Bob può verificare che Alice non stia cercando di derubarlo. Per farlo, controlla se l'adattatore di firma di Alice $s_A'$ corrisponde effettivamente alla transazione proposta $m_A$ . Se la seguente equazione è corretta, Bob può essere certo che l'adattatore di firma di Alice sia valido:

$s_A' \cdot G = N_A + H(N_A + T \parallelo P_A \parallelo m_A) \cdot P_A$

Questa verifica fornisce a Bob garanzie sufficienti per continuare lo scambio in totale sicurezza. Crea quindi la propria transazione $m_B$ , destinata a inviare 1 BTC ad Alice, e genera la propria firma adattatore $s_B'$ , che sarà anch'essa legata allo stesso segreto $t$ . A questo punto, solo Alice conosce il valore di $t$ ; Bob conosce solo il punto corrispondente $T$ che Alice gli ha trasmesso:

$s_B' = n_B + H(N_B + T \parallelo P_B \parallelo m_B) \cdot p_B$

Bob invia ad Alice la sua firma adattatore $s_B'$ , la sua transazione non firmata $m_B$ , nonché il punto corrispondente al segreto ( $T$ ) e il punto corrispondente al nonce ( $N_B$ ). Alice, che conosce il segreto $t$ , può ora combinare la firma adattatore di Bob $s_B'$ con questo segreto per generare una firma valida $s_B$ per la transazione $m_B$ che le trasferirà i BTC di Bob:

$$s_B = s_B' + t$$$

$(s_B' + t) \cdot G = N_B + T + H(N_B + T \parallelo P_B \parallelo m_B) \cdot P_B$

Alice trasmette questa transazione firmata $m_B$ sulla blockchain Bitcoin per recuperare i BTC promessi da Bob. Quando Bob vede questa transazione sulla blockchain, può estrarre la firma $s_B = s_B' + t$ . Con queste informazioni, Bob è in grado di isolare il famoso segreto $t$ di cui aveva bisogno:

$t = (s_B' + t) - s_B' = s_B - s_B'$

E questo segreto $t$ era l'unico elemento mancante a Bob per generare la firma valida $s_A$ dalla firma dell'adattatore di Alice $s_A'$ . Questa firma convalida la transazione $m_A$ , che invia un BTC da Alice a Bob. Bob calcola quindi $s_A$ e trasmette la transazione $m_A$ sulla blockchain:

$$s_A = s_A' + t$$$

$(s_A' + t) \cdot G = N_A + T + H(N_A + T \parallela P_A \parallela m_A) \cdot P_A$

Riassumiamo il funzionamento di un adattatore di firma in un coinswap. Inizialmente, Alice invia a Bob una transazione non firmata accompagnata da un adattatore, consentendo a Bob di verificare che il segreto rivelato in seguito gli darà accesso ai bitcoin. In cambio, Bob invia ad Alice la propria transazione non firmata e l'adattatore. Alice può quindi finalizzare la transazione di Bob e recuperare i bitcoin trasmettendo una transazione valida grazie al segreto. Quando questa transazione viene pubblicata sulla blockchain, Bob ha la possibilità di estrarre il segreto e quindi di sbloccare la transazione di Alice. Di conseguenza, se Alice avvia un trasferimento dei bitcoin di Bob, Bob può, a sua volta, accedere ai bitcoin di Alice senza bisogno di fiducia reciproca.

Si noti che i coinswap sono stati proposti per la prima volta da Gregory Maxwell nell'ottobre 2013 su BitcoinTalk.

Scambio atomico

In modo simile al coinswap, e utilizzando gli stessi tipi di smart contract, è possibile effettuare anche gli atomic swap. Uno swap atomico consente uno scambio diretto di criptovalute diverse, come BTC e XMR, tra due utenti senza bisogno di fiducia o dell'intervento di un intermediario. Questi scambi sono definiti "atomici" perché hanno solo due esiti possibili: o lo scambio va a buon fine ed entrambe le parti sono soddisfatte, oppure fallisce e ciascuno conserva le proprie criptovalute originali, eliminando la necessità di fidarsi dell'altra parte.

Lo swap atomico e il coinswap condividono un metodo di funzionamento simile e offrono gli stessi vantaggi e svantaggi in termini di riservatezza. In effetti, dal punto di vista di Bitcoin, uno swap atomico è paragonabile a un coinswap effettuato in due fasi. In primo luogo, si scambia il proprio BTC con un'altra criptovaluta, poi questa criptovaluta può essere scambiata con altri BTC. Infine, recuperiamo il BTC di un altro utente. Per questo motivo, nell'analisi dei problemi di riservatezza, raggruppo questi due protocolli sotto la categoria degli scambi segreti proprietari.

Attenzione, però, perché a differenza del coinswap, lo swap atomico può presentare squilibri in termini di liquidità disponibile, in particolare negli scambi BTC/XMR. In genere è più facile scambiare bitcoin con altcoin, poiché c'è una forte domanda di bitcoin, che mantiene bassi i premi per questa direzione di conversione. Tuttavia, lo scambio di altcoin in BTC può essere più complesso a causa della minore domanda, e spesso comporta premi molto elevati.

Infine, quando uno swap atomico coinvolge bitcoin onchain e bitcoin sulla rete Lightning, si parla di "swap sottomarino".

È davvero utile?

I trasferimenti segreti di proprietà, come i coinswap e gli atomic swap, hanno il vantaggio di ingannare le euristiche di analisi della catena. Questi metodi possono far credere che le transazioni coinvolgano lo stesso utente, mentre in realtà la proprietà è passata di mano. Tuttavia, lo svantaggio principale di questi metodi è che sono molto rischiosi senza l'uso di una tecnica aggiuntiva per rompere la storia della moneta.

Infatti, quando Alice effettua un coinswap o un atomic swap con Bob, scambia il possesso dei suoi bitcoin con quelli di Bob. Nel caso di uno scambio atomico, lo scambio include un'altcoin, ma il principio rimane lo stesso. Pertanto, Alice si ritrova con la moneta $B$ e Bob con la moneta $A$ . Questo aggiunge dubbi all'analisi della catena, ma la storia delle monete rimane tracciabile. Se un analista esamina la parte $A$ , può risalire alle attività precedenti di Alice e viceversa per la parte $B$ .

Dal punto di vista di Alice, il rischio è che la storia della moneta $B$ possa essere considerata sospetta da alcune entità. Se, ad esempio, Bob avesse acquisito la moneta $B$ attraverso un atto criminale come l'hacking, la moneta rimarrebbe legata alle sue attività illegali. Alice potrebbe quindi trovarsi in possesso di una moneta che non potrebbe trasferire su piattaforme di scambio regolamentate senza rischiare di vedersi congelare i fondi, o addirittura essere accusata dei crimini di Bob, anche se non ha nulla a che fare con essi.

Inevitabilmente, metodi di riservatezza come il coinswap o l'atomic swap sono preferiti dai criminali i cui fondi sono sotto sorveglianza da parte delle autorità. Questi protocolli consentono loro di disfarsi dei bitcoin sotto sorveglianza in cambio di bitcoin perfettamente fungibili. Inoltre, consentono di creare un diversivo, indirizzando le autorità verso altri utenti. Quindi c'è un doppio scopo per queste persone.

Con coinjoin, anche se la vostra moneta è mescolata con bitcoin monitorati, la storia della moneta è interrotta, fornendo una forma di negabilità plausibile che è inesistente nei protocolli di trasferimento segreto della proprietà come coinswap o atomic swap.

Se Alice vuole evitare qualsiasi rischio, deve necessariamente utilizzare un metodo per interrompere la storia della moneta $B$ , ad esempio passandola attraverso coinjoin. Ciò solleva una questione sull'utilità di combinare il trasferimento segreto di proprietà e il coinjoin. Il coinjoin, interrompendo la storia di una moneta, offre già un livello sufficiente di riservatezza per Alice. Pertanto, la mia opinione è che se Alice vuole proteggere la sua privacy, sarebbe più saggio procedere direttamente a un coinjoin piuttosto che intraprendere un coinswap seguito da un coinjoin.

Affinché i metodi di trasferimento segreto della proprietà siano veramente efficaci ed evitino il rischio di collegare la storia di un utente $A$ a un utente $B$ , sarebbe paradossalmente necessario che il loro uso sia ampiamente conosciuto. Se il coinswap è utilizzato in modo massiccio e le autorità sono a conoscenza di questa pratica comune, allora si potrebbe stabilire una forma plausibile di negazione. Tuttavia, finché l'uso di questi trasferimenti rimarrà marginale, penso che questi metodi rimarranno troppo rischiosi per gli utenti.

Finora abbiamo studiato principalmente i metodi di riservatezza a livello delle transazioni stesse. Nel prossimo capitolo esamineremo i problemi a livello di rete e di diffusione delle transazioni.

Privacy sulla rete P2P

Nella Parte 4 abbiamo discusso l'importanza di utilizzare un nodo completo per proteggere la riservatezza delle transazioni. Tuttavia, è importante capire che il vostro nodo può essere soggetto ad attacchi che cercano di estrarre informazioni sulle vostre attività. In questo capitolo, quindi, esamineremo le varie misure che potete adottare per proteggere la vostra privacy, non a livello delle transazioni stesse o dei flussi di bitcoin, ma a livello della rete.

Dente di leone

Un modo per evitare i vari attacchi di de-anonimizzazione è quello di utilizzare la proposta Dandelion. Questo protocollo di trasmissione è stato formalizzato nel BIP156, ma non è mai stato implementato su Bitcoin.

L'idea alla base di Dandelion è quella di migliorare la riservatezza del routing delle transazioni nella rete Bitcoin per contrastare varie forme di attacco. Il suo obiettivo principale è quello di nascondere il nodo sorgente che ha trasmesso inizialmente una transazione sulla rete. La divulgazione di questo nodo potrebbe consentire di collegare una transazione Bitcoin a un indirizzo IP specifico (se il nodo opera su clearnet), il che potrebbe fornire un punto di ingresso per l'analisi della catena.

Questa associazione tra l'attività su Bitcoin e un indirizzo IP rappresenta un rischio considerevole per la riservatezza degli utenti. Infatti, molte entità sono in grado di collegare facilmente un indirizzo IP a un'identità personale. Tra questi vi sono i governi e i fornitori di servizi Internet. Inoltre, queste informazioni possono diventare pubblicamente accessibili, ad esempio se l'indirizzo IP e i dati personali dell'utente vengono divulgati quando il database di un sito web viene violato.

Nel funzionamento classico di Bitcoin, le transazioni costruite da un utente sul suo portafoglio software vengono trasmesse al suo nodo personale. Questo nodo trasmette immediatamente la nuova transazione a tutti i peer a cui è collegato.

Questi peer controllano quindi la transazione per assicurarsi che sia conforme alle regole di consenso e di standardizzazione locale. Una volta convalidata, ogni peer inoltra a sua volta la transazione ai suoi pari, e così via.

Questa distribuzione delle transazioni in attesa di essere integrate in un blocco è abbastanza equilibrata e statisticamente prevedibile. Questa debolezza può essere sfruttata da nodi spia complici, che collaborano per monitorare e analizzare la rete, al fine di identificare il primo nodo che ha trasmesso una transazione. Se un osservatore riesce a individuare il nodo di origine, può presumere che la transazione provenga dall'operatore di quel nodo. Questo tipo di osservazione può essere utilizzato per collegare transazioni normalmente anonime a indirizzi IP specifici.

L'obiettivo del BIP156 è quello di risolvere questo problema. A tal fine, introduce una fase aggiuntiva nella diffusione di una nuova transazione per preservare l'anonimato prima dell'ampia propagazione pubblica. Dandelion utilizza innanzitutto una fase "stem" in cui la transazione viene inviata attraverso un percorso casuale di nodi.

La transazione viene poi trasmessa all'intera rete nella fase di "Fluff".

Lo stelo e la fase "Fluff" fanno riferimento al comportamento della propagazione della transazione attraverso la rete, che ricorda la forma e l'evoluzione di un dente di leone ("Dandelion" in inglese).

Pertanto, i nodi spia possono potenzialmente risalire alla transazione fino al nodo che ha avviato la fase di "Fluff" (la diffusione di massa), ma quel nodo non è quello che ha trasmesso per primo la transazione, poiché l’ha ricevuta dall’ultimo nodo del gambo. Se i nodi spia non riescono a risalire al gambo, non possono nemmeno identificare il nodo sorgente.

Anche in presenza di nodi-spia durante la fase di stem, rimane sempre un dubbio, perché non appena incontrano un nodo onesto nel grafo di diffusione, le spie non sono in grado di stabilire se questo nodo sia la fonte originale o semplicemente un intermediario.

Questo metodo di instradamento offusca la traccia che riporta al nodo sorgente, rendendo difficile risalire all'origine di una transazione attraverso la rete. Dandelion migliora quindi la riservatezza, limitando la capacità degli avversari di de-anonimizzare la rete. Questo metodo è ancora più efficace quando, durante la fase di "stemming", la transazione attraversa un nodo che cripta le sue comunicazioni di rete, come Tor o P2P Transport V2.

BIP156 non è stato integrato in Bitcoin Core ed è attualmente classificato come "rifiutato". Una delle principali preoccupazioni di questo protocollo è che, durante la fase di stem, le transazioni devono essere trasmesse attraverso nodi intermedi prima di essere verificate. Come abbiamo visto, nel normale modello Bitcoin, ogni nodo verifica la transazione prima di trasmetterla ai suoi pari. Se una transazione non è conforme alle regole di consenso del nodo o alle regole di standardizzazione locale, il nodo la ignora e non la distribuisce. Questo processo è importante per contrastare gli attacchi DoS, in quanto solo le transazioni valide vengono trasmesse all'intera rete. Le transazioni non valide, potenzialmente generate in massa per sovraccaricare la rete, vengono bloccate al primo nodo incontrato e non si propagano. Il rischio principale di Dandelion è che questo nuovo protocollo possa introdurre nuovi vettori per gli attacchi DoS, consentendo la trasmissione di transazioni non valide su parte della rete.

Trasporto P2P V2

Il P2P transport V2 è un altro protocollo di rete presentato nel BIP324. È una nuova versione del protocollo di trasporto P2P di Bitcoin che incorpora la crittografia opportunistica per migliorare la riservatezza e la sicurezza delle comunicazioni tra i nodi.

Questo miglioramento è stato progettato per risolvere diversi problemi della versione base del protocollo P2P. Da un lato, rende i dati scambiati indistinguibili da altri tipi di dati che circolano su Internet per un osservatore passivo. L'obiettivo principale è quello di impedire a governi, ISP e fornitori di VPN di monitorare massicciamente gli utenti di Bitcoin. Questo rende anche più difficile per queste entità determinare se un utente di Internet è anche un utente di Bitcoin, cioè se sta gestendo un nodo completo.

Il P2P V2 aiuta anche a ridurre il rischio di censura e di attacchi, rilevando modelli specifici nei pacchetti di dati. Complica e rende più costosa l'esecuzione di vari tipi di attacchi Sybil a livello di rete. Un attacco Sybil si verifica quando un attore crea più identità false per ottenere un vantaggio sleale. Nel contesto della rete Bitcoin, questo si manifesta spesso come un attore che controlla un gran numero di nodi completi e li usa aggressivamente per moltiplicare le connessioni. Gli attacchi sibillini possono essere passivi, per raccogliere informazioni e compromettere la riservatezza degli utenti, o attivi, sotto forma di attacchi Eclipse. Questi ultimi isolano un nodo specifico dal resto della rete, censurando l'utente o alterando i dati che riceve. Infine, il P2P V2 rende anche gli attacchi Man-In-The-Middle (MITM) più costosi e facili da individuare.

La crittografia implementata da P2P V2 non include l'autenticazione, per non aggiungere inutili complessità e per non compromettere il fatto che la connessione alla rete rimane senza permessi. Tuttavia, questo nuovo protocollo di trasporto P2P offre una maggiore sicurezza contro gli attacchi passivi e rende gli attacchi attivi molto più costosi e rilevabili. L'introduzione di un flusso di dati pseudocasuali nei messaggi di rete rende più difficile per gli aggressori censurare o manipolare le comunicazioni.

Il trasporto P2P V2 è stato incluso come opzione (disattivata per impostazione predefinita) nella versione 26.0 di Bitcoin Core, distribuita nel dicembre 2023. È stato poi abilitato per impostazione predefinita nella versione 27.0 dell'aprile 2024. Può essere modificato con l'opzione v2transport= nel file di configurazione.

Tor

Un'altra semplice soluzione per evitare il rischio di perdita di riservatezza per un nodo di rete è quella di eseguirlo interamente sotto Tor.

Tor è una rete di server relay (nodi) che rende anonima l'origine delle connessioni TCP su Internet. Funziona incapsulando i dati in diversi strati di crittografia. Ogni nodo relay rimuove uno strato per rivelare l'indirizzo del nodo successivo, fino a raggiungere la destinazione finale. La rete Tor garantisce l'anonimato impedendo ai nodi intermediari di conoscere sia l'origine che la destinazione dei dati, rendendo molto difficile per un osservatore tracciare l'attività di un utente.

Tor non solo cripta i dati, ma maschera anche l'origine e la destinazione delle comunicazioni. Utilizzando Tor per le comunicazioni dal vostro nodo personale, rafforzate la riservatezza delle vostre transazioni: il vostro ISP non può decifrare le comunicazioni e gli altri nodi della rete Bitcoin non possono identificare l'indirizzo IP del nodo di origine. Inoltre, Tor nasconde il vostro uso di Bitcoin al vostro ISP.

Il rischio principale di questo metodo è che Tor è un protocollo indipendente da Bitcoin. Se avete un nodo Bitcoin in esecuzione sotto Tor e Tor smette di funzionare, il vostro nodo Bitcoin non sarà più in grado di comunicare.

Inoltre, è importante notare che le comunicazioni su Tor sono più lente. Questa latenza è particolarmente fastidiosa durante il lancio iniziale di un nodo, poiché l'IBD (Initial Block Download) richiede molte comunicazioni. Di conseguenza, la sincronizzazione iniziale con la rete Bitcoin potrebbe richiedere molto più tempo utilizzando Tor. È anche possibile eseguire l'IBD sulla rete, quindi attivare Tor come secondo passo. Sebbene questo metodo riveli l'esistenza del vostro nodo Bitcoin al vostro ISP, protegge le vostre informazioni personali sulle transazioni una volta passati a Tor.

Dopo aver esplorato i vari metodi di riservatezza a livello di rete, nei prossimi capitoli vorrei presentarvi anche due eleganti soluzioni per evitare il riutilizzo degli indirizzi: BIP47 e Silent Payments.

BIP47 e codici di pagamento riutilizzabili

Come abbiamo visto nella parte 3, il riutilizzo degli indirizzi è un serio ostacolo alla riservatezza degli utenti nel protocollo Bitcoin. Per mitigare questi rischi, si raccomanda vivamente di generare un indirizzo di ricezione vuoto per ogni nuovo pagamento ricevuto in un portafoglio. Sebbene la generazione di un nuovo indirizzo sia oggi semplificata dall'uso di software moderni e di portafogli gerarchici deterministici, questa pratica può sembrare controintuitiva.

Nel sistema bancario tradizionale, ad esempio, siamo abituati a condividere il nostro IBAN, che rimane sempre lo stesso. Una volta che lo abbiamo dato a qualcuno, questi può inviarci più pagamenti senza dover interagire nuovamente con noi. Le neo-banche offrono anche possibilità più moderne, come l'uso di indirizzi e-mail unici su PayPal o di RevTag su Revolut. Anche al di fuori della sfera finanziaria, i nostri identificativi quotidiani come l'indirizzo postale, il numero di telefono e l'indirizzo e-mail sono unici e permanenti. Non dobbiamo rinnovarli per ogni nuova interazione.

Tuttavia, Bitcoin funziona in modo diverso: per ogni transazione in entrata deve essere generato un nuovo indirizzo di ricezione. Questo compromesso tra facilità d'uso e riservatezza risale alle origini stesse del Libro Bianco di Bitcoin. Già alla fine del 2008, con la pubblicazione della prima versione del documento, Satoshi Nakamoto ci avvertiva di questo rischio:

**Come ulteriore firewall, si potrebbe utilizzare una nuova coppia di chiavi per ogni transazione, in modo da non collegarle a un proprietario comune

Esistono molti modi per ricevere più pagamenti su un singolo identificatore senza dover riutilizzare un indirizzo. Ognuno di essi ha i propri compromessi e svantaggi. Tra questi metodi c'è BIP47, una proposta sviluppata da Justus Ranvier e pubblicata nel 2015. Questa proposta mira a creare codici di pagamento riutilizzabili che consentano di effettuare più transazioni nei confronti della stessa persona, evitando il riutilizzo dell'indirizzo. In breve, BIP47 mira a offrire un sistema di pagamento intuitivo come un identificativo unico, preservando al contempo la riservatezza delle transazioni.

BIP47 non migliora direttamente la riservatezza degli utenti, poiché un pagamento BIP47 offre lo stesso livello di riservatezza di una transazione Bitcoin classica che utilizza indirizzi vuoti. Tuttavia, rende l'uso di Bitcoin più comodo e intuitivo, una facilità che normalmente comprometterebbe la riservatezza. Grazie a BIP47, questa facilità d'uso raggiunge lo stesso livello di riservatezza di una transazione classica. Ecco perché BIP47 è uno strumento così prezioso per preservare la privacy.

Inizialmente, BIP47 era stato proposto per l'integrazione in Bitcoin Core, ma non è mai stato implementato. Tuttavia, alcune applicazioni software hanno scelto di implementarlo autonomamente. Ad esempio, i team di Samourai Wallet hanno sviluppato una propria implementazione di BIP47 chiamata "PayNym".

Principio generale di BIP47 e PayNym

L'obiettivo del BIP47 è quello di rendere possibile la ricezione di un gran numero di pagamenti senza riutilizzare gli indirizzi. Si basa sull'uso di un codice di pagamento riutilizzabile, che consente a diversi emittenti di inviare più pagamenti a un unico codice appartenente a un altro utente. Di conseguenza, il destinatario non deve fornire un nuovo indirizzo vuoto per ogni transazione, il che facilita notevolmente gli scambi, preservando la riservatezza.

L'utente può quindi condividere il proprio codice di pagamento in piena libertà, sia sui social network che sul proprio sito web, senza rischiare alcuna perdita di riservatezza, a differenza di quanto avviene con un indirizzo di destinatario convenzionale o una chiave pubblica.

Per effettuare una transazione, entrambe le parti hanno bisogno di un portafoglio Bitcoin con un'implementazione BIP47, come PayNym su Samurai Wallet o Sparrow Wallet. L'uso congiunto dei loro codici di pagamento crea un canale segreto tra loro. Per stabilire questo canale in modo efficace, l'emittente deve effettuare una transazione specifica sulla blockchain Bitcoin, nota come "transazione di notifica" (per saperne di più).

La combinazione dei codici di pagamento dei due utenti genera segreti condivisi, che a loro volta creano un gran numero di indirizzi unici di ricezione di Bitcoin (esattamente 2^32, ovvero circa 4 miliardi). In questo modo, i pagamenti effettuati tramite BIP47 non sono in realtà indirizzati al codice di pagamento stesso, ma piuttosto ai classici indirizzi di ricezione derivati dai codici di pagamento degli utenti coinvolti.

Il codice di pagamento funge quindi da identificatore virtuale derivato dal seme del portafoglio. Nella struttura gerarchica di derivazione del portafoglio, il codice di pagamento è posizionato al livello 3, ossia al livello del conto.

Il target di derivazione per il BIP47 è identificato dall'indice 47' (0x8000002F), che si riferisce al BIP47. Un esempio di percorso di derivazione per un codice di pagamento riutilizzabile è il seguente:

m/47'/0'/0'/

Per darvi un'idea di come si presenta un codice di pagamento, ecco il mio:

PM8TJSBiQmNQDwTogMAbyqJe2PE2kQXjtgh88MRTxsrnHC8zpEtJ8j7Aj628oUFk8X6P5rJ7P5qDudE4Hwq9JXSRzGcZJbdJAjM9oVQ1UKU5j2nr7VR5

Questo codice può anche essere codificato come codice QR, per facilitare la comunicazione, proprio come un indirizzo di ricezione convenzionale.

Per quanto riguarda i PayNym Bots, i robot che a volte si vedono su Twitter, si tratta di rappresentazioni visive del codice di pagamento, create da Samourai Wallet. Vengono generati utilizzando una funzione hash, che conferisce loro una quasi-unicità. Hanno la forma di una piccola stringa di caratteri che inizia con +:

+throbbingpond8B1
+twilightresonance487
+billowingfire340

Questi avatar possono anche essere rappresentati come immagini:

Sebbene questi robot non abbiano alcuna funzionalità tecnica specifica nell'ambito del framework BIP47, svolgono un ruolo nel facilitare l'interazione con l'utente offrendo un'identità visiva facilmente riconoscibile.

Nelle sezioni successive di questo capitolo dedicate a BIP47, vedremo nel dettaglio il suo funzionamento, con particolare attenzione ai metodi crittografici utilizzati. Per comprendere appieno queste spiegazioni un po' tecniche, è essenziale capire prima la struttura dei portafogli HD, le procedure di derivazione delle chiavi e i fondamenti della crittografia a curva ellittica. Se desiderate approfondire questi concetti, un altro corso di formazione gratuito è disponibile su Plan ₿ Network :

https://planb.network/courses/46b0ced2-9028-4a61-8fbc-3b005ee8d70f

Vi consiglio comunque di seguirli, perché la comprensione del funzionamento tecnico del BIP47 vi renderà molto più facile la comprensione di altre proposte simili, di cui parleremo nei capitoli successivi

Il codice di pagamento riutilizzabile

Come già detto, il codice di pagamento riutilizzabile si trova alla profondità 3 del portafoglio HD, il che lo rende paragonabile a un xpub, sia in termini di posizione nella struttura del portafoglio che di ruolo.

Il codice di pagamento di 80 byte si suddivide come segue:

Byte 0: La versione**. Per la prima versione di BIP47, questo byte è impostato su 0x01;
Byte 1: Il campo dei bit**. Questo spazio è riservato all'integrazione di indicazioni aggiuntive per usi specifici. Per l'uso classico di PayNym, questo byte è impostato su 0x00;
Il byte 2: La parità di y**. Questo byte è 0x02 o 0x03, a indicare se l'ordinata della chiave pubblica è pari o dispari, poiché viene utilizzata una chiave pubblica compressa;
Dal byte 3 al byte 34: Il valore di x**. Questi byte rappresentano l'ascissa della chiave pubblica. La concatenazione di x e della parità di y forma la chiave pubblica compressa completa;
Dal byte 35 al byte 66: Il codice stringa**. Questo spazio contiene il codice stringa associato alla chiave pubblica;
Dal byte 67 al byte 79: Il padding**. Questo spazio è destinato a possibili evoluzioni future. Per la versione attuale, si mettono semplicemente degli zeri qui per raggiungere la dimensione di 80 byte richiesta per l'output di OP_RETURN.

Ecco la rappresentazione esadecimale del mio codice di pagamento riutilizzabile già presentato nella sezione precedente:

0x010002a0716529bae6b36c5c9aa518a52f9c828b46ad8d907747f0d09dcd4d9a39e97c3c5f37c470c390d842f364086362f6122f412e2b0c7e7fc6e32287e364a7a36a00000000000000000000000000

All'inizio deve essere aggiunto il byte di prefisso P per indicare chiaramente che si tratta di un codice di pagamento. Questo byte è rappresentato da 0x47:

0x47010002a0716529bae6b36c5c9aa518a52f9c828b46ad8d907747f0d09dcd4d9a39e97c3c5f37c470c390d842f364086362f6122f412e2b0c7e7fc6e32287e364a7a36a00000000000000000000000000

Infine, per garantire l'integrità del codice di pagamento, viene eseguito un calcolo del checksum utilizzando HASH256, che consiste in un doppio hash utilizzando la funzione SHA256. I primi quattro byte di questo hash vengono concatenati alla fine del codice di pagamento:

0x47010002a0716529bae6b36c5c9aa518a52f9c828b46ad8d907747f0d09dcd4d9a39e97c3c5f37c470c390d842f364086362f6122f412e2b0c7e7fc6e32287e364a7a36a00000000000000000000000000567080c4

Una volta completati questi passaggi, il codice di pagamento è pronto. Non resta che convertirlo in base 58 per ottenere la versione finale:

PM8TJSBiQmNQDwTogMAbyqJe2PE2kQXjtgh88MRTxsrnHC8zpEtJ8j7Aj628oUFk8X6P5rJ7P5qDudE4Hwq9JXSRzGcZJbdJAjM9oVQ1UKU5j2nr7VR5

Nel processo di creazione del codice di pagamento, utilizziamo una chiave pubblica compressa e un codice stringa. Entrambi sono derivati in modo deterministico e gerarchico dal seme del portafoglio. Il percorso di derivazione utilizzato per ottenere questo risultato è :

m/47'/0'/0'/

In concreto, per generare la chiave pubblica compressa e il codice stringa associato al codice di pagamento riutilizzabile, si inizia calcolando la chiave privata master dal seme del portafoglio. Si procede quindi alla derivazione di una coppia di chiavi figlie utilizzando l'indice 47 + 2^31 (derivazione rafforzata). Seguono altre due derivazioni successive di coppie di chiavi figlie, ognuna delle quali utilizza l'indice 2^31 (derivazione rafforzata).

Scambio di chiavi Diffie-Hellman su curve ellittiche (ECDH)

Il protocollo crittografico alla base di BIP47 è noto con l'acronimo ECDH, per Elliptic-Curve Diffie-Hellman. Questo metodo è una variante dello scambio di chiavi Diffie-Hellman originale.

Introdotto nel 1976, Diffie-Hellman è un protocollo di accordo di chiave che consente a due parti, ciascuna dotata di una coppia di chiavi (pubblica e privata), di accordarsi su un segreto comune, anche quando comunicano solo attraverso un canale pubblico e non protetto.

Questo segreto condiviso (in questo caso, la chiave blu) può essere utilizzato per altre operazioni. In genere, questo segreto condiviso può essere usato per criptare e decriptare una comunicazione su una rete non protetta:

Per ottenere questo risultato, Diffie-Hellman utilizza l'aritmetica modulare per calcolare il segreto condiviso. Ecco come funziona in parole povere:

Alice e Bob si accordano su un colore comune, in questo caso il giallo, che è un dato pubblico (gli attaccanti conoscono questo colore);
Alice seleziona un colore segreto, in questo caso il rosso, e li mescola per ottenere l'arancione;
Anche Bob sceglie un colore segreto, in questo caso il blu, e lo mescola con il giallo per ottenere il verde;
Si scambiano quindi i colori risultanti, arancione e verde. Questo scambio può avvenire su una rete non sicura ed essere osservato dagli aggressori;
Mescolando il verde di Bob con il proprio colore segreto, Alice ottiene il marrone;
Bob, facendo lo stesso con l'arancione e il blu segreto di Alice, ottiene anche il marrone.

In questa divulgazione, il colore marrone rappresenta il segreto condiviso da Alice e Bob. Immaginiamo che, in realtà, sia impossibile per l'attaccante separare i colori arancione e verde per trovare i colori segreti di Alice o Bob.

Vediamo ora come funziona effettivamente questo protocollo, non con le analogie dei colori, ma utilizzando i numeri reali e l'aritmetica modulare!

Prima di addentrarci nei meccanismi di Diffie-Hellman, vorrei ricordare brevemente due concetti matematici essenziali che ci serviranno:

Un numero primo è un numero naturale che ha solo due divisori: $1$ e se stesso. Ad esempio, $7$ è un numero primo perché può essere diviso solo per $1$ e $7$ . D'altra parte, $8$ non è un numero primo, poiché è divisibile per $1$ , $2$ , $4$ e $8$ . Ha quindi quattro divisori interi positivi invece di due;
Il modulo (noto come $mod$ o $%$ ) è un'operazione matematica che, tra due numeri interi, restituisce il resto della divisione euclidea del primo per il secondo. Ad esempio, $16modulo 5 =$ 1$.

Lo scambio di chiavi Diffie-Hellman tra Alice e Bob avviene nel modo seguente:

Alice e Bob si accordano su due numeri comuni: $p$ e $g$ . $p$ è un numero primo e più grande è il numero, più sicuro sarà Diffie-Hellman. $g$ è una radice primitiva di $p$ . Questi due numeri possono essere comunicati in chiaro su una rete non protetta. Rappresentano l'equivalente del colore giallo della precedente divulgazione. È quindi importante che Alice e Bob utilizzino esattamente gli stessi valori per $p$ e $g$ .
Una volta definiti questi parametri, Alice e Bob scelgono ciascuno un numero casuale segreto. Alice chiama il suo numero casuale segreto $a$ (equivalente al colore rosso) e Bob il suo $b$ (equivalente al colore blu). Questi numeri devono rimanere segreti.
Invece di scambiarsi direttamente i numeri $a$ e $b$ , ciascuna parte calcola $A$ e $B$ come segue:

$A$ è uguale a $g$ elevato alla potenza $a$ modulo $p$ :

 $A = g^a \bmod p$

$B$ è uguale a $g$ elevato alla potenza $b$ modulo $p$ :

 $B = g^b \bmod p$

I valori $A$ (equivalente al colore arancione) e $B$ (equivalente al colore verde) vengono scambiati tra le due parti. Questo scambio può avvenire in chiaro su una rete non protetta;
Alice, dopo aver ricevuto $B$ , calcola il valore di $z$ come segue:

$z$ è uguale a $B$ elevato alla potenza $a$ modulo $p$ :

 $z = B^a \bmod p$

Un promemoria:

 $B = g^b \bmod p$

Il risultato è :

 $z = B^a \bmod p$

 $z = (g^b)^a \bmod p$

Applicando le regole del potere :

 $(x^n)^m = x^{nm}$

Il risultato è :

 $z = g^{ba} \bmod p$

Da parte sua, Bob, dopo aver ricevuto $A$ , calcola anche il valore di $z$ come segue:

$z$ è uguale ad $A$ elevato alla potenza $b$ modulo $p$ :

 $z = A^b \bmod p$

Il risultato è :

 $z = (g^a)^b \bmod p$

 $z = g^{ab} \bmod p$

 $z = g^{ba} \bmod p$

Grazie alla distributività dell'operatore modulo, Alice e Bob ottengono esattamente lo stesso valore $z$ . Questo numero rappresenta il loro segreto comune, equivalente a il colore marrone nella precedente divulgazione con i barattoli di vernice. Ora possono usare questo segreto comune per criptare simmetricamente le loro comunicazioni su una rete non protetta.

Un aggressore, anche in possesso di $p$ , $g$ , $A$ e $B$ (i valori pubblici), non sarà in grado di calcolare $a$ , $b$ o $z$ (i valori privati). Per ottenere questo risultato, bisognerebbe invertire l'esponenziazione, un'operazione impossibile senza provare tutte le possibilità una per una, poiché equivale a calcolare il logaritmo discreto, cioè il reciproco dell'esponenziale in un gruppo ciclico finito.

Quindi, finché i valori di $a$ , $b$ e $p$ sono sufficientemente grandi, il protocollo Diffie-Hellman è sicuro. In genere, con parametri di 2048 bit (un numero decimale di 600 cifre), testare tutte le possibilità per $a$ e $b$ sarebbe poco pratico. Ad oggi, con tali numeri, questo algoritmo è considerato sicuro.

Qui sta il principale inconveniente del protocollo Diffie-Hellman. Per essere sicuro, l'algoritmo deve utilizzare numeri grandi. Ecco perché oggi si preferisce utilizzare l'algoritmo ECDH (Elliptic Curve Diffie-Hellman), una variante di Diffie-Hellman basata su una curva algebrica, più precisamente una curva ellittica. Questo approccio consente di lavorare con numeri molto più piccoli mantenendo una sicurezza equivalente, riducendo così le risorse necessarie per il calcolo e la memorizzazione.

Il principio generale dell'algoritmo rimane lo stesso. Tuttavia, invece di utilizzare un numero casuale $a$ e un numero $A$ calcolato da $a$ mediante esponenziazione modulare, utilizziamo una coppia di chiavi stabilite su una curva ellittica. Invece di affidarci alla distributività dell'operatore modulo, utilizziamo la legge di gruppo sulle curve ellittiche, e più precisamente l'associatività di questa legge.

Per spiegare brevemente il principio della crittografia su curve ellittiche, una chiave privata è rappresentata da un numero casuale compreso tra $1$ e $n-1$ , dove $n$ rappresenta l'ordine della curva. La chiave pubblica, invece, è un punto specifico di questa curva, ottenuto dalla chiave privata sommando e raddoppiando i punti del punto generatore, secondo l'equazione :

 $K = k \cdot G$

In questa formula, $K$ indica la chiave pubblica, $k$ la chiave privata e $G$ il punto di generazione.

Una caratteristica essenziale di queste chiavi è la facilità con cui $K$ può essere calcolato da $k$ e $G$ , mentre è praticamente impossibile trovare $k$ da $K$ e $G$ . Questa asimmetria crea una funzione unidirezionale. In altre parole, è facile calcolare la chiave pubblica se si conosce la chiave privata, ma recuperare la chiave privata dalla chiave pubblica è impossibile. Questa sicurezza è ulteriormente sostenuta dalla difficoltà di calcolo del logaritmo discreto.

Utilizzeremo questa proprietà per adattare il nostro algoritmo Diffie-Hellman. Il principio di funzionamento dell'ECDH è il seguente:

Alice e Bob concordano una curva ellittica crittograficamente sicura e i suoi parametri. Queste informazioni sono pubbliche;
Alice genera un numero casuale $ka$ che sarà la sua chiave privata. Questa chiave privata deve rimanere segreta. Determina la sua chiave pubblica $Ka$ aggiungendo e raddoppiando punti sulla curva ellittica scelta:

 $K_a = k_a \cdot G$

Bob genera anche un numero casuale $kb$ , che sarà la sua chiave privata. Calcola la chiave pubblica associata $Kb$ :

 $K_b = k_b \cdot G$

Alice e Bob si scambiano le loro chiavi pubbliche $Ka$ e $Kb$ su una rete pubblica non protetta.
Alice calcola un punto $(x,y)$ sulla curva applicando la sua chiave privata $ka$ alla chiave pubblica $Kb$ di Bob:

 $(x,y) = k_a \cdot K_b$

Bob calcola un punto $(x,y)$ sulla curva applicando la sua chiave privata $kb$ alla chiave pubblica $Ka$ di Alice:

 $(x,y) = k_b \cdot K_a$

Alice e Bob ottengono lo stesso punto sulla curva ellittica. Il segreto condiviso sarà l'ascissa $x$ di questo punto.

Ottengono lo stesso segreto condiviso perché :

 $(x,y) = k_a \cdot K_b = k_a \cdot (k_b \cdot G) = (k_a \cdot k_b) \cdot G = (k_b \cdot k_a) \cdot G = k_b \cdot (k_a \cdot G) = k_b \cdot K_a$

Un potenziale aggressore che osservi la rete pubblica non protetta sarà in grado di ottenere solo le chiavi pubbliche di ciascun individuo e i parametri della curva ellittica scelta. Come spiegato in precedenza, queste informazioni da sole non sono sufficienti per determinare le chiavi private. Di conseguenza, l'attaccante non può trovare il segreto condiviso tra Alice e Bob.

L'ECDH è quindi un algoritmo di scambio di chiavi. Viene spesso utilizzato insieme ad altri metodi crittografici per stabilire un protocollo completo. Ad esempio, ECDH è il cuore di TLS (Transport Layer Security), un protocollo di crittografia e autenticazione utilizzato per il livello di trasporto di Internet. TLS utilizza ECDHE per lo scambio di chiavi, una variante di ECDH in cui le chiavi sono effimere, per fornire una riservatezza persistente. Inoltre, TLS utilizza algoritmi di autenticazione come ECDSA, algoritmi di crittografia come AES e funzioni di hash come SHA256.

TLS è responsabile della s in https e del lucchetto nella barra degli indirizzi del browser, simboli di comunicazioni criptate. Seguendo questo corso, utilizzerete ECDH ed è molto probabile che lo utilizziate quotidianamente senza nemmeno saperlo.

La transazione di notifica

Come abbiamo visto nella sezione precedente, ECDH è una variante dello scambio Diffie-Hellman che utilizza coppie di chiavi stabilite su una curva ellittica. È un bene che nei nostri portafogli Bitcoin ci siano già molte coppie di chiavi che rispettano questo standard! L'idea di BIP47 è quella di utilizzare le coppie di chiavi dei portafogli Bitcoin deterministici gerarchici di entrambe le parti per stabilire segreti condivisi ed effimeri tra loro. BIP47 utilizza invece ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).

ECDHE viene utilizzato per la prima volta in BIP47 per trasmettere il codice di pagamento dal mittente al destinatario. Si tratta della famosa transazione di notifica. Questo passaggio è essenziale perché, affinché BIP47 funzioni efficacemente, entrambe le parti coinvolte (mittente e destinatario) devono conoscere i rispettivi codici di pagamento. Questa conoscenza consente di ricavare le chiavi pubbliche effimere e, di conseguenza, gli indirizzi di ricezione vuoti associati.

Prima di questo scambio, il mittente è logicamente già a conoscenza del codice di pagamento del destinatario, avendolo recuperato fuori dalla catena, ad esempio dal suo sito web, dalla fattura o dai social network. Tuttavia, il destinatario non è necessariamente a conoscenza del codice di pagamento del mittente. Tuttavia, il codice deve essergli trasmesso, altrimenti non sarà in grado di ricavare le chiavi effimere necessarie per identificare gli indirizzi in cui sono memorizzati i suoi bitcoin o accedere ai suoi fondi. Sebbene questa trasmissione del codice del mittente possa tecnicamente essere effettuata fuori dalla catena con altri mezzi di comunicazione, ciò pone un problema se il portafoglio deve essere recuperato solo dal seed.

Questo perché, a differenza degli indirizzi convenzionali, gli indirizzi BIP47 non derivano direttamente dal seed del destinatario - in questo caso sarebbe più semplice utilizzare un xpub - ma risultano da un calcolo che combina i due codici di pagamento: quello del mittente e quello del destinatario. Quindi, se il destinatario perde il suo portafoglio e cerca di recuperarlo dal suo seme, recupererà il suo codice di pagamento, che deriva direttamente dal suo seme. Tuttavia, per recuperare gli indirizzi effimeri, avrà bisogno anche dei codici di pagamento di tutti coloro che gli hanno inviato bitcoin tramite BIP47. Da qui l'importanza della transazione di notifica, che permette di salvare queste informazioni sulla blockchain di Bitcoin, pur potendole trovare molto facilmente senza dover cercare tra i miliardi di transazioni eseguite dal suo lancio nel 2009.

Sarebbe quindi possibile implementare il BIP47 senza utilizzare la transazione di notifica, a condizione che ogni utente conservi un backup dei codici di pagamento dei suoi pari. Tuttavia, questo metodo si rivela complesso da gestire fino a quando non verrà sviluppata una soluzione semplice, robusta ed efficiente per creare, conservare e aggiornare questi backup. Allo stato attuale, la transazione di notifica è quasi inevitabile.

Nei capitoli successivi, tuttavia, esamineremo altri protocolli con obiettivi simili al BIP47, ma che non richiedono una transazione di notifica. Queste alternative, tuttavia, introducono dei compromessi.

Oltre al ruolo di salvataggio dei codici di pagamento, la transazione di notifica ha anche una funzione di notifica per il destinatario, come suggerisce il nome. Avverte il cliente del destinatario che è stato creato un nuovo tunnel di pagamento e gli suggerisce di tenere d'occhio gli indirizzi effimeri che ne derivano.

Il modello di riservatezza BIP47

Prima di descrivere nel dettaglio il funzionamento tecnico della transazione di notifica, è importante discutere il modello di riservatezza associato al BIP47, che giustifica alcune misure adottate nella creazione di questa transazione iniziale.

Il codice di pagamento in sé non rappresenta un rischio diretto per la riservatezza. A differenza del modello Bitcoin tradizionale, che mira a spezzare il legame tra l'identità dell'utente e le sue transazioni (che sono pubbliche) preservando l'anonimato di chiavi e indirizzi, il codice di pagamento può essere apertamente associato a un'identità senza rappresentare una minaccia.

Questo perché il codice di pagamento non viene utilizzato per ricavare direttamente gli indirizzi che ricevono i pagamenti BIP47. Questi indirizzi vengono invece generati tramite l'applicazione ECDH tra le chiavi derivate dai codici di pagamento delle due parti coinvolte.

Pertanto, un codice di pagamento di per sé non comporta direttamente una perdita di riservatezza, poiché da esso si ricava solo l'indirizzo di notifica. Sebbene questo indirizzo possa rivelare alcune informazioni, di norma non rivela le parti con cui si sta effettuando la transazione, a meno che non si effettui un'analisi approfondita della catena. Infatti, se il mittente utilizza UTXO riconducibili alla sua identità per effettuare la transazione di notifica, è possibile dedurre che la sua identità è probabilmente legata ai pagamenti BIP47 al vostro codice di pagamento. Questo non rivelerà le transazioni sottostanti, ma ne indicherà la probabile esistenza.

È quindi essenziale mantenere questa rigida separazione tra i codici di pagamento degli utenti. A questo proposito, la comunicazione iniziale del codice è un momento critico per la riservatezza del pagamento, ma essenziale per il corretto funzionamento del protocollo. Se uno dei codici di pagamento può essere ottenuto pubblicamente (ad esempio su un sito web), il secondo codice, quello del mittente, non deve in nessun caso essere collegato al primo.

Facciamo un esempio concreto: Voglio fare una donazione a un movimento politico tramite BIP47 :

L'organizzazione ha reso pubblico il codice di pagamento sul suo sito web o attraverso i suoi social network;
Questo codice è quindi legato al movimento politico;
Ricevo questo codice di pagamento ;
Prima di inviare, devo assicurarmi che conoscano il mio codice di pagamento, che è anche legato alla mia identità, poiché lo utilizzo per ricevere transazioni sui miei social network.

Come posso trasmettere il mio codice senza rischi? L'utilizzo di mezzi di comunicazione convenzionali potrebbe comportare una fuga di informazioni e quindi associarmi a questo movimento politico. La transazione di notifica offre una soluzione, grazie a uno strato di crittografia che impedisce proprio questa associazione tra due codici. Pur non essendo l'unico metodo per trasmettere segretamente il codice di pagamento del mittente, è molto efficace.

Nel diagramma sottostante, le linee arancioni indicano i punti in cui il flusso di informazioni deve essere interrotto, mentre le frecce nere mostrano le connessioni potenzialmente osservabili da terzi:

In realtà, nel modello di riservatezza tradizionale di Bitcoin, è spesso complesso dissociare completamente il flusso di informazioni tra la coppia di chiavi e l'utente, soprattutto nelle transazioni remote. Ad esempio, nel contesto di una campagna di donazione, il destinatario deve inevitabilmente rivelare un indirizzo o una chiave pubblica attraverso il proprio sito web o i social network. L'uso corretto di BIP47, in particolare con la transazione di notifica, permette di aggirare questo problema grazie a ECDHE e al livello di crittografia che vedremo in seguito.

Naturalmente, il modello di riservatezza classico di Bitcoin si applica ancora alle chiavi pubbliche effimere, che derivano dalla combinazione dei due codici di pagamento. I due modelli sono infatti complementari. Quello che voglio sottolineare qui è che, a differenza dell'uso abituale di una chiave pubblica per ricevere Bitcoin, il codice di pagamento può essere collegato a un'identità specifica, poiché l'informazione "Alice sta effettuando una transazione con Bob" viene interrotta in un'altra fase. Il codice di pagamento viene utilizzato per generare gli indirizzi di pagamento, ma in base alla sola osservazione della blockchain, è impossibile collegare una transazione di pagamento BIP47 ai codici di pagamento utilizzati per eseguirla, a meno che gli UTXO coinvolti non siano già stati collegati a un'identità in precedenza e gli utenti abbiano associato i loro codici di pagamento alle rispettive identità.

In sintesi, il modello di riservatezza offerto dai pagamenti BIP47 potrebbe essere considerato superiore al modello di base di Bitcoin, anche se questo non significa che sia magico.

Creazione della transazione di notifica

Vediamo ora come funziona questa transazione di notifica. Immaginiamo che Alice voglia inviare fondi a Bob utilizzando il BIP47. Nel mio esempio, Alice agisce come mittente e Bob come destinatario. Bob ha pubblicato il suo codice di pagamento sul suo sito web. Alice conosce quindi già il codice di pagamento di Bob.

1- Alice calcola il segreto condiviso con ECDH :

L'utente seleziona una coppia di chiavi dal suo portafoglio HD su un ramo diverso dal suo codice di pagamento. Si noti che questa coppia non deve essere facilmente associabile all'indirizzo di notifica di Alice, né all'identità di Alice (si veda la sezione precedente);
Alice sceglie la chiave privata per questa coppia. La chiamiamo $a$ (minuscolo);

$a$

Alice recupera la chiave pubblica associata all'indirizzo di notifica di Bob. Questa chiave è il primo figlio derivato dal codice di pagamento di Bob (indice $/0$ ). Chiamiamo questa chiave pubblica $B$ (maiuscolo). La chiave privata associata a questa chiave pubblica si chiama $b$ (minuscolo). $B$ si determina sommando e raddoppiando i punti della curva ellittica a partire da $G$ (il punto generatore) con $b$ (la chiave privata):

$B = b \cdot G$

Alice calcola un punto segreto $S$ (maiuscolo) sulla curva ellittica aggiungendo e raddoppiando i punti, applicando la sua chiave privata $a$ alla chiave pubblica $B$ di Bob.

$S = a \cdot B$

Alice calcola il fattore di accecamento $f$ che verrà utilizzato per crittografare il suo codice di pagamento. Per farlo, utilizza la funzione HMAC-SHA512 per determinare un numero pseudocasuale. Il secondo input di questa funzione è un valore che solo Bob sarà in grado di trovare: $x$ , che è l'ascissa del punto segreto calcolato sopra. Il primo ingresso è $o$ , che è l'UTXO consumato come input di questa transazione (outpoint).

$f = \text{HMAC-SHA512}(o, x)$

**2 - Alice converte il proprio codice di pagamento personale in base 2 (binario) **

3- Utilizza questo fattore di accecamento come chiave per eseguire una crittografia simmetrica sul carico utile del suo codice di pagamento. L'algoritmo di crittografia utilizzato è semplicemente un XOR. L'operazione eseguita è paragonabile al cifrario di Vernam, noto anche come "One-Time Pad".

Alice divide innanzitutto il suo fattore di accecamento in due: i primi 32 byte sono denominati $f1$ e gli ultimi 32 byte sono denominati $f2$ . In questo modo si ottiene :

$f = f1 || f2$

Alice calcola separatamente il cifrario $x'$ dell'ascissa della chiave pubblica $x$ del suo codice di pagamento e il cifrario $c'$ del suo codice stringa $c$ . $f1$ e $f2$ fungono rispettivamente da chiavi di cifratura. L'operazione utilizzata è XOR (o esclusiva).

$x' = x \oplus f1$

$c' = c \oplus f2$

Alice sostituisce i valori reali dell'ascissa della chiave pubblica $x$ e del codice stringa $c$ nel suo codice di pagamento con i valori criptati $x'$ e $c'$ .

4- Alice ha quindi il suo codice di pagamento con un payload criptato. Costruirà e trasmetterà una transazione con la sua chiave pubblica $A$ come input, un output all'indirizzo di notifica di Bob e un output OP_RETURN che consiste nel suo codice di pagamento con il payload criptato. Questa transazione è la transazione di notifica.

Un OP_RETURN è un codice operativo che contrassegna l'uscita di una transazione Bitcoin come non valida. Oggi viene utilizzato per trasmettere o ancorare informazioni sulla blockchain Bitcoin. Può memorizzare fino a 80 byte di dati, che vengono poi scritti sulla catena e sono visibili a tutti gli altri utenti.

Come abbiamo visto nelle sezioni precedenti, ECDH viene utilizzato per generare un segreto condiviso tra due utenti che comunicano su una rete insicura e potenzialmente osservabile dagli aggressori. In BIP47, l'ECDH viene utilizzato per comunicare sulla rete Bitcoin, che per sua natura è una rete di comunicazione trasparente e viene osservata da molti aggressori. Il segreto condiviso calcolato attraverso lo scambio di chiavi ECDH viene poi utilizzato per crittografare le informazioni segrete da trasmettere: il codice di pagamento del mittente (Alice).

Riassumerò insieme i passaggi appena visti per effettuare una transazione di notifica:

Alice recupera il codice di pagamento e l'indirizzo di notifica di Bob;
Alice seleziona un UTXO dal suo portafoglio HD con la coppia di chiavi corrispondente;
Calcola un punto segreto sulla curva ellittica utilizzando ECDH ;
Utilizza questo punto segreto per calcolare un HMAC, che è il fattore di blocco;
Utilizza questo fattore di accecamento per criptare il payload del suo codice di pagamento personale;
Utilizza un output di transazione OP_RETURN per comunicare il codice di pagamento nascosto a Bob.

Notifica di transazione: uno studio pratico

Per capire meglio come funziona, e in particolare l'uso di OP_RETURN, diamo un'occhiata a una vera transazione di notifica. Ho eseguito una transazione di questo tipo sulla testnet, che potete trovare [cliccando qui] (https://mempool.space/fr/testnet/tx/0e2e4695a3c49272ef631426a9fd2dae6ec3a469e3a39a3db51aa476cd09de2e).

Osservando questa transazione, possiamo già notare che ha un singolo ingresso e 4 uscite:

Il primo output è OP_RETURN che contiene il mio codice di pagamento nascosto;
La seconda uscita di 546 satelliti punta all'indirizzo di notifica del mio destinatario;
Il terzo output di 15.000 sats rappresenta la commissione per il servizio, poiché ho utilizzato Samourai Wallet per effettuare questa transazione;
Il quarto output di 2 milioni di satelliti rappresenta il tasso di scambio, cioè la differenza rimanente nel mio input che ritorna a un altro indirizzo che mi appartiene.

Il più interessante da studiare è ovviamente l'output 0 utilizzando OP_RETURN. Diamo un'occhiata più da vicino a ciò che contiene. Ecco la scriptPubKey in esadecimale:

6a4c50010002b13b2911719409d704ecc69f74fa315a6cb20fdd6ee39bc9874667703d67b164927b0e88f89f3f8b963549eab2533b5d7ed481a3bea7e953b546b4e91b6f50d800000000000000000000000000

Questo script è composto da diverse parti. In primo luogo, il file :

6a4c

Tra gli opcode, possiamo riconoscere 0x6a che designa l' OP_RETURN e 0x4c che designa l' OP_PUSHDATA1.

Il byte che segue quest'ultimo opcode indica la dimensione del payload successivo. Indica 0x50, ovvero 80 byte:

6a4c50

Poi, abbiamo i metadati del mio codice di pagamento in chiaro:

L'ascissa criptata della chiave pubblica del mio codice di pagamento :

b13b2911719409d704ecc69f74fa315a6cb20fdd6ee39bc9874667703d67b164

Il codice stringa criptato del mio codice di pagamento :

927b0e88f89f3f8b963549eab2533b5d7ed481a3bea7e953b546b4e91b6f50d8

Infine, il padding a 80 byte, la dimensione standard di un OP_RETURN:

00000000000000000000000000

Per aiutarvi a capire, ecco il mio codice di pagamento in chiaro in base 58 :

PM8TJQCyt6ovbozreUCBrfKqmSVmTzJ5vjqse58LnBzKFFZTwny3KfCDdwTqAEYVasn11tTMPc2FJsFygFd3YzsHvwNXLEQNADgxeGnMK8Ugmin62TZU

E in base 16 :

4701000277507c9c17a89cfca2d3af554745d6c2db0e7f6b2721a3941a504933103cc42add94881210d6e752a9abc8a9fa0070e85184993c4f643f1121dd807dd556d1dc000000000000000000000000008604e4db

Se confrontiamo il mio codice di pagamento in chiaro con l'OP_RETURN, possiamo vedere che l'HRP (0x47) e il checksum (0x8604e4db) non vengono trasmessi. Questo è normale, poiché queste informazioni sono destinate all'uomo.

Poi, possiamo riconoscere la versione (0x01), il campo di bit (0x00) e la parità della chiave pubblica (0x02). E, alla fine del codice di pagamento, i byte vuoti (0x0000000000000000000000) che consentono un padding per raggiungere un totale di 80 byte. Tutti questi metadati vengono trasmessi in chiaro.

Infine, possiamo osservare che l'ascissa della chiave pubblica (0x77507c9c17a89cfca2d3af554745d6c2db0e7f6b2721a3941a504933103cc42a) e il codice stringa (0xdd94881210d6e752a9abc8a9fa0070e85184993c4f643f1121dd807dd556d1dc) sono stati criptati. Questo è il payload del codice di pagamento.

Che cos'è lo XOR?

Nelle sezioni precedenti abbiamo visto che il codice di pagamento viene trasmesso criptato utilizzando l'operazione XOR. Vediamo più da vicino come funziona questo operatore, ampiamente utilizzato in crittografia.

XOR è un operatore logico bitwise basato sull'algebra booleana. Dati due operandi in bit, restituisce 1 se i bit dello stesso rango sono diversi e restituisce 0 se i bit dello stesso rango sono uguali. Ecco la tabella di verità XOR in base ai valori degli operandi D e E :

| D | E | D XOR E |

| --- | --- | ------- |

| 0 | 0 | 0 |

| 0 | 1 | 1 |

| 1 | 0 | 1 |

| 1 | 1 | 0 |

Ad esempio:

 $0110 \oplus 1110 = 1000$

Oppure :

 $010011 \oplus 110110 = 100101$

Con ECDH, l'uso di XOR come livello di crittografia è particolarmente coerente. In primo luogo, grazie a questo operatore, la crittografia è simmetrica. Ciò significa che il destinatario può decifrare il codice di pagamento con la stessa chiave utilizzata per la crittografia. Le chiavi di crittografia e decrittografia sono calcolate a partire dal segreto condiviso mediante ECDH. Questa simmetria è resa possibile dalle proprietà di commutatività e associatività dell'operatore XOR:

Altre proprietà :

 $D \oplus D = 0$

 $D \oplus 0 = D$

Commutatività :

 $D \oplus E = E \oplus D$

Associatività :

 $D \oplus (E \oplus Z) = (D \oplus E) \oplus Z = D \oplus E \oplus Z$

Se :

 $D \oplus E = L$

Poi :

 $D \oplus L = D \oplus (D \oplus E) = D \oplus D \oplus E = 0 \oplus E = E \\ \therefore D \oplus L = E$

In secondo luogo, questo metodo di crittografia è molto simile al cifrario di Vernam (One-Time Pad), l'unico algoritmo di crittografia finora conosciuto che ha una sicurezza incondizionata (o assoluta). Perché il cifrario di Vernam abbia questa caratteristica, la chiave di crittografia deve essere perfettamente casuale, della stessa dimensione del messaggio e utilizzata una sola volta. Nel metodo di cifratura qui utilizzato per il BIP47, la chiave è effettivamente della stessa dimensione del messaggio e il fattore di accecamento è esattamente della stessa dimensione della concatenazione dell'ascissa della chiave pubblica con la stringa del codice di pagamento. Questa chiave di crittografia viene utilizzata una sola volta. D'altra parte, questa chiave non deriva da una perfetta casualità, poiché si tratta di un HMAC. È piuttosto pseudocasuale. Non si tratta quindi di un cifrario di Vernam, ma il metodo ci si avvicina.

Ricezione della transazione di notifica

Ora che Alice ha inviato la transazione di notifica a Bob, vediamo come Bob la interpreta. Come promemoria, Bob deve avere accesso al codice di pagamento di Alice. Senza questa informazione, come vedremo nella prossima sezione, non sarà in grado di ricavare le coppie di chiavi create da Alice e quindi non potrà accedere ai bitcoin ricevuti tramite BIP47. Per il momento, il payload del codice di pagamento di Alice è criptato. Vediamo come Bob lo decifra.

1- Bob monitora le transazioni che creano uscite con il suo indirizzo di notifica.

2- Quando una transazione ha un'uscita sul suo indirizzo di notifica, Bob la analizza per vedere se contiene un'uscita OP_RETURN conforme allo standard BIP47.

3- Se il primo byte del payload OP_RETURN è 0x01, Bob inizia la ricerca di un possibile segreto condiviso con ECDH :

Bob seleziona la chiave pubblica di ingresso per la transazione. Ovvero, la chiave pubblica di Alice denominata $A$ con :

$A = a \cdot G$

Bob seleziona la chiave privata $b$ associata al suo indirizzo di notifica personale :

$b$

Bob calcola il punto segreto $S$ (segreto condiviso ECDH) sulla curva ellittica aggiungendo e raddoppiando i punti, applicando la sua chiave privata $b$ alla chiave pubblica di Alice $A$ :

$S = b \cdot A$

Bob determina il fattore di accecamento $f$ che consentirà di decifrare il payload del codice di pagamento di Alice. Allo stesso modo in cui Alice lo aveva calcolato in precedenza, Bob troverà $f$ applicando HMAC-SHA512 a $x$ , il valore di ascissa del punto segreto $S$ , e a $o$ , l'UTXO consumato come input di questa operazione di notifica:

$f = \text{HMAC-SHA512}(o, x)$

4- Bob interpreta i dati OP_RETURN della transazione di notifica come un codice di pagamento. Decodificherà semplicemente il payload di questo potenziale codice di pagamento utilizzando il fattore di accecamento $f$ :

Bob divide il fattore di accecamento $f$ in due parti: i primi 32 byte di $f$ saranno $f1$ e gli ultimi 32 byte saranno $f2$ ;
Bob decifra il valore dell'ascissa criptata $x'$ dalla chiave pubblica del codice di pagamento di Alice:

$x = x' \oplus f1$

Bob decifra il valore del codice stringa criptato $c'$ dal codice di pagamento di Alice:

$c = c' \oplus f2$

5- Bob controlla se il valore della chiave pubblica del codice di pagamento di Alice fa parte del gruppo secp256k1. In caso affermativo, lo interpreta come un codice di pagamento valido. In caso contrario, ignora la transazione.

Ora che Bob conosce il codice di pagamento di Alice, Alice può inviargli fino a 2^32 pagamenti, senza dover mai ripetere una transazione di notifica di questo tipo.

Perché funziona? Come può Bob determinare lo stesso fattore di accecamento di Alice e quindi decifrare il suo codice di pagamento? Esaminiamo più da vicino l'azione di ECDH in ciò che abbiamo appena descritto.

Innanzitutto, si tratta di una crittografia simmetrica. Ciò significa che la chiave di crittografia e la chiave di decrittografia hanno lo stesso valore. Questa chiave nella transazione di notifica è il fattore di accecamento:

$f = f1 || f2$

Alice e Bob devono quindi ottenere lo stesso valore per $f$ , senza trasmetterlo direttamente, poiché un aggressore potrebbe rubarlo e decifrare le informazioni segrete. Questo fattore di accecamento si ottiene applicando HMAC-SHA512 a 2 valori:

l'ascissa di un punto segreto ;
e l'UTXO consumato all'ingresso della transazione.

Bob ha quindi bisogno di entrambe le informazioni per decriptare il payload del codice di pagamento di Alice. Per l'UTXO di ingresso, Bob può semplicemente recuperarlo osservando la transazione di notifica. Per il punto segreto, Bob dovrà utilizzare ECDH. Come visto nella sezione precedente su Diffie-Hellman, semplicemente scambiando le rispettive chiavi pubbliche e applicando segretamente le loro chiavi private alla chiave pubblica dell'altro, Alice e Bob possono trovare un punto segreto preciso sulla curva ellittica. La transazione di notifica si basa su questo meccanismo:

Coppia di chiavi di Bob :

$B = b \cdot G$

Coppia di chiavi di Alice :

$A = a \cdot G$

Per un segreto $S (x, y)$ :

$S = a \cdot B = a \cdot (b \cdot G) = (b \cdot a) \cdot G = b \cdot A$

Ora che Bob conosce il codice di pagamento di Alice, sarà in grado di individuare i suoi pagamenti BIP47 e di ricavare le chiavi private che bloccano i bitcoin ricevuti.

Riassumerò insieme i passaggi appena visti per ricevere e interpretare una transazione di notifica:

Bob controlla l'output della transazione al suo indirizzo di notifica;
Quando ne rileva uno, recupera le informazioni contenute in OP_RETURN ;
Bob seleziona la chiave pubblica come input e calcola un punto segreto utilizzando ECDH ;
Utilizza questo punto segreto per calcolare l'HMAC, che è il fattore di blocco;
Utilizza questo fattore di accecamento per decifrare il payload del codice di pagamento di Alice contenuto nell'OP_RETURN.

L'operazione di pagamento BIP47

Diamo un'occhiata al processo di pagamento con BIP47. Per ricordare la situazione attuale :

Alice conosce il codice di pagamento di Bob, che ha semplicemente recuperato dal suo sito web;
Bob conosce il codice di pagamento di Alice dalla transazione di notifica;
Alice effettuerà il primo pagamento a Bob. Può effettuarne molti altri nello stesso modo.

Prima di spiegare questo processo, credo sia importante ricordare su quali indici stiamo attualmente lavorando. Il percorso di derivazione di un codice di pagamento è descritto come segue: m/47'/0'/0'. La profondità seguente divide gli indici come segue:

La prima coppia di figlie normali (non rinforzate) è quella utilizzata per generare l'indirizzo di notifica discusso nella sezione precedente: m/47'/0'/0'/0 ;
Le normali coppie di chiavi figlie sono utilizzate all'interno di ECDH per generare gli indirizzi delle ricevute di pagamento BIP47, come vedremo in questa sezione: da m/47'/0'/0'/0 a m/47'/0'/0'/2.147.483.647 ;
Le coppie di chiavi figlia rinforzate sono codici di pagamento effimeri: da m/47'/0'/0'/0' a m/47'/0'/0'/2.147.483.647'.

Ogni volta che Alice vuole inviare un pagamento a Bob, ricava un nuovo indirizzo univoco e vuoto, ancora una volta utilizzando il protocollo ECDH:

Alice seleziona la prima chiave privata derivata dal suo codice di pagamento personale riutilizzabile :

$a$

Alice seleziona la prima chiave pubblica non utilizzata derivata dal codice di pagamento di Bob. Chiameremo questa chiave pubblica $B$ . È associata alla chiave privata $b$ nota solo a Bob:

$B = b \cdot G$

Alice calcola un punto segreto $S$ sulla curva ellittica aggiungendo e raddoppiando punti applicando la sua chiave privata $a$ alla chiave pubblica $B$ di Bob:

$S = a \cdot B$

Da questo punto segreto, Alice calcola il segreto condiviso $s$ (minuscolo). Per farlo, seleziona l'ascissa del punto segreto $S$ denominata $Sx$ e passa questo valore alla funzione hash SHA256:

$S = (Sx, Sy)$

$s = \text{SHA256}(Sx)$

Alice utilizza il segreto condiviso $s$ per calcolare l'indirizzo di ricezione di un pagamento Bitcoin. Innanzitutto, controlla che $s$ sia contenuto nell'ordine della curva secp256k1 . In caso contrario, incrementa l'indice della chiave pubblica di Bob per ricavare un altro segreto condiviso;
In una seconda fase, calcola una chiave pubblica $K0$ sommando i punti $B$ e $s-G$ sulla curva ellittica. In altre parole, Alice aggiunge la chiave pubblica derivata dal codice di pagamento di Bob $B$ a un altro punto calcolato sulla curva ellittica aggiungendo e raddoppiando i punti con il segreto condiviso $s$ dal punto generatore della curva secp256k1 $G$ . Questo nuovo punto rappresenta una chiave pubblica, che chiamiamo $K0$ :

$K0 = B + s \cdot G$

Con questa chiave pubblica $K0$ , Alice può ricavare un indirizzo di ricezione vuoto nel modo standard (ad esempio SegWit V0 in bech32).

Una volta ottenuto l'indirizzo di ricezione $K0$ di Bob, Alice può effettuare una transazione Bitcoin nel modo standard. Per farlo, sceglie un UTXO di sua proprietà, garantito da una coppia di chiavi di un altro ramo del suo portafoglio HD, e lo consuma per soddisfare un'uscita all'indirizzo $K0$ di Bob. È importante notare che questo pagamento, una volta ricavato l'indirizzo, segue un processo classico e non dipende più dalle chiavi associate al BIP47.

Riassumerò insieme i passaggi appena visti per inviare un pagamento BIP47:

Alice seleziona la prima chiave privata figlia derivata dal suo codice di pagamento personale ;
Calcola un punto segreto sulla curva ellittica utilizzando ECDH dalla prima chiave pubblica figlia inutilizzata derivata dal codice di pagamento di Bob;
Utilizza questo punto segreto per calcolare un segreto condiviso con SHA256 ;
Utilizza questo segreto condiviso per calcolare un nuovo punto segreto sulla curva ellittica;
Aggiunge questo nuovo punto segreto alla chiave pubblica di Bob;
Ottiene una nuova chiave pubblica effimera di cui solo Bob possiede la chiave privata associata;
Alice può effettuare una transazione classica verso Bob con l'indirizzo di ricezione effimero derivato.

Se Alice vuole effettuare un secondo pagamento, seguirà la stessa procedura, ma questa volta selezionerà la seconda chiave pubblica derivata dal codice di pagamento di Bob. In particolare, utilizzerà la prossima chiave non utilizzata. Otterrà così un nuovo indirizzo di ricezione appartenente a Bob, denominato $K1$ :

Può continuare in questo modo e ricavare fino a 2^32 indirizzi vuoti appartenenti a Bob.

Da una prospettiva esterna, guardando la blockchain, è teoricamente impossibile distinguere un pagamento BIP47 da un pagamento convenzionale. Ecco un esempio di transazione di pagamento BIP47 su Testnet:

94b2e59510f2e1fa78411634c98a77bbb638e28fb2da00c9f359cd5fc8f87254

Sembra una transazione classica con un input consumato, un output di pagamento e un tasso di cambio:

Ricezione del pagamento BIP47 e derivazione della chiave privata

Alice ha appena effettuato il suo primo pagamento a un indirizzo BIP47 vuoto appartenente a Bob. Vediamo ora come Bob riceve questo pagamento. Vedremo anche perché Alice non ha accesso alla chiave privata dell'indirizzo che ha appena generato e come Bob trova questa chiave per spendere i bitcoin appena ricevuti.

Non appena Bob riceve la transazione di notifica da Alice, ricava la chiave pubblica BIP47 $K0$ anche prima che il suo corrispondente abbia inviato il pagamento. Osserva quindi qualsiasi pagamento all'indirizzo associato. Anzi, ricava immediatamente diversi indirizzi che osserva ( $K0$ , $K1$ , $K2$ , $K3$ ...). Ecco come deriva la chiave pubblica $K0$ :

Bob seleziona la prima chiave privata figlia derivata dal suo codice di pagamento. Questa chiave privata è denominata $b$ . È associata alla chiave pubblica $B$ con cui Alice ha effettuato i calcoli nel passaggio precedente:

$b$

Bob seleziona la prima chiave pubblica di Alice derivata dal suo codice di pagamento. Questa chiave è denominata $A$ . È associata alla chiave privata $a$ con cui Alice ha effettuato i calcoli e che è nota solo ad Alice. Bob può eseguire questo processo perché conosce il codice di pagamento di Alice, che gli è stato inviato con la transazione di notifica:

$A = a \cdot G$

Bob calcola il punto segreto $S$ , aggiungendo e raddoppiando punti sulla curva ellittica, applicando la sua chiave privata $b$ alla chiave pubblica $A$ di Alice. Anche in questo caso, l'ECDH viene utilizzato per garantire che il punto $S$ sia lo stesso sia per Bob che per Alice:

$S = b \cdot A$

Allo stesso modo di Alice, Bob isola l'ascissa di questo punto $S$ . Abbiamo chiamato questo valore $Sx$ . Passa questo valore alla funzione SHA256 per trovare il segreto condiviso $s$ (minuscolo):

$s = \text{SHA256}(Sx)$

Allo stesso modo di Alice, Bob calcola il punto $s-G$ sulla curva ellittica. Aggiunge quindi questo punto segreto alla sua chiave pubblica $B$ . Ottiene quindi un nuovo punto sulla curva ellittica, che interpreta come chiave pubblica $K0$ :

$K0 = B + s \cdot G$

Una volta che Bob ha questa chiave pubblica $K0$ , può ricavare la chiave privata associata per spendere i suoi bitcoin. Solo lui può generare questa chiave privata:

Bob somma la chiave privata di sua figlia $b$ derivata dal suo codice di pagamento personale. Solo lui può ottenere il valore di $b$ . Quindi aggiunge $b$ al segreto condiviso $s$ per ottenere $k0$ , la chiave privata di $K0$ :

$k0 = b + s$

Grazie alla legge di gruppo della curva ellittica, Bob ottiene esattamente la chiave privata corrispondente alla chiave pubblica utilizzata da Alice. Si ha quindi :

$K0 = k0 \cdot G$

Riassumerò insieme i passaggi appena visti per ricevere un pagamento BIP47 e calcolare la chiave privata corrispondente:

Bob seleziona la prima chiave privata figlia derivata dal suo codice di pagamento personale ;
Calcola un punto segreto sulla curva ellittica usando ECDH dalla prima chiave pubblica figlia derivata dal codice stringa di Alice;
Utilizza questo punto segreto per calcolare un segreto condiviso con SHA256 ;
Utilizza questo segreto condiviso per calcolare un nuovo punto segreto sulla curva ellittica;
Aggiunge questo nuovo punto segreto alla sua chiave pubblica personale;
Ottiene una nuova chiave pubblica effimera, quella a cui Alice invierà il primo pagamento;
Bob calcola la chiave privata associata a questa chiave pubblica effimera aggiungendo la sua chiave privata figlia derivata dal suo codice di pagamento e il segreto condiviso.

Poiché Alice non può ottenere $b$ (la chiave privata di Bob), non è in grado di determinare $k0$ (la chiave privata associata all'indirizzo di ricezione BIP47 di Bob). Schematicamente, possiamo rappresentare il calcolo del segreto condiviso $S$ come segue:

Una volta trovato il segreto condiviso con ECDH, Alice e Bob calcolano la chiave pubblica di pagamento BIP47 $K0$ e Bob calcola anche la chiave privata associata $k0$ :

Rimborso del pagamento BIP47

Poiché Bob conosce il codice di pagamento riutilizzabile di Alice, ha già tutte le informazioni necessarie per inviarle un rimborso. Non avrà bisogno di contattare nuovamente Alice per chiederle alcuna informazione. Deve semplicemente informarla con una transazione di notifica, in modo che possa recuperare i suoi indirizzi BIP47 con il suo seme, e poi può anche inviarle fino a 2^32 pagamenti.

La funzione di rimborso è specifica di BIP47 ed è uno dei suoi vantaggi rispetto ad altri metodi, come i pagamenti silenziosi, che verranno analizzati nei capitoli successivi.

Bob può quindi rimborsare Alice nello stesso modo in cui lei gli ha inviato i pagamenti. I ruoli sono invertiti:

*Un sentito ringraziamento a Fanis Michalakis per la sua correzione di bozze e per i suoi consigli sull'articolo che ha ispirato la stesura di questo capitolo!

https://planb.network/tutorials/privacy/on-chain/paynym-bip47-a492a70b-50eb-4f95-a766-bae2c5535093

Pagamenti silenziosi

BIP47 è stato ampiamente criticato per la sua inefficienza sulla catena. Come spiegato nel capitolo precedente, richiede l'esecuzione di una transazione di notifica per ogni nuovo destinatario. Questo vincolo diventa trascurabile se si intende stabilire un canale di pagamento sostenibile con questo destinatario. Infatti, una singola transazione di notifica apre la strada a un numero quasi infinito di pagamenti BIP47 successivi.

Tuttavia, in alcune situazioni, la transazione di notifica può rappresentare un ostacolo per l'utente. Prendiamo l'esempio di una donazione una tantum a un beneficiario: con un indirizzo Bitcoin classico, una sola transazione è sufficiente per completare la donazione. Con BIP47, invece, sono necessarie due transazioni: una per la notifica e una per il pagamento vero e proprio. Quando la domanda di spazio per i blocchi è bassa e le commissioni di transazione sono basse, questo passaggio in più non rappresenta di solito un problema. Tuttavia, in tempi di congestione, le commissioni di transazione possono diventare esorbitanti per un singolo pagamento, raddoppiando potenzialmente il costo per l'utente rispetto a una transazione Bitcoin standard, il che può risultare inaccettabile per l'utente.

Per le situazioni in cui l'utente intende effettuare solo pochi pagamenti a un identificatore statico, sono state sviluppate altre soluzioni. Tra queste c'è Silent Payments, descritto in BIP352. Questo protocollo consente di utilizzare un identificatore statico per ricevere pagamenti senza produrre riutilizzi di indirizzi e senza richiedere l'uso di transazioni di notifica. Vediamo come funziona questo protocollo.

Per comprendere appieno questo capitolo, è essenziale padroneggiare il funzionamento di ECDH (Elliptic Curve Diffie-Hellman) e la derivazione delle chiavi crittografiche in un portafoglio HD. Questi concetti sono stati trattati in dettaglio nel capitolo precedente su BIP47. Non li ripeterò qui. Se non avete ancora familiarità con questi concetti, vi consiglio di consultare il capitolo precedente prima di continuare con questo. Non tornerò sui rischi associati al riutilizzo degli indirizzi di ricezione, né sull'importanza di avere un identificatore unico per la ricezione dei pagamenti

Perché non spostare la notifica?

Come discusso nel capitolo BIP47, la transazione di notifica ha due funzioni principali:

Notifica al destinatario ;
Trasmette il codice di pagamento del mittente.

Si potrebbe ingenuamente pensare che questo processo di notifica possa essere effettuato fuori dalla catena. In teoria, è perfettamente fattibile: tutto ciò che il destinatario dovrebbe fare è indicare un mezzo di comunicazione per ricevere i codici di pagamento BIP47 dai mittenti. Tuttavia, questo approccio presenta due problemi principali:

In primo luogo, il processo di trasmissione dei codici verrebbe trasferito a un altro protocollo di comunicazione. I problemi relativi al costo e alla riservatezza dello scambio rimarrebbero, ma verrebbero semplicemente trasferiti a questo nuovo protocollo. In termini di riservatezza, questo potrebbe anche creare un legame tra l'identità di un utente e l'attività sulla blockchain, che è ciò che cerchiamo di evitare eseguendo la notifica direttamente sulla blockchain. Inoltre, rendere la notifica esterna alla blockchain introdurrebbe rischi di censura (come il blocco dei fondi) che non esistono su Bitcoin;
In secondo luogo, questo porrebbe un problema di recupero. Con BIP47, il destinatario deve conoscere i codici di pagamento dei mittenti per poter accedere ai fondi. Questo vale al momento della ricezione, ma anche nel caso in cui i fondi vengano recuperati tramite il seed se il portafoglio viene perso. Con le notifiche onchain, questo rischio è evitato, in quanto l'utente può recuperare e decriptare le transazioni di notifica semplicemente conoscendo il suo seed. Tuttavia, se la notifica viene effettuata al di fuori della blockchain, l'utente dovrebbe mantenere un backup dinamico di tutti i codici di pagamento ricevuti, cosa poco pratica per l'utente medio.

Tutti questi vincoli rendono l'uso della notifica onchain essenziale per BIP47. Tuttavia, i pagamenti silenziosi cercano di evitare questa fase di notifica onchain proprio a causa del suo costo. La soluzione adottata non è quindi quella di spostare la notifica, ma di eliminarla del tutto. Per raggiungere questo obiettivo, è necessario accettare un compromesso: la scansione. A differenza di BIP47, dove l'utente sa esattamente dove trovare i suoi fondi grazie alle transazioni di notifica, con Silent Payments l'utente deve esaminare tutte le transazioni Bitcoin esistenti per individuare i pagamenti a lui destinati. Per ridurre questo onere operativo, la ricerca di Silent Payments è limitata solo alle transazioni che potrebbero contenere tali pagamenti, ovvero quelle con almeno un'uscita Taproot P2TR. Inoltre, la scansione si concentra esclusivamente sulle transazioni a partire dalla data di creazione del portafoglio (non è necessario analizzare le transazioni risalenti al 2009 se il portafoglio è stato creato nel 2024).

Si può quindi capire perché BIP47 e Silent Payments, pur avendo un obiettivo simile, comportano compromessi diversi e quindi rispondono effettivamente a casi d'uso distinti. Per i pagamenti una tantum, come ad esempio le donazioni una tantum, i Silent Payment sono più adatti grazie al loro costo inferiore. D'altro canto, per le transazioni regolari verso lo stesso destinatario, come nel caso delle piattaforme di scambio o dei pool minerari, può essere preferito il BIP47.

Diamo un'occhiata al funzionamento tecnico dei pagamenti silenziosi per capire meglio la posta in gioco. A tal fine, suggerisco di adottare lo stesso approccio del documento esplicativo BIP352. Scomporremo gradualmente i calcoli da effettuare, elemento per elemento, giustificando ogni nuova aggiunta.

Alcuni concetti da capire

Prima di iniziare, è importante sottolineare che Silent Payments si basa esclusivamente sull'uso di tipi di script P2TR (Pay to Taproot). A differenza del BIP47, non è necessario ricavare gli indirizzi dei destinatari dalle chiavi pubbliche dei bambini tramite hashing. Nello standard P2TR, la chiave pubblica modificata viene utilizzata direttamente e non criptata nell'indirizzo. Quindi un indirizzo di ricezione Taproot è essenzialmente una chiave pubblica con alcuni metadati. Questa chiave pubblica modificata è l'aggregazione di altre due chiavi pubbliche: una che consente la spesa diretta e tradizionale tramite una semplice firma, e l'altra che rappresenta la radice Merkle del MAST, che autorizza la spesa a condizione che sia soddisfatta una delle condizioni potenzialmente inscritte nell'albero Merkle.

La decisione di limitare Silent Payments esclusivamente a Taproot è dovuta a due motivi principali:

In primo luogo, facilita notevolmente l'implementazione e gli aggiornamenti futuri del software di portafoglio, poiché deve essere rispettato un solo standard;
In secondo luogo, questo approccio contribuisce a migliorare l'anonset degli utenti, incoraggiandoli a non dividersi tra diversi tipi di script, che generano impronte digitali di portafoglio distinte nell'analisi della catena (per maggiori informazioni su questo concetto, si rimanda al capitolo 4 della parte 2).

Derivazione ingenua di una chiave pubblica per i pagamenti silenziosi

Partiamo da un semplice esempio per capire come funzionano gli SP (Silent Payments). Prendiamo Alice e Bob, due utenti Bitcoin. Alice desidera inviare Bitcoin a Bob su un indirizzo di ricezione vuoto. Gli obiettivi di questo processo sono tre:

Alice deve essere in grado di generare un indirizzo vuoto;
Bob deve essere in grado di identificare un pagamento inviato a questo specifico indirizzo;
Bob deve poter ottenere la chiave privata associata a questo indirizzo per poter spendere i suoi fondi.

Alice ha un UTXO nel suo portafoglio Bitcoin sicuro con la seguente coppia di chiavi:

$a$ : la chiave privata ;
$A$ : la chiave pubblica ( $A = a \cdot G$ )

Bob ha un indirizzo SP che ha pubblicato su Internet con :

$b$ : la chiave privata ;
$B$ : la chiave pubblica ( $B = b \cdot G$ )

Recuperando l'indirizzo di Bob, Alice è in grado di calcolare un nuovo indirizzo vuoto che appartiene a Bob utilizzando ECDH. Chiamiamo questo indirizzo $P$ :

$P = B + ´testo{hash}(a \cdot B) \cdot G$

In questa equazione, Alice ha semplicemente calcolato il prodotto scalare della sua chiave privata $a$ e della chiave pubblica di Bob $B$ . Ha passato il risultato in una funzione di hash nota a tutti. Il valore risultante viene poi moltiplicato scalarmente per il punto di generazione $G$ della curva ellittica secp256k1. Infine, Alice aggiunge il punto risultante alla chiave pubblica di Bob $B$ . Una volta che Alice ha questo indirizzo $P$ , lo usa come output in una transazione, cioè vi invia bitcoin.

Nel contesto di Silent Payments, la funzione "hash" corrisponde a una funzione hash SHA256 specificamente etichettata con BIP0352/SharedSecret, che garantisce che gli hash generati siano unici per questo protocollo e non possano essere riutilizzati in altri contesti, offrendo al contempo una protezione aggiuntiva contro il riutilizzo dei nonces nelle firme. Questo standard corrisponde a quello specificato in BIP340 per le firme Schnorr su secp256k1. Grazie alle proprietà della curva ellittica su cui si basa ECDH, sappiamo che :

$a \cdot B = b \cdot A$

Bob sarà quindi in grado di calcolare l'indirizzo di ricezione a cui Alice ha inviato i bitcoin. A tal fine, controlla tutte le transazioni Bitcoin che soddisfano i criteri di Silent Payments e applica il seguente calcolo a ciascuna di esse per verificare se il pagamento è indirizzato a lui (scansione):

$P' = B + ´testo{hash}(b \cdot A) \cdot G$

Quando analizza la transazione di Alice, si rende conto che $P'$ è uguale a $P$ . Sa quindi che il pagamento è indirizzato a lei:

$P' = B + ´testo{hash}(b ´cdot A) ´cdot G = B + ´testo{hash}(a ´cdot B) ´cdot G = P$

Da qui, Bob sarà in grado di calcolare la chiave privata $p$ che consente di spendere l'indirizzo $P$ :

$p = (b + \text{hash}(b \cdot A)) \bmod n$

Come si può notare, per calcolare la chiave privata $p$ è necessario disporre della chiave privata $b$ . Solo Bob possiede questa chiave privata $b$ . Sarà quindi l'unico a poter spendere i bitcoin inviati al suo indirizzo Silent Payments.

Leggenda:

$B$ : La chiave pubblica/indirizzo statico pubblicato da Bob
$b$ : chiave privata di Bob
$A$ : la chiave pubblica UTXO di Alice utilizzata come input della transazione
$a$ : chiave privata di Alice
$G$ : il punto di generazione della curva ellittica secp256k1
${testo{SHA256}$ : la funzione hash SHA256 associata a BIP0352/SharedSecret
$s$ : il segreto comune ECDH
$P$ : la chiave pubblica/indirizzo univoco per il pagamento a Bob

Ecco un approccio iniziale piuttosto ingenuo all'utilizzo dell'indirizzo statico di Bob, noto come $B$ , per ricavare un indirizzo unico $P$ a cui inviare bitcoin. Tuttavia, questo metodo è troppo semplicistico e presenta diversi difetti che devono essere corretti. Il primo problema è che, in questo schema, Alice non può creare più invii a Bob nell'ambito della stessa transazione.

Come si creano più uscite?

Nell'esempio della sezione precedente, Alice crea un unico output che verrà inviato a Bob all'indirizzo unico $P$ . Con lo stesso input selezionato, è impossibile per Alice creare due indirizzi vuoti distinti per Bob, poiché il metodo utilizzato porterebbe sempre allo stesso risultato per $P$ , ossia lo stesso indirizzo. Tuttavia, ci possono essere molte situazioni in cui Alice desidera dividere il suo pagamento a Bob in diversi importi minori, creando così diversi UTXO. È quindi necessario trovare un metodo per ottenere questo risultato.

Per ottenere questo risultato, modificheremo leggermente il calcolo che Alice esegue per ricavare $P$ , in modo da poter generare due indirizzi distinti per Bob, ovvero $P_0$ e $P_1$ .

Per modificare il calcolo e ottenere due indirizzi diversi, è sufficiente aggiungere un numero intero che modifichi il risultato. Così, Alice aggiungerà $0$ al suo calcolo per ottenere l'indirizzo $P_0$ e $1$ per ottenere l'indirizzo $P_1$ . Chiamiamo questo intero $i$ :

$P_i = B + \text{hash}(a \cdot B \text{ ‖ } i) \cdot G$

Il processo di calcolo rimane invariato rispetto al metodo precedente, tranne che questa volta Alice concatena $a \cdot B$ con $i$ prima di procedere con l'hash. Sarà quindi sufficiente modificare $i$ per ottenere un nuovo indirizzo appartenente a Bob. Ad esempio:

$P_0 = B + \text{hash}(a \cdot B \text{ ‖ } 0) \cdot G$

$P_1 = B + \text{hash}(a \cdot B \text{ ‖ } 1) \cdot G$

Quando Bob esamina la blockchain alla ricerca di pagamenti silenziosi a lui destinati, inizia utilizzando $i = 0$ per l'indirizzo $P_0$ . Se non trova alcun pagamento su $P_0$ , conclude che questa transazione non contiene pagamenti silenziosi a lui destinati e abbandona la scansione. Tuttavia, se $P_0$ è valido e contiene un pagamento per lui, continua con $P_1$ nella stessa transazione per verificare se Alice ha effettuato un secondo pagamento. Se $P_1$ risulta non valido, interrompe la ricerca di questa transazione; altrimenti, continua a testare i valori $i$ successivi:

$P_0 = B + \text{hash}(b \cdot A ‖ 0) \cdot G$

$P_1 = B + \text{hash}(b \cdot A \text{ ‖ } 1) \cdot G$

Poiché Bob si ferma immediatamente a $i = 0$ se $P_0$ non funziona, l'uso di questo intero non aggiunge quasi alcun carico operativo a Bob per la fase di scansione della transazione.

Bob può quindi calcolare le chiavi private nello stesso modo:

 $p_0 = (b + \text{hash}(b \cdot A \text{ ‖ } 0)) \bmod n$

 $p_1 = (b + \text{hash}(b \cdot A \text{ ‖ } 1)) \bmod n$

Leggenda:

$B$ : La chiave pubblica/indirizzo statico pubblicato da Bob
$b$ : chiave privata di Bob
$A$ : la chiave pubblica UTXO di Alice utilizzata come input della transazione
$a$ : chiave privata di Alice
$G$ : il punto di generazione della curva ellittica secp256k1
${testo{SHA256}$ : la funzione hash SHA256 associata a BIP0352/SharedSecret
$s_0$ : il primo segreto comune ECDH
$s_1$ : il secondo segreto comune ECDH
$P_0$ : la prima chiave pubblica / indirizzo univoco per il pagamento a Bob
$P_1$ : la seconda chiave pubblica / indirizzo univoco per il pagamento a Bob

Con questo metodo, stiamo iniziando a ottenere un bel protocollo, ma ci sono ancora alcune sfide da superare, non ultima la prevenzione del riutilizzo degli indirizzi.

Come evitare il riutilizzo degli indirizzi?

Come abbiamo visto nelle sezioni precedenti, Alice utilizza la coppia di chiavi che protegge il suo UTXO, che spenderà per calcolare il segreto condiviso ECDH con Bob. Questo segreto le consente di ricavare l'indirizzo univoco $P_0$ . Tuttavia, la coppia di chiavi ( $a$ , $A$ ) utilizzata da Alice può proteggere diversi UTXO se ha riutilizzato questo indirizzo più volte. Nel caso in cui Alice effettui due pagamenti all'indirizzo statico di Bob $B$ utilizzando due UTXO protetti dalla stessa chiave $A$ , si avrebbe un riutilizzo dell'indirizzo per Bob.

Il riutilizzo degli indirizzi è una pratica molto scorretta in termini di riservatezza degli utenti. Per sapere perché, vi consiglio di rivedere le prime parti di questo corso di formazione Infatti, poiché l'indirizzo univoco $P_0$ è derivato da $A$ e $B$ , se Alice ricava un secondo indirizzo per un secondo pagamento a $B$ , con la stessa chiave $A$ , si ritroverà esattamente sullo stesso indirizzo $P_0$ . Per evitare questo rischio e prevenire il riutilizzo degli indirizzi all'interno di Silent Payments, dobbiamo modificare leggermente i nostri calcoli.

Vogliamo che ogni UTXO consumato da Alice come input per un pagamento fornisca un indirizzo unico dal lato di Bob, anche se diversi UTXO sono protetti dalla stessa coppia di chiavi. Pertanto, tutto ciò che dobbiamo fare è aggiungere un riferimento all'UTXO quando calcoliamo l'indirizzo univoco $P_0$ . Questo riferimento sarà semplicemente l'hash dell'UTXO consumato come input:

$´testo{inputHash} = ´testo{hash}(´testo{outpoint} ´testo{ ‖ } A)$

Alice aggiungerà questo riferimento all'input per il calcolo dell'indirizzo univoco $P_0$ :

$P_0 = B + \text{hash}(\text{inputHash} \cdot a \cdot B \text{ ‖ } 0) \cdot G$

Durante la scansione, Bob può anche aggiungere $testo{inputHash}$ , poiché gli basta osservare la transazione per dedurre $testo{outpoint}$ :

$P_0 = B + \text{hash}(\text{inputHash} \cdot b \cdot A \text{ ‖ } 0) \cdot G$

Quando trova una $P_0$ valida, può calcolare la corrispondente chiave privata $p_0$ :

 $p_0 = (b + \text{hash}(\text{inputHash} \cdot b \cdot A \text{ ‖ } 0)) \bmod n$

Leggenda:

$B$ : La chiave pubblica/indirizzo statico pubblicato da Bob
$b$ : chiave privata di Bob
$A$ : la chiave pubblica UTXO di Alice utilizzata come input della transazione
$a$ : chiave privata di Alice
$H$ : hash UTXO usato come ingresso
$G$ : il punto di generazione della curva ellittica secp256k1
${testo{SHA256}$ : la funzione hash SHA256 associata a BIP0352/SharedSecret
$s_0$ : il primo segreto comune ECDH
$P_0$ : la prima chiave pubblica / indirizzo univoco per il pagamento a Bob

Per il momento, i nostri calcoli presuppongono che Alice utilizzi un singolo input per la sua transazione. Tuttavia, dovrebbe essere in grado di utilizzare più input. Di conseguenza, dal lato di Bob, per ogni transazione che coinvolge diversi input, egli dovrebbe teoricamente calcolare l'ECDH per ogni input per determinare se un pagamento è destinato a lui. Questo metodo non è soddisfacente, quindi dobbiamo trovare una soluzione per ridurre il carico di lavoro!

Modifica delle chiavi pubbliche in input

Per risolvere questo problema, invece di utilizzare la coppia di chiavi che assicura uno specifico ingresso dal lato di Alice, utilizzeremo la somma di tutte le coppie di chiavi utilizzate negli ingressi della transazione. Questa somma sarà quindi considerata come una nuova coppia di chiavi. Questa tecnica è nota come "tweaking".

Ad esempio, immaginiamo che la transazione di Alice abbia 3 input, ciascuno protetto da una coppia di chiavi diversa:

$a_0$ viene utilizzato per proteggere l'ingresso #0 ;
$a_1$ viene utilizzato per proteggere l'ingresso #1;
$a_2$ protegge l'ingresso #2.

Seguendo il metodo precedentemente descritto, Alice dovrebbe scegliere una singola coppia di chiavi tra $a_0$ , $a_1$ e $a_2$ per calcolare il segreto ECDH e generare il singolo indirizzo di pagamento $P$ dall'indirizzo statico $B$ di Bob. Tuttavia, questo approccio richiede a Bob di testare ogni possibilità in sequenza, iniziando con $a_0$ , poi $a_1$ e così via, finché non identifica una coppia che genera un indirizzo $P$ valido. Questo processo richiede che Bob esegua il calcolo dell'ECDH su tutti gli ingressi di tutte le transazioni, il che aumenta notevolmente il carico operativo della scansione.

Per evitare ciò, chiederemo ad Alice di calcolare $P$ utilizzando la somma di tutte le chiavi in ingresso. Utilizzando il nostro esempio, la chiave privata modificata $a$ verrebbe calcolata come segue:

$a = a_0 + a_1 + a_2$

Allo stesso modo, Alice e Bob possono calcolare la chiave pubblica modificata:

$A = A_0 + A_1 + A_2$

Con questo metodo, Bob deve solo calcolare la somma delle chiavi pubbliche della transazione, quindi calcolare il segreto ECDH solo da $A$ , il che riduce notevolmente il numero di calcoli necessari per la fase di scansione.

Tuttavia, ricordiamo la sezione precedente. Avevamo aggiunto al nostro calcolo l'hash $\text{inputHash}$ , che viene utilizzato come nonce per evitare il riutilizzo degli indirizzi:

$´testo{inputHash} = ´testo{hash}(´testo{outpoint} ´testo{ ‖ } A)$

Tuttavia, se in una transazione sono presenti più ingressi, è necessario essere in grado di determinare quale $testo{outpoint}$ viene scelto in questo calcolo. Secondo il BIP352, il criterio di selezione del $testo{outpoint}$ da utilizzare è quello di scegliere il più piccolo dal punto di vista lessicografico, il che significa selezionare l'UTXO che appare per primo in ordine alfabetico. Questo metodo standardizza l'UTXO da scegliere in ogni transazione. Ad esempio, se il $testo{outpoint}$ lessicograficamente più piccolo è $testo{outpoint}_L$ , il calcolo di $testo{inputHash}$ sarà :

$´testo{inputHash} = ´testo{hash}(´testo{outpoint}_L ´testo{ ‖ } A)$

I calcoli rimangono quindi identici a quelli presentati nella sezione precedente, tranne per il fatto che la chiave privata $a$ e la corrispondente chiave pubblica $A$ non sono più una coppia utilizzata per proteggere un singolo ingresso, ma rappresentano ora il tweak per tutte le coppie di chiavi in ingresso.

Chiavi di spesa e di scansione separate

Per il momento, ci siamo riferiti all'indirizzo statico del pagamento silenzioso $B$ come a una chiave pubblica unica. Ricordiamo che è questa chiave pubblica $B$ che Alice utilizza per creare il segreto condiviso ECDH, che a sua volta calcola l'indirizzo di pagamento univoco $P$ . Bob utilizza questa chiave pubblica $B$ e la corrispondente chiave privata $b$ per la fase di scansione. Ma utilizzerà anche la chiave privata $b$ per calcolare la chiave privata $p$ che consente di spendere dall'indirizzo $P$ .

Lo svantaggio di questo metodo è che la chiave privata $b$ , utilizzata per calcolare tutte le chiavi private degli indirizzi che hanno ricevuto i pagamenti silenziosi, viene utilizzata anche da Bob per analizzare le transazioni. Questo passaggio richiede che la chiave $b$ sia disponibile sul software del portafoglio connesso a Internet, il che la espone maggiormente al rischio di furto rispetto alla conservazione in un portafoglio freddo. L'ideale sarebbe poter sfruttare i Silent Payments mantenendo la chiave privata $b$ , che controlla l'accesso a tutte le altre chiavi private, al sicuro in un portafoglio hardware. Fortunatamente, il protocollo è stato adattato per consentire proprio questo.

A tal fine, il BIP352 richiede che il ricevitore utilizzi 2 coppie di chiavi diverse:

b_{\text{spend}}$: per calcolare le chiavi private degli indirizzi di pagamento unici;
b_{{text{scan}}$: per trovare indirizzi di pagamento unici.

In questo modo, Bob può conservare la chiave privata $b_{\text{spend}}$ su un portafoglio hardware e utilizzare la chiave privata $b_{\text{scan}}$ su un software online per trovare i suoi Silent Payment, senza rivelare $b_{\text{spend}}$ . D'altra parte, le chiavi pubbliche $B_{\text{scan}}$ e $B_{\text{spend}}$ sono entrambe rivelate pubblicamente, poiché si trovano nell'indirizzo statico di Bob $B$ :

$B = B_{{testo{scan}} \´testo{ ‖ } B_{testo{spesa}}$

Per calcolare un indirizzo di pagamento unico $P_0$ appartenente a Bob, Alice eseguirà il seguente calcolo:

$P_0 = B_{{testo{spesa}} + \text{hash}(\text{inputHash} \cdot a \cdot B_{{text{scan}} \text{ ‖ } 0) \cdot G$

Per trovare i pagamenti a lui destinati, Bob eseguirà il seguente calcolo:

$P_0 = B_{{testo{spesa}} + \text{hash}(\text{inputHash} \cdot b_{\text{scan}} \cdot A \text{ ‖ } 0) \cdot G$

Come si può notare, finora Bob non ha avuto bisogno di usare $b_{\text{spend}}$ , che si trova nel suo portafoglio hardware. Quando vuole spendere $P_0$ , può eseguire il seguente calcolo per trovare la chiave privata $p_0$ :

$p_0 = (b_{{testo{spesa}} + \text{hash}(\text{inputHash} \cdot b_{\text{scan}} \cdot A \text{ ‖ } 0)) \bmod n$

Leggenda:

$B_{{text{scan}}$ : chiave pubblica di scansione di Bob (indirizzo statico)
$b_{\text{scan}}$ : chiave di scansione privata di Bob
$B_{\text{spend}}$ : chiave pubblica di spesa di Bob (indirizzo statico)
$b_{\text{spend}}$ : chiave privata di spesa di Bob
$A$ : Somma degli input della chiave pubblica (tweak)
$a$ : la chiave privata corrispondente alla chiave pubblica modificata
$H$ : l'hash del più piccolo UTXO (in senso lessicografico) usato come input
$G$ : il punto di generazione della curva ellittica secp256k1
${testo{SHA256}$ : la funzione hash SHA256 associata a BIP0352/SharedSecret
$s_0$ : il primo segreto comune ECDH
$P_0$ : la prima chiave pubblica / indirizzo univoco per il pagamento a Bob

Utilizzo degli indirizzi SP con un'etichetta

Bob ha quindi un indirizzo statico $B$ per i pagamenti silenziosi come :

$B = B_{{testo{scan}} \´testo{ ‖ } B_{testo{spesa}}$

Il problema di questo metodo è che non consente di separare i diversi pagamenti inviati a questo indirizzo. Ad esempio, se Bob ha due clienti diversi per la sua attività e vuole differenziare i pagamenti a ciascuno di essi, avrà bisogno di due indirizzi statici diversi. Una soluzione ingenua, con l'approccio attuale, sarebbe che Bob creasse due portafogli separati, ciascuno con il proprio indirizzo statico, o addirittura che stabilisse due indirizzi statici diversi all'interno dello stesso portafoglio. Tuttavia, questa soluzione richiede una doppia scansione dell'intera blockchain (una volta per ciascun indirizzo) per rilevare i pagamenti destinati rispettivamente a ciascun indirizzo. Questa doppia scansione aumenta irragionevolmente il carico operativo di Bob.

Per risolvere questo problema, BIP352 utilizza un sistema di etichette che consente diversi indirizzi statici, senza aumentare in modo irragionevole il carico di lavoro per trovare i pagamenti silenziosi sulla blockchain. A tal fine, aggiungiamo un intero $m$ alla chiave pubblica di spesa $B_{\text{spend}}$ . Questo intero può assumere il valore di $1$ per il primo indirizzo statico, poi $2$ per il secondo e così via. Le chiavi di spesa $B_{\text{spend}}$ saranno ora chiamate $B_m$ e saranno costruite in questo modo:

$B_m = B_{{testo{spesa}} + \text{hash}(b_{text{scan}} \text{ ‖ } m) \cdot G$

Ad esempio, per la prima chiave di spesa con l'etichetta $1$ :

$B_1 = B_{{text{spend}} + \text{hash}(b_{testo{scan}} \text{ ‖ } 1) \cdot G$

L'indirizzo statico pubblicato da Bob sarà ora composto da $B_{\text{scan}}$ e $B_m$ . Ad esempio, il primo indirizzo statico con etichetta $1$ sarà :

$B = B_{{testo{scan}} \text{ ‖ } B_1$

Partiamo solo dall'etichetta 1 perché l'etichetta 0 è riservata al cambiamento. Alice, da parte sua, ricaverà l'indirizzo di pagamento singolo $P$ nello stesso modo di prima, ma utilizzando il nuovo $B_1$ al posto di $B_{{text{spend}}$ :

$$ P_0 = B_1 + \text{hash}(\text{inputHash} \cdot a \cdot B_{text{scan}} \text{ ‖ } 0) \cdot G$

In realtà, Alice non sa nemmeno necessariamente che Bob ha un indirizzo etichettato, poiché sta semplicemente utilizzando la seconda parte dell'indirizzo statico fornito da Bob, che in questo caso è il valore $B_1$ anziché $B_{text{spend}}$ .

Per eseguire la scansione dei pagamenti, Bob utilizzerà sempre il valore del suo indirizzo statico iniziale con $B_{\text{spend}}$ in questo modo:

$P_0 = B_{{testo{spesa}} + \text{hash}(\text{inputHash} \cdot b_{\text{scan}} \cdot A \text{ ‖ } 0) \cdot G$

Quindi, sottrae semplicemente il valore trovato per $P_0$ da ogni uscita, una per una. Quindi controlla se uno dei risultati di queste sottrazioni corrisponde al valore di una delle etichette utilizzate nel portafoglio. Se, ad esempio, l'uscita #4 corrisponde all'etichetta $1$ , significa che questa uscita è un Pagamento silenzioso associato all'indirizzo staticamente etichettato $B_1$ :

$$ Out_4 - P_0 = \text{hash}(b_{\text{scan}} \text{ ‖ } 1) \cdot G$

Funziona perché :

$B_1 = B_{{text{spend}} + \text{hash}(b_{testo{scan}} \text{ ‖ } 1) \cdot G$

Grazie a questo metodo, Bob può utilizzare una moltitudine di indirizzi statici ( $B_1$ , $B_2$ , $B_3$ ...), tutti derivati dal suo indirizzo statico di base ( $B = B_{\text{scan}} \text{ ‖ } B_{\text{spend}}$ ), in modo da mantenere l'utilizzo separato.

Si noti, tuttavia, che questa separazione degli indirizzi statici è valida solo dal punto di vista della gestione del portafoglio personale, ma non separa le identità. Poiché tutti hanno lo stesso $B_{{text{scan}}$ , è molto facile associare tutti gli indirizzi statici insieme e dedurre che appartengono a un'unica entità.

Leggenda:

$B_{{text{scan}}$ : chiave pubblica di scansione di Bob (indirizzo statico)
$b_{\text{scan}}$ : chiave di scansione privata di Bob
$B_{\text{spend}}$ : chiave pubblica di spesa di Bob (indirizzo iniziale)
$B_m$ : chiave di spesa pubblica di Bob etichettata (indirizzo statico)
$b_m$ : la chiave di spesa privata di Bob etichettata come
$A$ : Somma degli input della chiave pubblica (tweak)
$a$ : la chiave privata corrispondente alla chiave pubblica modificata
$H$ : l'hash del più piccolo UTXO (in senso lessicografico) usato come input
$G$ : il punto di generazione della curva ellittica secp256k1
${testo{SHA256}$ : la funzione hash SHA256 associata a BIP0352/SharedSecret
$s_0$ : il primo segreto comune ECDH
$P_0$ : la prima chiave pubblica / indirizzo univoco per il pagamento a Bob
$p_0$ : la chiave privata del primo indirizzo di pagamento univoco a Bob
$X$ : l'hash della chiave privata di scansione con l'etichetta

Come si costruisce un indirizzo Silent Payments?

Per creare un indirizzo dedicato a Silent Payments, è necessario innanzitutto ricavare 2 coppie di chiavi dal proprio portafoglio Bitcoin HD:

La coppia $b_{\text{scan}}$ , $B_{\text{scan}}$ per cercare i pagamenti indirizzati a noi;
La coppia $b_{\text{spend}}$ , $B_{\text{spend}}$ per pensare ai bitcoin ricevuti.

Queste coppie sono derivate utilizzando i seguenti percorsi (Bitcoin Mainnet):

scan : m / 352' / 0' / 0' / 1' / 0
spend : m / 352' / 0' / 0' / 0' / 0

Una volta ottenute queste due coppie di chiavi, è sufficiente concatenarle (end-to-end) per creare il payload dell'indirizzo statico:

$B = B_{{testo{scan}} \´testo{ ‖ } B_{testo{spesa}}$

Se vogliamo usare le etichette, sostituiamo $B_{\text{spend}}$ con $B_m$ :

$B = B_{{testo{scan}} \text{ ‖ } B_m$

Con etichetta $m$ :

$B_m = B_{{testo{spesa}} + \text{hash}(b_{text{scan}} \text{ ‖ } m) \cdot G$

Una volta ottenuto questo payload, aggiungiamo l'HRP (Human-Readable Part) sp e la versione q (= versione 0). Aggiungiamo anche un checksum e formattiamo l'indirizzo come bech32m.

Ad esempio, ecco il mio indirizzo statico Silent Payments:

sp1qqvhjvsq2vz8zwrw372vuzle7472zup2ql3pz64yn5cpkw5ngv2n6jq4nl8cgm6zmu48yk3eq33ryc7aam6jrvrg0d0uuyzecfhx2wgsumcurv77e

Un punto importante relativo agli indirizzi statici, che forse avete capito nelle sezioni precedenti, è che questi indirizzi non sono visibili nelle transazioni Bitcoin. Solo gli indirizzi di pagamento $P$ utilizzati nelle uscite appaiono sulla blockchain nel formato standard Taproot. Quindi, dall'esterno, è impossibile distinguere una transazione che coinvolge il Silent Payment da una transazione ordinaria che utilizza gli output P2TR.

Come nel caso del BIP47, è impossibile stabilire una connessione tra un indirizzo statico $B$ e un indirizzo di pagamento $P$ derivato da $B$ . Infatti, anche se Eve, un potenziale attaccante, tenta di scansionare la blockchain con l'indirizzo statico $B$ di Bob, non sarà in grado di eseguire i calcoli necessari per determinare $P$ . Per farlo, avrebbe bisogno della chiave privata di Bob $b_{\text{scan}}$ , o delle chiavi private del mittente $a$ , ma entrambe sono ovviamente private. È quindi possibile collegare esplicitamente il proprio indirizzo statico a una forma di identità personale.

Come si usa Silent Payments?

La proposta dei pagamenti silenziosi è relativamente recente e al momento è stata implementata solo da un numero molto limitato di portafogli. A mia conoscenza, esistono solo 3 prodotti software che li supportano:

Presto vi forniremo un tutorial dettagliato su come impostare il vostro indirizzo statico Silent Payments.

Poiché questa funzione è nuova, vi consigliamo di usare cautela e di evitare di utilizzare i pagamenti silenziosi per importi elevati su mainnet.

*Per creare questo capitolo sui pagamenti silenziosi, ho utilizzato il sito di spiegazione dei pagamenti silenziosi e il documento di spiegazione del BIP352

Sezione finale

Recensioni e valutazioni

true

Esame finale

true

Conclusione

true