bitcoinforfreedom.it
Schema di un wallet Bitcoin multisig 2-di-3 e matrice delle soglie Tre chiavi indipendenti (K1, K2, K3) generano un indirizzo multisig 2-di-3. Lo script di riscatto richiede due firme su tre per spendere i fondi. La parte inferiore mostra una matrice 3x4 con la soglia M-di-N e l'effetto di perdita o furto di una o due chiavi. MULTISIG 2-DI-3 QUORUM + MATRICE SOGLIE K1 firmatario A K2 firmatario B K3 recovery SCRIPT P2WSH 2 / 3 descrittore BIP-380 firma con PSBT BIP-174 MATRICE SOGLIE soglia perdi 1 chiave perdi 2 chiavi rubano 1 chiave 2-di-2 bloccante recuperabile non sufficiente 2-di-3 recuperabile bloccante non sufficiente 3-di-5 recuperabile recuperabile non sufficiente

Bitcoin, dalle basi

Multisig Bitcoin: soglie, backup e piano di recupero

Tempo di lettura: 14 min

Un indirizzo multisig Bitcoin richiede M firme su N chiavi: con un 2-di-3 servono due firme su tre, codificate in uno script P2WSH o P2SH e gestite con PSBT (BIP-174) e descrittori di output (BIP-380). Il multisig distribuisce il rischio di furto e perdita, ma richiede una prova di ripristino completa prima di spostare importi reali.

Indice della guida13 sezioni
  1. Che cos'è davvero un indirizzo multisig
  2. Perché esiste, se una sola firma già funziona
  3. Soglie consigliate e relativi compromessi
  4. Come si costruisce un indirizzo multisig oggi
  5. Firma in aria: PSBT, firma distribuita e ricomposizione
  6. Standard di configurazione: BSMS e wallet di nuova generazione
  7. Perché il multisig non è per tutti
  8. Matrice delle modalità di errore
  9. Come si esegue una prova di ripristino
  10. Quando una struttura più evoluta ha senso
  11. Relazione con la custodia single-sig
  12. Checklist operativa
  13. Verifica e limiti

Che cos'è davvero un indirizzo multisig

In Bitcoin, un indirizzo multisig nasconde uno script che richiede più firme. La specifica originale BIP-11 ha standardizzato i pagamenti M-di-N usando un template OP_CHECKMULTISIG: un output richiede almeno M firme su N chiavi pubbliche fornite per essere speso. Le firme raccolte devono corrispondere, nell'ordine stabilito dallo script, alle chiavi annunciate.

Questo tipo di script può essere esposto sulla catena (indirizzi bare-multisig 1..., oggi deprecati per ragioni di efficienza, privacy e difetti storici come il bug off-by-one in OP_CHECKMULTISIG) oppure incapsulato in un P2SH (indirizzi 3...) o in un P2WSH (indirizzi bc1q... con 32 byte di witness). Le tre forme ottengono lo stesso effetto logico, ma cambiano costi, footprint sulla catena, e resistenza al fee-sniping post-SegWit. La sezione multisig della guida per sviluppatori documenta l'esempio canonico 2-di-3 in P2SH, completo di script redeem e scriptPubKey.

Una conseguenza spesso sottovalutata: la soglia M-di-N e la lista delle N chiavi sono impresse nello script. Cambiare la soglia o aggiungere una chiave dopo la prima transazione di funding significa spostare i fondi su un nuovo indirizzo multisig. Non esiste un'operazione di "aggiungi firmatario" on-chain.

Perché esiste, se una sola firma già funziona

Un portafoglio single-sig richiede una sola firma, prodotta da una sola chiave privata. Se la chiave è compromessa, i fondi sono persi. Se il supporto che custodisce la chiave viene distrutto senza backup, i fondi sono persi allo stesso modo. Il multisig distribuisce entrambi i rischi: per rubare i fondi serve compromettere almeno M chiavi distinte; per perderli serve perdere almeno N − M + 1 chiavi.

Questo spostamento è il valore aggiunto. Per importi contenuti, un single-sig con una buona procedura di backup può essere sufficiente: la complessità operativa del multisig non è gratis, e una configurazione mal gestita può essere meno sicura di un single-sig ben custodito. Per importi rilevanti, per casse condivise fra più persone, o per casse che devono sopravvivere all'incapacità o alla morte del titolare, il multisig diventa una scelta difendibile. La pagina sulla seed phrase suggerisce esplicitamente il multisig "per importi rilevanti" come passo successivo alla singola mnemonic, dopo aver verificato che il backup è ripristinabile e che la procedura di recovery è ripetibile.

