Un post di Oleksandr Kurbatov pubblicato il 15 ottobre 2026 su Delving Bitcoin (il forum in cui gli sviluppatori discutono i cambiamenti al protocollo) descrive come un wallet con più firmatari possa inviare silent payments, i pagamenti verso un indirizzo statico che genera un indirizzo on-chain diverso a ogni transazione. L’autore propone un protocollo in due round chiamato AggDLEQ, ripreso il 30 ottobre da Bitcoin Optech nella newsletter #429. Il BIP-352 oggi sconsiglia gli input a chiave aggregata (MuSig2, FROST) per mancanza di una prova di sicurezza.
Silent payments e wallet multiparty: dov’è il problema
Il BIP-352, la specifica dei silent payments, sconsiglia di usare input con chiavi aggregate MuSig o FROST per mancanza di una prova di sicurezza, tranne quando i partecipanti sono fidati o sono la stessa entità. MuSig2 e FROST sono schemi con cui più firmatari controllano insieme una sola chiave.
Il motivo è tecnico. Per creare l’indirizzo del destinatario, il mittente calcola un segreto condiviso (uno scambio Diffie-Hellman, ECDH) tra la chiave del proprio input e la chiave di scansione del destinatario. In un wallet multiparty nessun firmatario conosce la chiave intera, quindi ognuno deve contribuire con una quota del calcolo. Lo stesso BIP-352 ammette in teoria questi input, ma osserva che potrebbe essere necessario che i partecipanti forniscano anche una prova DLEQ (una prova che due valori derivano dallo stesso segreto) per dimostrare di non agire in modo malevolo.
AggDLEQ: due round e una sola prova
Il protocollo AggDLEQ combina i contributi di tutti i firmatari in un’unica prova compatibile con il BIP-374 in due round, secondo il post di Kurbatov. Un coordinatore invia a ogni firmatario il contesto della sessione: l’insieme dei firmatari, i coefficienti dello schema di firma, il tweak, la chiave, la transazione e un identificativo di sessione. Il tweak è il valore aggiuntivo che modifica la chiave, mentre il nonce è un numero casuale usato una sola volta. Ogni firmatario controlla il contesto prima di procedere.
| Fase | Cosa fa ogni firmatario | Cosa fa il coordinatore |
|---|---|---|
| Contesto | Convalida i dati ricevuti | Invia insieme dei firmatari, coefficienti, tweak, chiave, transazione e ID di sessione |
| Round 1 | Genera due nonce casuali e invia la propria quota ECDH con i commitment sui nonce (impegni crittografici) | Combina le quote con i coefficienti dello schema (somma ponderata, più il tweak) e calcola la sfida (la ricalcola anche ogni firmatario) |
| Round 2 | Risponde con un contributo alla prova, calcolato sulla sfida | Verifica ogni risposta e le aggrega in un’unica prova BIP-374 |
| Firma | Controlla tutte le prove, ricalcola gli output e solo dopo rilascia la firma parziale | Aggrega le firme e scrive quota e prova nei campi del BIP-375 |
Fonti: post di Oleksandr Kurbatov su Delving Bitcoin, 15 ottobre 2026, e newsletter #429 di Optech.
Il BIP-375, che standardizza i campi PSBT (il formato delle transazioni parzialmente firmate) per i silent payments, prevede una prova da 64 byte per ogni input e per ogni chiave di scansione, come ricorda il post. AggDLEQ serve a sostituire le molte prove dei singoli firmatari con una sola, che un verificatore BIP-374 accetta senza modifiche.
Un passaggio è centrale nel disegno: secondo Kurbatov, un firmatario rilascia la propria firma parziale solo dopo aver verificato ogni prova e ricalcolato ogni output. In questo modo, sostiene l’autore, la solidità della prova si traduce nella garanzia che il destinatario trovi il pagamento, anche se il coordinatore si comporta in modo scorretto.
Cosa non cambia e cosa non è ancora dimostrato
Secondo Kurbatov, come riporta la newsletter #429 di Optech, il protocollo non richiede modifiche a BIP-352, BIP-374, BIP-375 né ai protocolli di firma MuSig2 e FROST, e non introduce nuovi campi PSBT, perché i messaggi di AggDLEQ passano solo sul canale con cui i firmatari comunicano col coordinatore.
Sul piano della sicurezza, Kurbatov scrive che l’articolo con le dimostrazioni è in revisione interna e verrà condiviso nel thread quando sarà disponibile su eprint, l’archivio di preprint crittografici. Tra le garanzie che dichiara ci sono la solidità (il destinatario rileva il pagamento qualunque cosa faccia il coordinatore, tranne che con probabilità trascurabile) e l’impossibilità, per firmatari corrotti e coordinatore, di falsificare una prova o una firma.
Questa seconda garanzia poggia però su un’ipotesi chiamata DH-AOMDL, la cui difficoltà, ammette l’autore, è una questione aperta: i parametri di sicurezza sono dimensionati sul miglior attacco noto, senza una riduzione a un problema più standard. Kurbatov aggiunge che il rischio non riguarda solo i wallet multiparty: anche un firmatario BIP-375 singolo calcola la quota ECDH per qualunque chiave di scansione indicata nella PSBT, quindi la sua chiave si comporta come un oracolo Diffie-Hellman statico, cioè risponde a richieste di calcolo scelte da altri.
Le reazioni nel thread
Al 4 novembre il thread conta tre risposte, una delle quali dell’autore. Il 27 ottobre l’utente poyuholu ha segnalato che nelle equazioni mancava il fattore di parità della chiave. Kurbatov ha risposto lo stesso giorno di trattarsi di un errore di notazione e di voler aggiornare il post. Secondo l’autore, con parità negativa la prova non supererebbe la verifica BIP-374 e la sessione verrebbe interrotta, invece di produrre una quota sbagliata accettata.
Il 29 ottobre l’utente macgyver ha descritto un approccio alternativo, pensato per un wallet di tesoreria che spende tramite hardware wallet: due campi PSBT provvisori, uno per la quota ECDH e uno per la prova BIP-374 di ciascun firmatario. Afferma di avere prototipi con MuSig2 su Jade e COLDCARD, con pagamenti su signet rilevati da due wallet riceventi diversi. Ha chiesto come funzionerebbe AggDLEQ senza un canale di coordinamento attivo, caso tipico dei dispositivi air-gapped, cioè mai collegati alla rete, che scambiano dati solo tramite PSBT.
Cosa aspettarsi
Siamo davanti a una proposta in discussione, non a una specifica approvata. Restano da vedere la pubblicazione dell’articolo con le dimostrazioni, la versione corretta del post e la risposta alla domanda sui dispositivi air-gapped. Optech ha trattato nello stesso numero anche la falla di Core Lightning sugli annunci di canale; tra gli altri temi di sviluppo seguiti da BitcoinLive24 ci sono la proposta per importare i preimage hash nei descriptor e BIP139 per esportare i dati dei wallet.
Scarica l’app BitcoinLive24 per ricevere le notizie sullo sviluppo di Bitcoin appena escono.
Domande frequenti sui silent payments multiparty
Che cosa sono i silent payments?
Sono pagamenti verso un indirizzo statico riutilizzabile, definiti dal BIP-352, in cui il mittente deriva per ogni transazione un indirizzo on-chain diverso. Così gli output sulla blockchain non sono riconducibili, per un osservatore esterno, all’indirizzo statico del destinatario.
Che cosa propone AggDLEQ?
Propone un protocollo in due round con cui più firmatari di un wallet MuSig2 o FROST calcolano insieme la quota ECDH e la dimostrano con una sola prova compatibile con il BIP-374, come descritto nel thread di Kurbatov.
Si può usare già oggi?
No: è una proposta in discussione. Il BIP-352 continua a sconsigliare input MuSig e FROST senza prova di sicurezza, e per AggDLEQ l’articolo con le dimostrazioni è ancora in revisione interna.
Servono modifiche al protocollo Bitcoin?
Secondo l’autore della proposta, come riporta Optech, no: il protocollo non richiede modifiche ai BIP esistenti né ai protocolli di firma e non aggiunge campi PSBT, perché i messaggi restano nel canale tra firmatari e coordinatore.
