Il 31 ottobre \u00e8 una data che chi segue Bitcoin conosce a memoria: diciotto anni fa, nel 2008, Satoshi Nakamoto pubblicava il white paper. Quest’anno la vigilia arriva carica di tensione, ma per un motivo diverso. Domani Paul Sztorc e LayerTwo Labs faranno partire ECX, una hard fork che copia il registro di Bitcoin e volta le spalle al processo delle soft fork, mentre sul ramo principale il tentativo di attivare la BIP-54 resta impantanato da mesi. I titoli parlano di scismi, di aggiornamenti che non riescono a partire, di una comunit\u00e0 che litiga su come, e perfino se, toccare ancora il protocollo.<\/p>
Eppure la trasformazione pi\u00f9 concreta che Bitcoin ha vissuto negli ultimi dodici mesi non ha richiesto nessun fork nuovo. \u00c8 arrivata quasi in silenzio, dentro i wallet, grazie a un aggiornamento che \u00e8 legge dal novembre 2021: Taproot. La sua eredit\u00e0 pi\u00f9 sottovalutata non sono gli Ordinals, i covenant o i rollup di cui si riempiono le cronache, ma qualcosa di molto pi\u00f9 noioso e molto pi\u00f9 usato: le firme di soglia, cio\u00e8 la crittografia che permette a molte chiavi di comportarsi, agli occhi della blockchain, come se fossero una sola. Con Bitcoin intorno ai 69.400 euro (CoinGecko<\/a>, 30 ottobre 2026, in rialzo di circa il 5 per cento in ventiquattro ore), vale la pena guardare dove Taproot ha vinto davvero.<\/p> La cronaca recente di Bitcoin \u00e8 fatta di scontri sul consenso. Da una parte c’\u00e8 chi, come il fronte di ECX, ha deciso che le soft fork sono ormai impossibili da attivare e ha preferito duplicare la catena e andarsene, uno strappo che abbiamo raccontato nel dettaglio nell’analisi sullo scisma Bitcoin del 31 ottobre<\/a>. Dall’altra ci sono proposte come la BIP-54 e i covenant, ferme a una manciata di punti percentuali di segnalazione dei miner. Il messaggio implicito \u00e8 che Taproot, attivato il 14 novembre 2021 al blocco 709.632 (CoinDesk<\/a>), resti l’ultimo aggiornamento del protocollo entrato in vigore, e che da allora il motore del cambiamento si sia inceppato.<\/p> \u00c8 una lettura che guarda solo il livello del consenso. Perch\u00e9 Taproot non \u00e8 stato un singolo interruttore, ma una cassetta degli attrezzi composta da tre proposte distinte.<\/p> La parte che pi\u00f9 ha cambiato la vita pratica agli utenti non \u00e8 quella degli script complicati, ma la prima: Schnorr. Ed \u00e8 da l\u00ec che nasce una rivoluzione silenziosa della custodia, fatta non di nuovi opcode ma di un modo diverso di firmare. Mentre il dibattito pubblico si consuma sulle proposte che non partono, questa parte di Taproot \u00e8 semplicemente andata in produzione, un wallet alla volta.<\/p> Per anni il multisig di Bitcoin ha funzionato in modo robusto ma trasparente: per spendere da un portafoglio 2-di-3 occorreva mostrare sulla blockchain tre chiavi pubbliche e almeno due firme separate, una accanto all’altra. Chiunque guardasse la transazione vedeva lo schema esatto: quante chiavi, quale soglia, quali avevano firmato. Questo perch\u00e9 l’algoritmo di firma storico di Bitcoin, ECDSA, non si presta a essere combinato in modo pulito; ogni firmatario resta un’entit\u00e0 visibile e separata.<\/p> Le firme Schnorr introdotte con la BIP-340 hanno una propriet\u00e0 matematica che a ECDSA manca: sono lineari. In termini semplici, due chiavi pubbliche possono essere sommate in una terza chiave, e le rispettive firme possono essere combinate in una firma unica, valida per quella chiave aggregata. L’idea non \u00e8 nuova (le prime proposte di firme aggregate alla Bellare-Neven circolano da oltre un decennio), ma solo con Taproot \u00e8 diventata utilizzabile sulla rete principale di Bitcoin. Il risultato, sulla catena, \u00e8 spiazzante: un portafoglio controllato da tre persone pu\u00f2 apparire identico a un portafoglio con una sola chiave. Da questa semplice idea discendono due protocolli che nel 2026 sono diventati lo standard di fatto della custodia avanzata: MuSig2 e FROST.<\/p> Per capire la portata del cambiamento conviene un paragone. Con ECDSA un multisig \u00e8 come un documento che richiede pi\u00f9 firme autografe affiancate: chiunque lo guardi conta le firme e riconosce i firmatari. Con Schnorr, invece, le firme si fondono in un unico tratto di penna che vale per tutti insieme e risulta identico a quello di una persona sola. La blockchain registra solo quel tratto finale, non il processo che lo ha prodotto. La differenza non tocca le garanzie di sicurezza, perch\u00e9 servono sempre le chiavi giuste per spendere, ma cancella l’informazione su quante e quali chiavi ci siano dietro. \u00c8 un cambiamento che agisce su due piani insieme: la dimensione dei dati scritti sulla catena e la quantit\u00e0 di metadati che quei dati rivelano. Per la prima volta, nella storia di Bitcoin, un portafoglio condiviso da un consiglio di amministrazione e un portafoglio personale possono essere letteralmente indistinguibili. \u00c8 su questa indistinguibilit\u00e0 che si gioca tutto il resto.<\/p> MuSig2 \u00e8 il primo dei due mattoni. Specificato nella BIP-327<\/a> (autori Jonas Nick, Tim Ruffing ed Elliott Jin, stato \u00abDeployed\u00bb), permette a pi\u00f9 firmatari di generare insieme un’unica chiave pubblica aggregata e di produrre una normale firma Schnorr compatibile con Taproot. Il protocollo lavora in due round: nel primo i partecipanti si scambiano dei valori casuali chiamati nonce, nel secondo le firme parziali, che vengono poi combinate. Il prodotto finale \u00e8 una firma sola, da 64 byte, indistinguibile da quella di un portafoglio con una chiave. Non \u00e8 un caso che si chiami MuSig2: la prima versione, MuSig1, richiedeva tre round di comunicazione, e ridurli a due \u00e8 stato il salto che ha reso lo schema abbastanza pratico da finire nei wallet di consumo.<\/p> E nei wallet ci \u00e8 finito davvero. Ledger ha portato MuSig2 dentro la sua Bitcoin app nella versione 2.4.0, uscita nell’aprile 2025 (Ledger<\/a>). Nel presentarlo, gli autori del post, l’ingegnere Salvatore Ingala e il crittografo Yannick Seurin (tra i firmatari del paper originale su MuSig2 del 2020), hanno spiegato che \u00absi pu\u00f2 creare un output multisig con una sola chiave pubblica e convalidare una transazione che lo spende con una sola firma, indipendentemente dal numero di parti coinvolte\u00bb. E hanno aggiunto il punto che conta di pi\u00f9: un output MuSig2 non \u00e8 in alcun modo distinguibile da un comune output a chiave singola, perci\u00f2 \u00abla privacy arriva come bonus in cima al risparmio di spazio\u00bb. \u00c8 una frase che riassume l’intera tesi di questo articolo.<\/p> MuSig2 non vive solo nei portafogli multi-persona. Trova impiego anche dove un singolo utente vuole distribuire il rischio tra pi\u00f9 dispositivi, per esempio una chiave sul telefono e una su un hardware wallet, oppure nella gestione del cold storage di un exchange, dove firmare con una chiave aggregata evita di rivelare ai concorrenti e agli analisti la struttura interna dei caveau. Ed \u00e8 il mattone su cui Lightning costruisce i suoi canali di nuova generazione, come vedremo pi\u00f9 avanti. In tutti questi casi il vantaggio \u00e8 lo stesso: meno dati sulla catena, meno impronte, meno superficie di attacco informativa. La frenata, semmai, non \u00e8 nella crittografia ma nell’hardware: perch\u00e9 un hardware wallet possa partecipare a una firma MuSig2 deve gestire correttamente i nonce segreti, e questo richiede firmware aggiornato e verificato. \u00c8 il motivo per cui prodotti come il portafoglio di Nunchuk, pur usando MuSig2, all’inizio hanno accettato solo chiavi software. La teoria \u00e8 pronta da anni; i dispositivi fisici arrivano a scaglioni.<\/p> MuSig2 ha un limite: nella sua forma pura \u00e8 uno schema n-di-n, cio\u00e8 richiede la firma di tutti i partecipanti. Per la maggior parte dei portafogli reali, dove si vuole uno schema 2-di-3 o 3-di-5 proprio per sopravvivere alla perdita di una chiave, serve qualcosa di pi\u00f9 flessibile. Quel qualcosa \u00e8 FROST (Flexible Round-Optimized Schnorr Threshold), ideato da Chelsea Komlo e Ian Goldberg nel 2020 e standardizzato dall’IRTF nel giugno 2024 come RFC 9591<\/a>, con una suite dedicata alla curva secp256k1 usata da Bitcoin.<\/p> FROST generalizza l’idea di MuSig2 a uno schema t-di-n: bastano t firmatari sugli n totali, e i restanti possono restare offline senza bloccare la spesa. Anche qui il risultato \u00e8 una singola firma Schnorr da 64 byte, indistinguibile dalle altre. La distribuzione iniziale delle chiavi avviene con un protocollo di generazione distribuita (DKG) in cui nessuno vede mai la chiave completa, un’alternativa pi\u00f9 sicura rispetto a spezzare a posteriori un segreto unico. Per Bitcoin il lavoro di standardizzazione prosegue con la proposta BIP-445 (variante FROST3, assegnata a gennaio 2026, ancora in bozza) e con il protocollo di generazione delle chiavi ChillDKG. A irrobustire il tutto c’\u00e8 ROAST, un involucro proposto da Tim Ruffing e colleghi di Blockstream che garantisce la produzione della firma anche quando la rete \u00e8 asincrona e alcuni firmatari sono lenti o ostili (Blockstream<\/a>). Implementazioni di FROST girano gi\u00e0 in produzione, dalla libreria libsecp256k1-zkp alla ZF FROST della Zcash Foundation, fino al layer 2 Spark.<\/p>Mentre si litiga sui fork, Taproot ha gi\u00e0 vinto altrove<\/h2>
Che cosa significa davvero firma aggregata<\/h2>
MuSig2 (BIP-327): il multisig che sembra un wallet qualunque<\/h2>
FROST: quando bastano t firme su n<\/h2>