Soglie consigliate e relativi compromessi

Non esiste una soglia universalmente corretta. Il compromesso riguarda il numero di chiavi, la distribuzione geografica, la resistenza al furto e la resistenza alla perdita. Una matrice decisionale utile:

Soglia Resistenza al furto Resistenza alla perdita Complessità operativa Uso tipico
2-di-2 alta (servono entrambe le chiavi) bassa (perderne una è fatale) bassa trustee duali, escrow, casse con operatore e cassiere
2-di-3 media (compromettere 2 chiavi è difficile) alta (perderne 1 è recuperabile) media custodia personale strutturata, casse familiari
3-di-5 alta (servono 3 chiavi) molto alta (perderne 2 è ancora recuperabile) alta casse aziendali, escrow professionali, trust
3-di-4 alta media (perderne 2 è fatale) media-alta team operativi con un dispositivo di riserva

Una regola pratica: per uso personale, il 2-di-3 è spesso il miglior compromesso fra costo operativo e protezione. Con due dispositivi e una terza chiave di recovery offline, si tollera la perdita di un dispositivo e si alza significativamente la barra per un attaccante. Una 4ª o 5ª chiave diventa utile quando il contesto lo richiede, ad esempio trustee indipendenti o firme in luoghi fisici diversi.

Come si costruisce un indirizzo multisig oggi

