{"id":237,"date":"2026-08-01T16:36:46","date_gmt":"2026-08-01T16:36:46","guid":{"rendered":"https:\/\/hoge.gg\/it\/musig2-frost-firme-soglia-bitcoin-taproot\/"},"modified":"2026-08-01T16:36:46","modified_gmt":"2026-08-01T16:36:46","slug":"musig2-frost-firme-soglia-bitcoin-taproot","status":"publish","type":"post","link":"https:\/\/hoge.gg\/it\/musig2-frost-firme-soglia-bitcoin-taproot\/","title":{"rendered":"MuSig2 e FROST: le firme a soglia che cambiano il multisig Bitcoin"},"content":{"rendered":"

A giugno 2026 BitGo \u00e8 entrata nella classifica Fortune 500 come prima azienda di infrastrutture per asset digitali a riuscirci, con circa 16,2 miliardi di dollari di ricavi dichiarati per il 2025 secondo il comunicato ufficiale<\/a>, e una banca fiduciaria autorizzata a livello federale negli Stati Uniti, BitGo Bank & Trust. Dietro l’annuncio c’\u00e8 un dettaglio meno pubblicizzato ma pi\u00f9 interessante dal punto di vista tecnico: buona parte dei wallet istituzionali che BitGo gestisce oggi non firma pi\u00f9 le transazioni Bitcoin come faceva fino a qualche anno fa. Al posto di uno script che elenca tre, cinque o sette chiavi pubbliche, molti di quei wallet producono una singola firma Schnorr, indistinguibile da quella di un utente che spende da un indirizzo personale.<\/p>

Il meccanismo si chiama MuSig2 (BIP-327) e ha un parente pi\u00f9 giovane, FROST, ancora in fase di standardizzazione come BIP-445, pensato per gli scenari in cui non tutti i firmatari sono sempre disponibili. Entrambi esistono solo perch\u00e9 Taproot, attivato il 14 novembre 2021, ha portato le firme Schnorr al posto delle sole firme ECDSA. Con Bitcoin che secondo CoinGecko<\/a> vale circa 54.500 euro all’inizio di agosto 2026, non \u00e8 un dettaglio da poco: qualunque risparmio in commissioni o riduzione della superficie d’attacco per un grande custode si traduce rapidamente in cifre concrete. Questo articolo entra nel dettaglio di come funzionano MuSig2 e FROST, perch\u00e9 i grandi custodi li stanno adottando, perch\u00e9 qualcuno invece ha scelto deliberatamente di non farlo ancora, e cosa cambia per chi in Italia deve rispettare gli obblighi di custodia previsti da MiCA.<\/p>

Taproot in breve: da tre BIP a un nuovo modo di firmare<\/h2>

Taproot non \u00e8 un singolo cambiamento ma un pacchetto di tre proposte: BIP-340 (firme Schnorr), BIP-341 (l’output Taproot vero e proprio, con la struttura MAST) e BIP-342 (Tapscript), firmate principalmente da Pieter Wuille, Jonas Nick e Tim Ruffing. Il soft fork \u00e8 stato bloccato al blocco 687.284 il 12 giugno 2021 con oltre il 90% del segnale dei miner tramite il meccanismo Speedy Trial, ed \u00e8 entrato in vigore al blocco 709.632 il 14 novembre 2021. Gli indirizzi che usano Taproot iniziano con il prefisso bc1p, diverso da bc1q di SegWit.<\/p>

La parte che interessa questo articolo \u00e8 il passaggio da ECDSA a Schnorr. Le firme Schnorr hanno una propriet\u00e0 che ECDSA non offre in modo pratico: la linearit\u00e0. Pi\u00f9 chiavi pubbliche e pi\u00f9 firme possono essere combinate matematicamente in un’unica chiave e un’unica firma valide, invece di essere elencate una per una dentro lo script. \u00c8 la base di tutto ci\u00f2 che segue in questo pezzo. La stessa propriet\u00e0, applicata in modo diverso, \u00e8 anche dietro Ordinals e Runes, di cui abbiamo scritto in un pezzo dedicato<\/a>, e dietro le Silent Payments, lo standard per ricevere fondi senza pubblicare un indirizzo riutilizzabile, approfondito qui<\/a>. Chi cerca invece il dibattito sulla resistenza quantistica delle chiavi esposte da Taproot pu\u00f2 leggere l’analisi che abbiamo dedicato al tema<\/a>: qui ci concentriamo su un problema diverso, quello della firma multipla.<\/p>

Il problema del multisig tradizionale: costi e privacy<\/h2>

Prima di Taproot, un wallet a firma multipla su Bitcoin funzionava quasi sempre con script P2SH o P2WSH, basati sull’opcode OP_CHECKMULTISIG: lo script elenca esplicitamente le chiavi pubbliche coinvolte e richiede che un certo numero di firme, ad esempio due su tre, venga allegato alla transazione. Funziona da anni ed \u00e8 ancora oggi lo schema pi\u00f9 diffuso, ma ha due difetti strutturali. Il primo \u00e8 il costo: pi\u00f9 firmatari servono, pi\u00f9 lo script si allunga, e pi\u00f9 byte occupa la transazione. Un input 2-di-3 in SegWit nativo pesa circa 104,5 vB secondo la documentazione tecnica di Bitcoin Optech<\/a>, mentre configurazioni pi\u00f9 ampie possono avvicinarsi a diverse centinaia di vB per un singolo input. Su una rete dove le commissioni si pagano a vByte, un custode con centinaia di prelievi al giorno paga quel sovrapprezzo ogni volta.<\/p>

Il secondo difetto \u00e8 la privacy, meno ovvio ma pi\u00f9 delicato per chi fa custodia istituzionale. Uno script multisig \u00e8 visibile in chiaro sulla blockchain: chiunque analizzi la mempool o un esploratore di blocchi vede che quell’indirizzo richiede, ad esempio, tre firme su cinque. Prima di Taproot, una transazione con quella struttura era essa stessa un segnale: comunicava che l\u00ec dentro c’era probabilmente molto valore, organizzato con una procedura complessa. Non \u00e8 un caso che i furti pi\u00f9 grandi degli ultimi anni, quelli che ripercorriamo pi\u00f9 avanti, abbiano preso di mira proprio wallet multisig identificabili come tali fin dalla loro struttura on chain.<\/p>

MuSig2 (BIP-327): tante chiavi, una firma sola<\/h2>

MuSig2 \u00e8 lo schema che rende possibile aggregare le chiavi pubbliche di pi\u00f9 firmatari in un’unica chiave, e le loro firme in un’unica firma Schnorr valida. \u00c8 stato descritto per la prima volta da Jonas Nick, Tim Ruffing e Yannick Seurin in un paper accademico presentato alla conferenza CRYPTO 2021, poi formalizzato come BIP-327<\/a> da Nick, Ruffing ed Elliott Jin, creato il 22 marzo 2022 e oggi con stato Deployed. Rispetto alla versione precedente, MuSig1, che richiedeva tre round di comunicazione tra i firmatari, MuSig2 ne richiede solo due: ogni firmatario genera pi\u00f9 nonce per la sessione di firma e li invia tutti nel primo round, eliminando il bisogno di un round di commitment separato. Nella pratica significa wallet pi\u00f9 reattivi e meno scambi di rete tra dispositivi hardware.<\/p>

Il vincolo di MuSig2 \u00e8 che serve la collaborazione di tutti i firmatari coinvolti: \u00e8 uno schema n-di-n, non a soglia. Se anche uno solo dei partecipanti \u00e8 offline o si rifiuta di firmare, la transazione non si completa. In cambio, il risultato finale \u00e8 indistinguibile da una spesa a chiave singola: nessuno script visibile, nessun indizio sul numero di firmatari coinvolti. BitGo, che ha contribuito attivamente alla specifica finale del BIP, ha pubblicato dati concreti sul risparmio: un input firmato in key path con MuSig costa circa 57,5 vB, contro i 104,5 vB di un input SegWit nativo e i 107,5 vB di un tapscript a profondit\u00e0 1, circa il 45% in meno secondo il report tecnico di Bitcoin Optech<\/a> firmato dall’ingegnere BitGo Brandon Black. Lo stesso report descrive un contributo tecnico di BitGo alla specifica finale: solo l’ultimo firmatario della sequenza pu\u00f2 usare un nonce deterministico, il che permette di firmare da un modulo hardware (HSM) stateless, senza dover conservare stato tra un round e l’altro.<\/p>

Per portare MuSig2 nei wallet serviva anche un formato dati condiviso per scambiarsi chiavi pubbliche, nonce e firme parziali durante il processo multi-round. Lo ha fornito il BIP-373, scritto dalla core developer Ava Chow e completato il 4 giugno 2024, che aggiunge i campi necessari al formato PSBT (Partially Signed Bitcoin Transaction). Senza quello standard, ogni wallet avrebbe dovuto inventarsi un proprio formato non interoperabile. Il 4 marzo 2026 Bitcoin Core ha unito la pull request numero 34219, che aggiunge la validazione dei pubnonce e delle firme parziali MuSig2 durante la deserializzazione dei PSBT: un tassello tecnico minore ma che conferma quanto lo stack software attorno a MuSig2 sia ancora in fase di rifinitura attiva, quattro anni dopo la nascita del BIP.<\/p>

Il limite di MuSig2: cosa succede se un firmatario sparisce<\/h2>

Lo schema n-di-n di MuSig2 funziona bene quando i firmatari sono pochi e sempre raggiungibili, il caso tipico di un wallet aziendale 2-di-3 dove le tre chiavi sono su dispositivi controllati dalla stessa organizzazione. Diventa un problema quando i firmatari sono distribuiti tra parti indipendenti, con fusi orari diversi, dispositivi in manutenzione, o quando il modello di sicurezza prevede esplicitamente che una minoranza di partecipanti possa essere offline, in errore o addirittura malevola senza bloccare l’operativit\u00e0. Un consiglio di custodia composto da cinque membri che richiede tutti e cinque per muovere fondi non \u00e8 resiliente: basta un dispositivo rotto o una persona irraggiungibile per congelare i fondi.<\/p>

Per questi scenari serve uno schema a soglia vero e proprio, in cui basta che un sottoinsieme t di n partecipanti collabori. \u00c8 esattamente il problema che risolve FROST.<\/p>

FROST (BIP-445): firme a soglia t-di-n<\/h2>

FROST, acronimo di Flexible Round-Optimized Schnorr Threshold signatures, \u00e8 stato proposto nel 2020 da Chelsea Komlo (University of Waterloo e Zcash Foundation) e Ian Goldberg (University of Waterloo) in un paper accademico poi diventato lo standard IETF RFC 9591, pubblicato nel giugno 2024. Per Bitcoin, l’adattamento compatibile con le firme BIP-340 \u00e8 in corso di standardizzazione come BIP-445, assegnato a gennaio 2026 e attualmente ancora in stato di bozza: la specifica vive nel repository bip-frost-signing<\/a> dello sviluppatore Sivaram Dhakshinamoorthy, con la pull request corrispondente ancora aperta su bitcoin\/bips. Un progetto complementare guidato da Blockstream Research definisce il protocollo di generazione distribuita delle chiavi (DKG) necessario a FROST, che pu\u00f2 appoggiarsi a un dealer fidato secondo lo schema di RFC 9591 oppure a un protocollo DKG senza dealer come ChillDKG, ancora sotto sviluppo.<\/p>

La differenza pratica con MuSig2 \u00e8 nel modello di fiducia. Con FROST, la chiave privata non esiste mai per intero in nessun momento: durante la generazione distribuita, ogni partecipante calcola un proprio pezzo di chiave a partire da un polinomio segreto, e la chiave privata del gruppo esiste solo implicitamente, come somma dei termini costanti dei polinomi di tutti i partecipanti. Per firmare basta che una soglia t di n partecipanti collabori: se il gruppo \u00e8 configurato come 3 di 5, due partecipanti possono essere offline, in errore o non disponibili senza bloccare la spesa. Il risultato, anche in questo caso, \u00e8 un’unica firma Schnorr indistinguibile da una spesa a chiave singola. FROST supporta anche il rinnovo periodico delle quote di chiave: si possono rigenerare i pezzi assegnati a ciascun partecipante, invalidando eventuali copie compromesse, senza mai cambiare l’indirizzo pubblico su cui sono depositati i fondi.<\/p>

Il caso d’uso pi\u00f9 avanzato oggi \u00e8 Spark<\/a>, il layer 2 di Lightspark per Bitcoin, che usa FROST per il proprio modello di fiducia: l’utente detiene una quota della chiave, un insieme di operatori indipendenti ne detiene collettivamente un’altra tramite FROST, e basta che un solo operatore si comporti onestamente perch\u00e9 i fondi restino al sicuro, un modello descritto come 1-di-n. Anche le transazioni Spark che si regolano infine su Bitcoin layer 1 appaiono come normali spese Taproot, senza rivelare nulla sulla struttura interna del sistema di custodia sottostante.<\/p>

ROAST: cosa succede se un firmatario si comporta male<\/h2>

FROST tollera che una minoranza di partecipanti sia assente, ma ha un punto debole nella fase di coordinamento: se un firmatario partecipa al primo round e poi sparisce, o invia dati scorretti apposta, l’intera sessione di firma pu\u00f2 fallire e va ricominciata da capo, un problema soprattutto in contesti dove i partecipanti non si conoscono o non si fidano pienamente l’uno dell’altro. La soluzione si chiama ROAST, Robust Asynchronous Schnorr Threshold signatures, pubblicata da Blockstream Research il 24 maggio 2022 a firma di Tim Ruffing, Elliott Jin, Jonas Nick e alcuni collaboratori accademici. ROAST avvolge FROST con una logica che fa partire pi\u00f9 tentativi di firma in parallelo e usa il primo che va a buon fine, garantendo che i firmatari onesti riescano comunque a produrre una firma valida anche in presenza di partecipanti disonesti o di una rete inaffidabile, come spiegato nel post tecnico di Blockstream<\/a>.<\/p>

Per chi gestisce custodia istituzionale, questo dettaglio non \u00e8 secondario: un consiglio di firma che si blocca ogni volta che un partecipante \u00e8 lento o malevolo \u00e8 un rischio operativo, non solo teorico. ROAST \u00e8 oggi il complemento naturale di qualsiasi implementazione FROST pensata per ambienti dove i firmatari sono davvero indipendenti tra loro, ad esempio operatori di un layer 2 come Spark o membri di un consiglio di custodia distribuito su pi\u00f9 organizzazioni.<\/p>

Multisig legacy, MuSig2 e FROST a confronto<\/h2>

Riassumere le differenze in una tabella aiuta a capire quale schema conviene in quale scenario. Nessuno dei tre \u00e8 strettamente migliore in assoluto: sono strumenti con compromessi diversi tra semplicit\u00e0, tolleranza ai guasti e maturit\u00e0 dello standard.<\/p>

Caratteristica<\/th>Multisig legacy (P2SH\/P2WSH)<\/th>MuSig2 (BIP-327)<\/th>FROST (BIP-445)<\/th><\/tr><\/thead>
Modello<\/td>n-di-n oppure m-di-n via script<\/td>n-di-n, tutti devono collaborare<\/td>t-di-n, soglia che tollera assenze<\/td><\/tr>
Peso on chain per input<\/td>Cresce con il numero di firmatari<\/td>Circa 57,5 vB, costante<\/td>Costante, paragonabile a una spesa a chiave singola<\/td><\/tr>
Privacy on chain<\/td>La struttura dello script \u00e8 visibile pubblicamente<\/td>Indistinguibile da una spesa a chiave singola<\/td>Indistinguibile da una spesa a chiave singola<\/td><\/tr>
Tolleranza ai guasti<\/td>Dipende dalla soglia scelta nello script<\/td>Nessuna, serve la collaborazione di tutti<\/td>Alta, tollera fino a n meno t partecipanti assenti<\/td><\/tr>
Stato dello standard<\/td>Consolidato da anni<\/td>BIP-327 Deployed, PSBT via BIP-373 Complete<\/td>BIP-445 in bozza, RFC 9591 gi\u00e0 pubblicato da IETF<\/td><\/tr><\/tbody><\/table><\/figure>

Chi sta gi\u00e0 usando queste firme, in pratica<\/h2>

L’adozione non \u00e8 pi\u00f9 solo teorica. BitGo ha distribuito MuSig2 sui propri wallet Taproot caldi ed \u00e8 oggi, dopo la quotazione a Wall Street nel gennaio 2026 (NYSE: BTGO), la prima azienda di infrastrutture per asset digitali entrata nella classifica Fortune 500, con BitGo Bank & Trust che opera come banca fiduciaria per asset digitali autorizzata a livello federale dall’OCC statunitense fin dall’approvazione finale di dicembre 2025. Il CEO Mike Belshe ha commentato l’ingresso in classifica dicendo che si tratta di \u00abun traguardo importante per BitGo e per l’industria degli asset digitali\u00bb, aggiungendo che \u00able istituzioni cercano fiducia, trasparenza, solidit\u00e0 regolamentare e resilienza operativa\u00bb, come riportato nel comunicato ufficiale<\/a> del 10 giugno 2026.<\/p>

Ledger ha aggiunto il supporto a MuSig2 nella sua app Bitcoin a partire dalla versione 2.4.0, rilasciata nell’aprile 2025. Nunchuk ha lanciato un wallet multisig basato interamente su Taproot e MuSig2. Sul fronte Lightning, LND, l’implementazione pi\u00f9 diffusa di nodi Lightning, ha portato i Simple Taproot Channels in produzione con la versione 0.21-beta di giugno 2026, che usa firme parziali MuSig2 con nonce just in time anche per la chiusura cooperativa dei canali con RBF. Jameson Lopp, CTO di Casa, aveva gi\u00e0 sintetizzato il vantaggio di fondo per la privacy dei firmatari in una presentazione del 2022 poi trascritta integralmente sul suo sito: con Taproot i wallet multisig \u00abnon devono pi\u00f9 rivelare quali chiavi stavano partecipando\u00bb e possono \u00abconfondersi con la folla\u00bb, come si legge nella trascrizione integrale dell’intervento<\/a>. E come gi\u00e0 visto, Spark costruisce l’intero modello di sicurezza del proprio layer 2 attorno a FROST.<\/p>

Il contrappunto: perch\u00e9 Unchained frena su Taproot multisig<\/h2>

Non tutti i custodi si sono mossi allo stesso ritmo, ed \u00e8 un dettaglio che vale la pena raccontare perch\u00e9 bilancia l’entusiasmo attorno a queste tecnologie. Unchained Capital, uno dei nomi di riferimento negli Stati Uniti per la collaborative custody multisig, ha scelto pubblicamente di non adottare ancora MuSig2 o le firme Schnorr a soglia per i propri vault, preferendo restare su schemi basati su OP_CHECKSIGADD con pi\u00f9 foglie k-di-k dentro lo script Tapscript. Il motivo, spiegato nel suo blog tecnico<\/a> aggiornato ad aprile 2026, riguarda proprio la gestione dei nonce nei protocolli di firma interattivi: aggregare firme Schnorr richiede uno scambio di nonce tra i partecipanti che, se gestito male, con nonce riutilizzati o generati in modo prevedibile, pu\u00f2 esporre le chiavi private, un rischio ben documentato nella letteratura crittografica sugli schemi di firma multi-round.<\/p>

La differenza con BitGo non \u00e8 tanto tecnologica quanto operativa: BitGo firma con dispositivi e software che controlla direttamente, e pu\u00f2 quindi gestire la generazione dei nonce con margini di sicurezza noti. Unchained lavora invece in un modello di custodia collaborativa dove cliente e istituzione condividono le chiavi su hardware wallet di terze parti, spesso di marche diverse, e non pu\u00f2 imporre aggiornamenti software unilaterali a tutti i partecipanti. Come nota lo stesso blog, per quello scenario \u00abnon esistono ancora best practice consolidate\u00bb per il multisig su Taproot. \u00c8 un promemoria utile: l’adozione di MuSig2 e FROST non \u00e8 un interruttore acceso o spento per l’intero settore, ma una scelta che ogni custode pesa in base al proprio modello di minaccia specifico.<\/p>

Bybit, WazirX: cosa cambia (e cosa no) con le firme native<\/h2>

I furti multisig pi\u00f9 grandi della storia recente delle crypto non sono nati da chiavi rubate, ma da firmatari che hanno approvato qualcosa di diverso da quello che pensavano di approvare. Bybit ha perso circa 1,5 miliardi di dollari il 21 febbraio 2025, il furto crypto pi\u00f9 grande mai registrato, dopo che un aggressore ha compromesso il dispositivo di uno sviluppatore di Safe{Wallet} e alterato l’interfaccia al momento della firma, cos\u00ec che i firmatari legittimi hanno autorizzato un trasferimento diverso da quello mostrato a schermo: le chiavi non sono mai state rubate, come ha ricostruito un’indagine indipendente<\/a> che ha attribuito l’attacco al gruppo Lazarus. WazirX ha perso circa 230 milioni di dollari nel luglio 2024, quasi met\u00e0 delle sue riserve, con una dinamica simile: uno scarto tra quello che l’interfaccia di custodia di Liminal mostrava e i dati reali della transazione ha convinto quattro firmatari su sei ad approvare un payload nascosto, come ricostruito da Halborn<\/a>. Un copione simile, per decine di milioni di dollari, ha colpito pochi mesi dopo anche Radiant Capital.<\/p>

Questi tre casi riguardano wallet smart contract su reti EVM, non il multisig nativo di Bitcoin, ma la lezione si applica anche a MuSig2 e FROST: aggregare le firme in un’unica firma Schnorr elimina lo script visibile e quindi il segnale che comunica un bersaglio di alto valore, ma non elimina di per s\u00e9 il problema di fondo, cio\u00e8 sapere con certezza cosa si sta firmando. Un coordinatore di firma malevolo o compromesso potrebbe in teoria presentare a un firmatario dati diversi da quelli reali, esattamente come \u00e8 successo con l’interfaccia di Safe. La differenza \u00e8 che il protocollo di firma di Bitcoin, tramite PSBT, \u00e8 pensato per essere verificato in chiaro riga per riga, destinatari, importi, fee, su un dispositivo separato prima di firmare. Alcune regole operative restano valide indipendentemente dallo schema di firma scelto:<\/p>