
Bitcoin, dalle basi
Taproot: firme, condizioni di spesa e limiti della privacy
Taproot è un insieme di regole Bitcoin che combina firme Schnorr e condizioni di spesa organizzate in una struttura ad albero. Quando si utilizza il percorso basato sulla chiave, alcune condizioni alternative non vengono rivelate sulla catena. Il beneficio dipende dalla transazione e dal software utilizzato: Taproot non rende automaticamente anonimi né elimina ogni costo.
Indice della guida10 sezioni
- Il problema concreto: condizioni che servono solo in alcuni casi
- Prima distinzione: gli output contengono condizioni, non monete separate
- Che cosa aggiungono le firme Schnorr
- Il percorso basato sulla chiave
- Il percorso basato su uno script
- Tre situazioni a confronto
- Perché il backup richiede più attenzione del nome del formato
- Dove finiscono i benefici di privacy
- Come confrontare costi senza scegliere un esempio favorevole
- Conclusioni: valutare il percorso che si userà davvero
Report retrospettivo: riferimento 4 ottobre 2026; pubblicazione 11 ottobre 2026. Confronto documentale dei BIP 340 e 341 consultati l’11 ottobre.
Il problema concreto: condizioni che servono solo in alcuni casi
Immaginiamo una custodia condivisa. Nel funzionamento ordinario i partecipanti collaborano, ma il progetto prevede anche una procedura di recupero utilizzabile a condizioni prestabilite. Pubblicare ogni dettaglio di tutti i percorsi a ogni pagamento può rivelare informazioni non necessarie al caso che si sta eseguendo.
Taproot permette di organizzare questi percorsi in modo che alcune informazioni restino non rivelate quando non servono alla validazione della spesa scelta. Per capire il vantaggio bisogna però distinguere il controllo di una chiave dalla dimostrazione di una condizione alternativa. Non basta che un portafoglio offra un nuovo formato di indirizzo per sapere come utilizzi queste possibilità.
Il riferimento tecnico di questo report è il confronto fra BIP 340, sulle firme Schnorr, e BIP 341, sulle regole di spesa Taproot. Entrambi risultano «Deployed» nei documenti consultati. Il confronto riguarda proprietà del protocollo, che vanno tenute distinte dalle funzioni offerte da una particolare applicazione.
Prima distinzione: gli output contengono condizioni, non monete separate
Un saldo Bitcoin deriva da output non spesi che il portafoglio può utilizzare secondo determinate condizioni. Una nuova transazione consuma output precedenti e ne crea altri. La guida agli UTXO Bitcoin illustra questo passaggio e il ruolo del resto.
Taproot riguarda un tipo di queste condizioni. Quando viene creato un output, la catena contiene un impegno crittografico che consente determinate modalità di spesa. Le informazioni richieste quando quell’output sarà consumato dipendono dal percorso effettivamente usato. Creazione e spesa, quindi, non mostrano necessariamente lo stesso livello di dettaglio.
Questa distinzione rende più precisa anche la discussione sulla privacy. Una condizione può restare nascosta pur essendo pubblici l’importo dell’output e il suo collegamento alla transazione che lo spende. Ridurre l’informazione rivelata su una regola non significa cancellare tutte le relazioni osservabili nella catena.
Che cosa aggiungono le firme Schnorr
Il BIP 340 definisce firme Schnorr sulla curva secp256k1. Fra le proprietà rilevanti vi sono la struttura delle firme e le possibilità che questa offre ai protocolli di collaborazione tra firmatari. L’applicazione concreta richiede comunque un protocollo appropriato, una gestione corretta del materiale sensibile e software compatibile.
Una firma Schnorr definita dal BIP 340 ha dimensione di 64 byte. Questo numero non è la dimensione di una transazione Taproot. Una transazione contiene altri dati e può avere più input e output. Inoltre, nel percorso Taproot possono comparire informazioni aggiuntive, come il byte che specifica una modalità di firma non predefinita.
Usare la dimensione della sola firma per promettere una percentuale universale di risparmio sarebbe quindi scorretto. Il confronto deve includere la struttura completa delle transazioni confrontate e il percorso di spesa scelto. Anche il costo in valuta dipende dal tasso di commissione del momento, non soltanto dai byte.
La combinazione di chiavi o firme non nasce automaticamente perché più persone partecipano alla custodia. Servono strumenti che implementino la collaborazione prevista. Un multisig Bitcoin descrive una politica di autorizzazione; non identifica da solo il protocollo crittografico con cui essa viene realizzata.
Il percorso basato sulla chiave
Nel percorso chiamato key path la spesa viene autorizzata attraverso una firma valida per la chiave prevista dall’output. Se la struttura è stata progettata con un protocollo di collaborazione appropriato, più partecipanti possono contribuire a produrre questa autorizzazione senza pubblicare sulla catena tutti i dettagli del loro coordinamento.
Il BIP 341 spiega che, quando si usa questo percorso, non viene rivelato se fossero disponibili anche percorsi alternativi basati su script. Per un osservatore della catena, una spesa cooperativa può quindi non esporre condizioni di recupero rimaste inutilizzate. È un beneficio circoscritto e verificabile, non una promessa di anonimato complessivo.
La progettazione deve però essere coerente. Un percorso basato sulla chiave che permette di spendere immediatamente non diventa bloccato soltanto perché nell’albero esiste un altro ramo con un’attesa. Le condizioni alternative non si sommano automaticamente: ciascun percorso deve rappresentare l’autorizzazione effettivamente voluta dai partecipanti.
Il percorso basato su uno script
Nel percorso chiamato script path si rivela lo script utilizzato insieme alle informazioni necessarie a dimostrare che appartiene alla struttura impegnata nell’output. Non è necessario pubblicare in chiaro tutti gli altri script dell’albero. La quantità e il tipo di informazioni da fornire dipendono dal ramo scelto e dalla sua posizione.
Questo percorso può servire, per esempio, quando la collaborazione ordinaria non è disponibile e occorre utilizzare una condizione alternativa prevista fin dall’inizio. L’esempio resta concettuale: la disponibilità di una procedura di recupero dipende da come sono stati costruiti output, chiavi, vincoli e backup.
Una volta utilizzato un ramo, le condizioni rivelate diventano parte della storia pubblica della spesa. Alcune informazioni prima nascoste possono dunque diventare osservabili. Il vantaggio va valutato lungo l’intero ciclo di vita dell’output, compreso il caso meno frequente del recupero.
Tre situazioni a confronto
La tabella è una sintesi originale dei meccanismi descritti nei BIP. Non attribuisce a specifici portafogli funzionalità testate e non esprime una classifica di sicurezza. Serve a separare ciò che viene dimostrato sulla catena da ciò che rimane nel coordinamento dei partecipanti.
| Situazione illustrativa | Percorso utilizzato | Informazione resa necessaria alla spesa | Limite da ricordare |
|---|---|---|---|
| Autorizzazione ordinaria attraverso la chiave prevista | Key path | Firma valida per la chiave dell’output | Non nasconde importi e collegamenti della transazione |
| Collaborazione prevista tra più firmatari | Key path, se il protocollo scelto lo consente | Autorizzazione aggregata risultante | La collaborazione non è una funzione automatica di ogni portafoglio |
| Condizione alternativa di recupero | Script path | Script usato e prova del relativo impegno | Il ramo usato viene rivelato; il backup deve conservarne i dati |
Il confronto suggerisce una domanda pratica: quale di queste situazioni il software sa eseguire realmente? Ricevere su un indirizzo compatibile, spendere attraverso un percorso ordinario e gestire un recupero complesso sono capacità diverse. La parola «supporto» deve essere accompagnata dalla funzione precisa che è stata verificata.
Perché il backup richiede più attenzione del nome del formato
Un sistema con condizioni articolate può dipendere da informazioni ulteriori rispetto a una singola chiave. Descrizioni del portafoglio, dati dei partecipanti e struttura delle condizioni possono essere necessari per ricostruire correttamente il percorso voluto. Non si può assumere che qualsiasi insieme di parole di recupero ricrei automaticamente ogni accordo di custodia.
La guida alla seed phrase e al recupero distingue il possesso di un backup dalla prova che esso sia utilizzabile. Per una struttura Taproot complessa, il test deve riguardare anche le condizioni alternative rilevanti e gli strumenti che saranno disponibili nel momento del bisogno.
Un’analisi della procedura può essere svolta prima di impiegare fondi significativi, in ambienti e con strumenti adatti alla verifica. Questo report non prescrive una configurazione universale né invita a sperimentare trasferimenti casuali. La scelta utile è rendere espliciti requisiti e dipendenze prima che un partecipante o un dispositivo diventi indisponibile.
Dove finiscono i benefici di privacy
Taproot non elimina la necessità di considerare riuso degli indirizzi, unione di input e informazioni comunicate a servizi esterni. Un portafoglio può rivelare relazioni tramite il proprio comportamento anche se le singole firme espongono meno dettagli. La privacy è una proprietà dell’operazione complessiva, non un marchio incorporato nell’indirizzo.
Il coin control mostra un esempio concreto: selezionare insieme output provenienti da contesti differenti può creare collegamenti osservabili. Taproot non annulla questa conseguenza. Allo stesso modo, chi conosce l’identità associata a una transazione può disporre di informazioni che non provengono direttamente dalla catena.
Non bisogna poi confondere un miglioramento della privacy con una garanzia contro future capacità crittanalitiche. Le firme Schnorr qui considerate continuano a basarsi sulla curva indicata dal BIP 340. Le discussioni sulle firme resistenti a computer quantistici sufficientemente potenti costituiscono un tema distinto, con proposte e requisiti propri.
Come confrontare costi senza scegliere un esempio favorevole
Per misurare una differenza di costo occorre mantenere comparabili numero di input e output, condizioni di autorizzazione e tasso di commissione. Una transazione ordinaria con un input non va confrontata con un recupero complesso a più input attribuendo tutta la differenza al formato.
È utile separare almeno due scenari: il percorso previsto nella maggioranza delle operazioni e il percorso di recupero. La frequenza attesa conta, ma non elimina la necessità di poter eseguire il secondo. Un’organizzazione della custodia che risparmia spazio nelle spese ordinarie può richiedere una gestione più accurata dei dati necessari per le eccezioni.
Se un software fornisce una stima, verificare quali ipotesi utilizzi e se includa il percorso che interessa. Il risultato dovrebbe essere riproducibile a parità di struttura. Da una singola cifra espressa in euro, senza descrizione della transazione e del mercato delle commissioni, non si ricava una misura generale dell’efficienza.
Conclusioni: valutare il percorso che si userà davvero
Il confronto documentale mostra un vantaggio preciso: Taproot permette di evitare la rivelazione di alcune condizioni inutilizzate e offre una struttura più flessibile per autorizzazioni cooperative e alternative. Il beneficio diventa concreto solo quando il software implementa il percorso necessario e il backup ne conserva le informazioni.
Per valutare una soluzione servono quindi tre verifiche: modalità ordinaria di spesa, procedura alternativa e dati indispensabili al recupero. Privacy e costo vanno misurati su questi casi, mantenendo visibili importi, collegamenti e dipendenze che il protocollo non nasconde. È una valutazione più utile di un generico giudizio su quanto un indirizzo sia «moderno».