Il modo moderno per descrivere un portafoglio multisig è il descrittore di output definito nella specifica BIP-380 e nella documentazione descriptor di Bitcoin Core. Un descrittore multisig 2-di-3 con tre chiavi Xpub si scrive, in forma sintetica, come wsh(sortedmulti(2,xpub1.../<0;1>/*,xpub2.../<0;1>/*,xpub3.../<0;1>/*)). Il descrittore non è la chiave privata: è la formula per derivare gli indirizzi, controllabile da chiunque e replicabile fra portafogli compatibili.

I passaggi operativi, da eseguire su dispositivi fidati e in un ambiente offline, sono:

  1. Generare una chiave per ciascun cofirmatario, in modo indipendente. Annotare la key origin (per esempio fingerprint/path) per ricondurre ogni xpub al dispositivo che l'ha generata.
  2. Ordinare le chiavi in modo deterministico prima di codificarle nello script: BIP-67 richiede l'ordinamento lessicografico delle chiavi pubbliche, per garantire che due portafogli indipendenti producano lo stesso indirizzo a partire dallo stesso set di chiavi. Senza ordinamento, ogni firmatario potrebbe calcolare un indirizzo diverso e i fondi andrebbero persi.
  3. Codificare l'elenco ordinato in un descrittore e generare l'indirizzo di ricezione. Verificare che ogni firmatario, in modo indipendente, derivi lo stesso indirizzo dallo stesso descrittore. È un passaggio di sanity check non opzionale.
  4. Conservare il descrittore, le key origin, gli xpubs e i percorsi di derivazione. Senza queste informazioni, anche con tutte le chiavi private, il portafoglio potrebbe non ricostruire gli indirizzi corretti.

Firma in aria: PSBT, firma distribuita e ricomposizione

Dopo SegWit e Taproot, lo standard per coordinare le firme fra più dispositivi è il PSBT (Partially Signed Bitcoin Transaction), aggiornato alla versione 2 nel BIP-370. Il PSBT è un contenitore che trasporta una transazione Bitcoin con i metadati necessari a ciascun firmatario: gli input da firmare, gli importi, gli script, gli xpubs coinvolti. Il flusso operativo, valido per multisig e per i portafogli single-sig che vogliono mantenere la chiave offline, è:

  1. Un partecipante (o un coordinatore) crea la transazione, anche non firmata, e la esporta come PSBT. Questo può avvenire su un dispositivo connesso.
  2. Il PSBT viene trasferito, via QR, file o cavo, a ciascun dispositivo firmatario, idealmente in modo air-gapped.
  3. Ogni firmatario verifica la transazione (destinatari, importi, commissioni) sul proprio schermo, aggiunge la propria firma, ed esporta il PSBT aggiornato.
  4. L'ultimo firmatario (o un raccoglitore) combina le firme e finalizza la transazione, che viene poi trasmessa alla rete.

Il vantaggio è che ogni firmatario vede l'operazione completa, senza esporre la propria chiave privata, e senza dover fidarsi del coordinatore per la correttezza degli importi. Il flusso PSBT funziona anche con Taproot e Tapscript, dove le firme Schnorr possono essere aggregate: una transazione Taproot multisig, una volta finalizzata, mostra in catena un'unica firma, indipendentemente dal numero di firmatari che hanno contribuito.

Standard di configurazione: BSMS e wallet di nuova generazione

Costruire manualmente descrittori, ordinare le chiavi e verificare l'indirizzo finale è una procedura che lascia spazio a errori. Lo standard BSMS (Bitcoin Secure Multisig Setup) definisce un formato di file scambiato fra portafogli compatibili, che contiene la soglia, i cofirmatari con key origin, i percorsi di derivazione e le reti supportate. Lo standard mira a tre obiettivi: identificare in modo univoco ciascun firmatario, garantire che tutti i portafogli producano gli stessi indirizzi, e rendere la configurazione riproducibile su un dispositivo sostitutivo in caso di guasto.

Anche con BSMS, l'operazione umana resta critica: la generazione delle chiavi deve avvenire in un ambiente non compromesso, la verifica dell'indirizzo deve essere ripetuta su schermi indipendenti, e il backup delle informazioni (xpubs, key origin, fingerprint) deve essere conservato con la stessa cura della seed phrase.

Perché il multisig non è per tutti

La complessità operativa ha un costo reale. I passaggi che un single-sig evita — generare più chiavi, ordinarle, costruire e verificare il descrittore, scambiare PSBT, ricombinare le firme — sono il motivo per cui un single-sig ben eseguito è spesso più sicuro di un multisig configurato frettolosamente. Le insidie più ricorrenti, viste anche nelle discussioni tecniche pubbliche, sono:

  • Ordinamento non deterministico delle chiavi: senza BIP-67, due portafogli producono due indirizzi diversi, e i fondi inviati al primo sono persi per il secondo firmatario.
  • Backup incompleto: conservare solo le chiavi private e non il descrittore rende impossibile ricostruire l'albero di derivazione. Conservare solo il descrittore senza le chiavi rende la cassa inaccessibile.
  • Firme in ambienti non verificati: importare un PSBT in un wallet compromesso equivale a firmare alla cieca.
  • Soglia sbagliata per il profilo di rischio: un 2-di-2 è robusto al furto ma fragile alla perdita, e in contesti dove un firmatario potrebbe essere temporaneamente irreperibile (viaggio, malattia) diventa inutilizzabile.
  • Mancata prova di ripristino: non avere verificato, in un momento di calma, che il portafoglio ricostruisce lo stesso indirizzo a partire dai backup. Quando serve, è troppo tardi.

Matrice delle modalità di errore

Una mappa delle conseguenze pratiche aiuta a ragionare sulla soglia e sulla distribuzione delle chiavi. Le voci non sono mutuamente esclusive.

Modalità 2-di-2 2-di-3 3-di-5
Perdita di una chiave bloccante recuperabile recuperabile
Perdita di due chiavi recuperabile se ne resta una firmabile? No: 2-di-2 richiede entrambe bloccante recuperabile se ne restano 3
Furto di una chiave non ancora sufficiente non ancora sufficiente non ancora sufficiente
Furto di due chiavi sufficiente per 2-di-2 sufficiente per 2-di-3 non ancora sufficiente per 3-di-5
Firmatario irreperibile per giorni blocco operativo uno dei due firmatari ancora firmabile due alternative ancora firmabili
Dispositivo contraffatto al setup una chiave compromessa una chiave compromessa, altre due integre una compromessa su cinque

La riga più sottovalutata è l'ultima. Se uno dei dispositivi usati per generare la chiave è contraffatto o compromesso al momento del setup, l'attaccante può ottenere una chiave senza che il firmatario se ne accorga. La verifica della provenienza del dispositivo, del firmware e della catena di fornitura è parte integrante del setup, non un dettaglio.

Come si esegue una prova di ripristino

Il setup multisig va considerato non finito finché una prova offline non dimostra che, partendo dai soli backup, due firmatari indipendenti possono ricostruire lo stesso indirizzo e firmare una transazione di prova. La procedura consigliata:

  1. In un momento di calma, su dispositivi resettati e offline, importare ciascuna chiave dal proprio backup (seed phrase, scheda di recovery, file cifrato, a seconda del portafoglio).
  2. Importare il descrittore, oppure scambiare un file BSMS, e verificare che ogni dispositivo derivi lo stesso indirizzo di ricezione. Tre indirizzi coincidenti su tre dispositivi distinti sono la prova minima.
  3. Costruire una transazione di prova che sposta un importo simbolico dall'indirizzo multisig a un nuovo indirizzo single-sig controllato.
  4. Far girare il PSBT fra i firmatari, raccogliere le firme, trasmettere la transazione. Verificare che il saldo si aggiorni coerentemente.
  5. Cancellare la transazione di prova, ripristinare i dispositivi, conservare i backup nella loro collocazione definitiva.

Una prova di ripristino che fallisce è una scoperta utile, non una perdita: significa che il setup ha un problema che andava trovato prima di spostare importi reali. Una prova che ha successo va ripetuta ogni volta che cambiano hardware, firmware, descrittore, o uno dei cofirmatari.

Quando una struttura più evoluta ha senso

Una volta padroneggiato un multisig 2-di-3 con PSBT e descrittori, si può considerare il passaggio a strutture che migliorano privacy o riducono i costi on-chain. BIP-48 definisce uno standard per portafogli multi-script multi-key, utile per chi vuole gestire con un unico set di chiavi sia un indirizzo P2WSH multisig, sia un percorso single-sig di riserva. BIP-341 e BIP-342 introducono Taproot e Tapscript, che consentono multisig che, in catena, appare come un normale single-sig con un'unica chiave, migliorando la privacy e abbassando il costo per i casi cooperativi.

Questi passaggi non sono indispensabili per la maggior parte degli utenti. Il multisig classico, con P2WSH o P2SH, ha specifiche stabili, implementazioni mature e un ecosistema di portafogli e strumenti ampio. Le varianti più recenti vanno valutate solo dopo che la struttura di base è solida, i backup verificati e la procedura di ripristino ripetibile.

Relazione con la custodia single-sig

Il multisig non sostituisce il single-sig: lo affianca. Una struttura ragionevole può prevedere:

  • una cassa principale multisig, in cold storage su dispositivi dedicati, da cui si sposta solo per ragioni specifiche;
  • una cassa operativa single-sig, su portafoglio caldo, con importi limitati, usata per la spesa corrente;
  • una cassa di test multisig, con importi simbolici, su cui esercitarsi prima di toccare la cassa principale.

Il criterio di scelta della soglia resta lo stesso: quanto è tollerabile perdere in una volta sola, e quanto è accettabile che un singolo evento (furto, disastro, errore umano) renda inaccessibile l'intera cassa. Una struttura con un full node proprio, che verifica in autonomia le transazioni della cassa multisig, chiude il cerchio: il nodo controlla che gli output osservati corrispondano agli script previsti dal descrittore, e che le commissioni siano coerenti con il mempool osservato.

Checklist operativa

  1. Definire la soglia M-di-N in base al profilo di rischio, al numero di cofirmatari e alla tolleranza operativa.
  2. Generare le chiavi su dispositivi indipendenti, verificandone provenienza e firmware. Annotare fingerprint, percorso di derivazione e xpub di ciascuna.
  3. Ordinare le chiavi secondo BIP-67 e codificarle in un descrittore o in un file BSMS.
  4. Verificare che ogni dispositivo, in modo indipendente, derivi lo stesso indirizzo dallo stesso descrittore. Tre dispositivi, tre indirizzi coincidenti.
  5. Custodire chiavi, descrittore e key origin su supporti diversi in luoghi fisici separati, con la stessa cura di una seed phrase.
  6. Inviare un importo di prova, far girare il PSBT fra i firmatari, ricombinare le firme e verificare la transazione finale su un nodo proprio.
  7. Ripetere la prova di ripristino almeno una volta l'anno, e ogni volta che cambiano hardware, firmware, descrittore o cofirmatari.
  8. Aggiornare il piano documentato: chi sono i cofirmatari, dove sono i backup, come si ricostruisce la cassa, chi avvertire in caso di emergenza.

Verifica e limiti

Questa pagina è stata verificata il 5 ottobre 2026 sulle specifiche BIP-11, BIP-16, BIP-67, BIP-129, BIP-174, BIP-341, BIP-342, BIP-370, BIP-380 e BIP-48, oltre alla sezione multisig della guida per sviluppatori Bitcoin e alla documentazione descriptor di Bitcoin Core.

Le soglie e i compromessi descritti non sono raccomandazioni operative per il singolo lettore: sono una matrice decisionale da adattare al proprio profilo di rischio, al valore esposto e alla capacità di gestire la complessità. Le implementazioni software (Sparrow, Nunchuk, Electrum, Specter, BTCPay Server, Liana) differiscono su dettagli di setup, scambio PSBT e integrazione con hardware wallet: prima di mettere in produzione una cassa multisig, vale la pena leggere la documentazione specifica dello strumento scelto e fare una prova di ripristino completa. Questa pagina non offre consulenza finanziaria né una garanzia di funzionamento: spiega il protocollo e ne dichiara i limiti, lascia all'utente la scelta delle chiavi, dei dispositivi e delle procedure.