Ai microfoni di Atlas21 il lead developer di PDK spiega come il Payjoin possa alzare il livello di privacy per tutti gli utenti della rete Bitcoin.
Dan Gould, lead developer di Payjoin Dev Kit, ha parlato ai microfoni di Atlas21 dell’adozione di Payjoin, delle sfide tecniche, dei benefici e dello stato di sviluppo della libreria Payjoin Dev Kit.
Cos’è una transazione Payjoin?
“Penso al Payjoin più come un meccanismo di coordinamento che come un formato di transazione. È il modo più semplice per due parti di raggruppare i loro input in un’unica transazione, in sostanza consente di fare batching tra due parti. Ad esempio, un deposito su un exchange può finanziare direttamente i prelievi perché l’exchange può raggruppare i propri input con il deposito in entrata. L’altro caso d’uso è quello classico: hai un mittente e un ricevente, e il ricevente genera un indirizzo con dei metadati Payjoin associati. Quando quel QR code viene scansionato, il mittente invia la transazione al ricevente attraverso un canale laterale anziché sulla rete Bitcoin. Il ricevente può quindi consolidare automaticamente i propri input unendoli a quelli del mittente”.
Quali incentivi hanno gli exchange a implementare Payjoin?
“Ci sono due modi in cui un exchange può risparmiare commissioni. Il primo, se il mittente finanzia direttamente i prelievi, l’exchange non deve mai prendere un UTXO dalla sua tesoreria per poi spenderlo successivamente, quindi non paga commissioni su quell’input. Inoltre, se un consolidamento doveva avvenire comunque, di norma il mittente copre il costo di un input extra. Tutte le altre operazioni che finiscono nello stesso batch condividono i costi fissi della transazione. In altre parole, stai mettendo più input all’interno di meno byte sulla blockchain, ottenendo un forte incentivo al risparmio sulle commissioni”.
Nel futuro pensi che grandi exchange integreranno Payjoin?
“Bull Bitcoin sarà il primo exchange a supportarlo. È molto facile per loro perché, almeno con il loro wallet mobile self-custody, possono astrarre tutto dietro il pulsante compra e vendi, quindi avviene automaticamente. Penso sia nell’interesse anche degli exchange più grandi supportarlo, perché dà loro strumenti migliori per la gestione degli UTXO. Questo non ostacola alcun tipo di KYC o compliance che devono fare. Possono ancora raccogliere tutte le stesse informazioni dai loro utenti. Ma il fatto che Payjoin esista rende più difficile per terze parti ottenere il saldo di un cluster di indirizzi, con chi ha interagito in passato, con chi interagirà in futuro e quanto volume entra ed esce regolarmente”.
Quali sono i benefici concreti di Payjoin in termini di privacy?
“Il beneficio più grande è per la rete nel suo complesso: se c’è una sufficiente adozione di Payjoin, allora le euristiche di sorveglianza non sono più affidabili. Il secondo beneficio è l’opportunità di risparmiare commissioni impacchettando più input in meno byte on-chain. Il terzo beneficio è la possibilità di comunicare out-of-band quando facciamo questi batch, così a volte non abbiamo nemmeno bisogno di fare due transazioni quando una è sufficiente. Un esempio è il funding di un canale Lightning: tipicamente invii fondi a un wallet single-sig, poi il nodo Lightning invia un’altra transazione che apre un canale. Con Payjoin, un wallet che non sa nulla di Lightning può contribuire a un batch che apre direttamente un canale”.
C’è una percentuale specifica di utenti che devono usarlo perché la rete ne benefici?
“Se qualsiasi utente usa Payjoin, la rete ne beneficia perché le euristiche delle aziende di blockchain analysis non sono più affidabili al 100%. Ciò che è considerato statisticamente significativo da un analista varierà a seconda della precisione di cui hanno bisogno per avere fiducia nella loro analisi. Ma il solo fatto che esista la possibilità di un Payjoin crea un potenziale controesempio per qualsiasi transazione che ha input multipli”.
Perché l’adozione di Payjoin non ha mai preso piede su larga scala?
“Il problema più grande storicamente era che tutti dovevano implementare la propria versione. Inoltre, le vecchie versioni richiedevano che il ricevente gestisse un server sempre attivo e pubblicamente accessibile. La prima cosa che abbiamo fatto è stata correggere il protocollo. Negli ultimi due anni abbiamo sviluppato un protocollo Payjoin asincrono che esternalizza questa responsabilità di gestire un server a una terza parte cieca (directory) che non vede i messaggi. Usiamo anche OHTTP (Oblivious HTTP) per proteggere i metadati, simile a iCloud Private Relay di Apple. Una volta sviluppato il protocollo asincrono, non abbiamo più bisogno che mittente e destinatario siano online contemporaneamente. Questo è stato unito nel repository dei BIP lo scorso luglio come BIP77. In parallelo, abbiamo sviluppato il Payjoin Dev Kit, una libreria Rust altamente testata che implementa correttamente la specifica. Ora chiunque voglia integrarlo può usarla e creare un’implementazione Payjoin in meno di 2.000 righe di codice”.
Con la versione 2, chi può gestire queste directory?
“Chiunque può gestire le directory. C’è un software open-source scritto in Rust. È un semplice server store-and-forward, quindi non è costoso da gestire. Stai solo memorizzando e inoltrando pacchetti da otto kilobyte di dati casuali. Se hai un server accessibile su Internet con un nome di dominio e un certificato TLS può essere usato da chiunque”.
Ci sono già wallet che hanno implementato PDK?
“Sì, ci sono diverse implementazioni proof-of-concept e test pilota in produzione. Abbiamo due test in produzione nel 2025 con Bull Bitcoin e Cake Wallet, dove Payjoin è integrato nell’esperienza di pagamento predefinita. Abbiamo anche dimostrato che Payjoin DevKit funziona in Liana e nell’exchange Boltz all’MIT Bitcoin Expo Hackathon di quest’anno. La scorsa settimana abbiamo rilasciato il Rust Payjoin 1.0 release candidate, quindi pensiamo sia stabile e le persone possono prenderlo e integrarlo da sole. Una delle ragioni per cui non è stato possibile integrarlo ovunque è perché il Dev Kit non era abbastanza stabile. Ora con questa release candidate 1.0 le persone hanno tutti i componenti di cui hanno bisogno”.
Quanto è probabile che in futuro ci saranno wallet che implementano Payjoin di default, così che gli utenti non si accorgano nemmeno di usarlo?
“Direi che già ora le persone che lo usano probabilmente non lo sanno davvero. La loro esperienza non è cambiata significativamente. Il modo in cui Payjoin funziona gli permette di avvenire automaticamente in background con un flusso predefinito. E se il protocollo fallisce, viene effettuata una tipica transazione standard. È già possibile per i wallet integrarlo nel loro flusso predefinito e alcuni lo hanno già fatto. Vedremo più wallet farlo e miglioreremo l’esperienza utente ora che abbiamo dimostrato i primi test”.
Se dovessi convincere uno sviluppatore a integrare PDK nel suo wallet, quale sarebbe la tua argomentazione principale?
“Siamo stati fortunati che non abbiamo dovuto convincere così tanti sviluppatori. Abbiamo avuto più domanda per l’integrazione di Payjoin di quanto siamo stati effettivamente in grado di fornire a causa delle limitazioni del Dev Kit. Ma se qualcuno è indeciso, indicherei prima i benefici: l’intera rete ne beneficia, quindi stai facendo del bene e i tuoi utenti soprattutto hanno una difesa migliore contro questi attacchi basati sulle euristiche. Inoltre direi che è abbastanza facile avere un proof of concept funzionante in un weekend. Puoi guardare l’implementazione di riferimento e i test pilota per vedere che è possibile integrarlo senza interrompere il flusso che i tuoi utenti si aspettano già”.
Su cosa stai lavorando attualmente?
“In questo momento abbiamo rilasciato la release candidate 1.0 e ci stiamo assicurando che l’API sia stabile. Stiamo aggiornando i nostri test pilota esistenti alla 1.0, stiamo facendo un’integrazione con Liana, con Boltz, e stiamo espandendo la nostra integrazione con Bull Bitcoin. Il nostro piano è accelerare l’adozione nel 2026 verso molti più wallet e servizi. Stiamo anche iniziando a dedicarci alla ricerca di un protocollo Payjoin multi-party. Abbiamo dimostrato che il flusso scan-send può essere esteso oltre il batching a due parti al batching multi-party. Credo che questa prossima generazione, Payjoin v3, sia qualcosa che possiamo realizzare”.
