Taproot e la custodia programmabile: Miniscript, eredità, vault

Bitcoin ha un problema che quasi nessuno ama nominare ad alta voce: una fetta enorme delle monete non tornerà mai in circolazione. Le stime di Chainalysis collocano tra 2,3 e 3,7 milioni di BTC ormai irrecuperabili, chiavi finite in una discarica, seed dimenticati, proprietari scomparsi senza lasciare istruzioni (BitGo). Nel 2025 Fidelity Digital Assets ha misurato una cosa ancora più netta: la cosiddetta ancient supply, le monete ferme da oltre dieci anni, cresce più in fretta di quelle appena minate, oltre 566 BTC al giorno che invecchiano contro i circa 450 prodotti dai miner dopo l’halving del 2024. Con il prezzo di Bitcoin intorno ai 66.700 euro (CoinGecko), in un mercato che oscilla al ritmo di Tesoro e Fed, è un patrimonio che si scava la fossa da solo.

La stampa specializzata ha già dato un nome al fenomeno: una bomba a orologeria dell’eredità, e il 2026 potrebbe essere l’anno in cui inizia a esplodere (CryptoSlate). La risposta tecnica esiste, però non arriva da un nuovo token o da una Layer 2 alla moda. Arriva dalla metà meno raccontata di Taproot, l’aggiornamento entrato in vigore nel novembre 2021: lo script path. È qui che Bitcoin diventa, per la prima volta in modo pratico, programmabile nella custodia. Non nel senso degli smart contract di Ethereum, ma in un senso più sobrio e forse più utile per chi tiene i propri BTC: eredità a tempo, multisig che si semplifica da solo, recupero senza affidarsi a nessuno.

Questa è la storia dello script path: cosa consente oggi, quali strumenti lo usano davvero nel 2026 e dove sbatte contro un soffitto che solo i covenant, la prossima grande battaglia del protocollo, possono alzare.

Taproot ha due strade, e la più importante è la meno raccontata

Ogni output Taproot, quelli con indirizzo che inizia per bc1p, può essere speso in due modi diversi. Il primo è il key path: una singola firma Schnorr che, grazie a schemi come MuSig2, può nascondere dietro di sé molte chiavi. È il multisig invisibile, la parte di Taproot che ha preso quasi tutta l’attenzione perché fa risparmiare commissioni e migliora la privacy, e che l’edizione italiana di HOGE Wire ha già raccontato in dettaglio. Un pagamento firmato da un consiglio di amministrazione di cinque persone, se costruito bene, sulla catena appare identico a un versamento fatto da un singolo utente.

Il secondo modo è lo script path, ed è quello che qui ci interessa. Invece di una sola firma, si può ancorare all’output un intero albero di condizioni di spesa, e al momento di spendere se ne rivela una soltanto. È la strada che trasforma un wallet da semplice cassaforte con una chiave in un piccolo insieme di regole: questa chiave può spendere sempre, quest’altra solo dopo un anno di silenzio, questa terna richiede due firme su tre fino a una certa data e poi ne basta una. In altre parole, il key path stabilisce quanto elegante è la firma; lo script path stabilisce quali condizioni la firma deve soddisfare.

La distinzione conta perché la maggior parte della cronaca su Taproot ha riguardato l’uso involontario dello script path, cioè le iscrizioni di Ordinals e Runes che hanno riempito il blocco di dati. Ma la promessa originaria era un’altra: dare a chi custodisce Bitcoin la possibilità di scrivere le proprie regole di spesa in modo compatto, privato e verificabile. Nel 2026, con l’ondata di furti e la questione delle monete perse, quella promessa smette di essere teorica.

Lo script path in breve: Tapscript e MAST

Due specifiche fanno funzionare tutto questo. La prima è MAST, definita dalla BIP-341 (autori Pieter Wuille, Jonas Nick e Anthony Towns): al posto di un unico script monolitico, le condizioni di spesa vengono organizzate in un albero di Merkle. Quando si spende, si mostra soltanto la foglia usata più una breve prova crittografica (il control block), fatta dalla chiave interna e da un hash per ogni livello dell’albero. Un wallet può nascondere decine di percorsi diversi e rivelarne uno solo: le condizioni non usate non finiscono mai sulla catena, con un guadagno netto di privacy e di spazio.

La seconda è Tapscript, la BIP-342. Riscrive il linguaggio di scripting per le foglie Taproot: introduce OP_CHECKSIGADD per contare le firme Schnorr in un multisig, sostituisce le vecchie operazioni disattivate e, soprattutto, elimina due limiti storici che avevano ingessato lo Script di Bitcoin per anni, il tetto dei 10.000 byte per script e quello delle 201 operazioni non di push. Al loro posto arriva un modello a budget di operazioni di firma legato al peso del witness. È una differenza tecnica che sembra minore, e invece è proprio ciò che permette a script complessi, dai piani di successione fino ai verificatori usati dalle Layer 2, di esistere.

Messe insieme, MAST e Tapscript trasformano lo script path in un contenitore capace e riservato. Il problema, fino a poco tempo fa, era scrivere questi script a mano: un errore in una condizione può congelare i fondi per sempre. Serviva un linguaggio più sicuro. Quel linguaggio è Miniscript.

Miniscript: rendere leggibile lo Script di Bitcoin

Lo Script di Bitcoin è potente ma ostico: è uno stack di operazioni difficile da leggere, da comporre e da analizzare. Un errore non si vede a occhio, e non c’è un modo automatico per sapere quanto costerà spendere né quali percorsi restano aperti. Miniscript nasce nel 2019 per risolvere esattamente questo, opera di Pieter Wuille, Andrew Poelstra e Sanket Kanjalkar di Blockstream, presentata alla Stanford Blockchain Conference. L’idea: definire un sottoinsieme strutturato e analizzabile dello Script, con un linguaggio di policy leggibile che si compila prima in Miniscript e poi nello Script vero e proprio.

Il vantaggio pratico è enorme. Con Miniscript un wallet può calcolare in anticipo la dimensione e il costo di ogni percorso di spesa, enumerare tutte le condizioni, comporre policy diverse come mattoncini e firmare in modo generico senza sapere in anticipo quale ramo verrà usato. Wuille stesso, alla presentazione, notava che il compilatore trovava script leggermente migliori di quelli scritti a mano che Blockstream usava allora in Liquid. La specifica è oggi la BIP-379 (in stato Draft, tra i coautori figurano Antoine Poinsot e Ava Chow), descritta come un linguaggio per scrivere in modo strutturato un sottoinsieme dello Script, in modo da poterlo analizzare, comporre e firmare.

Il salto decisivo è arrivato con l’integrazione in Bitcoin Core. I descriptor Miniscript per gli script P2WSH sono stati aggiunti tra il 2022 e il 2023; poi, con Bitcoin Core 26.0 (dicembre 2023), Miniscript è entrato dentro le foglie Taproot attraverso i descriptor tr(), la funzione soprannominata MiniTapscript (Bitcoin Optech). Da quel momento la custodia programmabile smette di essere un esperimento e diventa qualcosa che un portafoglio può gestire in produzione.

I timelock: come si insegna al tempo a firmare

La custodia programmabile ha bisogno di un ingrediente in più: il tempo. Bitcoin lo fornisce con due tipi di timelock. Il primo è assoluto, l’operazione OP_CHECKLOCKTIMEVERIFY (CLTV, definita dalla BIP-65): un output diventa spendibile solo dopo una certa altezza di blocco o una certa data. Il secondo è relativo, OP_CHECKSEQUENCEVERIFY (CSV, BIP-112) unito al conteggio della BIP-68: qui l’orologio parte dal momento in cui la moneta è stata confermata e si azzera ogni volta che la si sposta.

Il timelock relativo è perfetto per costruire un piano di recupero, perché misura l’inattività. Ha però un tetto: circa 65.535 blocchi, all’incirca 455 giorni, poco più di quindici mesi. Oltre quella soglia bisogna concatenare più condizioni o usare timelock assoluti. Combinati con Miniscript, questi mattoncini permettono di scrivere policy in linguaggio quasi naturale: chiave A può spendere sempre, oppure la chiave B può spendere dopo sei mesi di silenzio. È esattamente il tipo di regola che serve per l’eredità.

L’eredità è un problema di ingegneria, non solo di avvocati

Il paradosso dell’autocustodia è semplice: togliendo l’intermediario, si toglie anche la persona a cui telefonare quando qualcosa va storto. Se il proprietario muore, o perde la memoria, o semplicemente smarrisce il seed, non c’è un ufficio reclami. Le chiavi esistono da qualche parte, ma chi le capiva è sparito, e il patrimonio diventa un monumento inaccessibile. È la definizione stessa della bomba a orologeria descritta nel 2026.

I numeri danno la misura del rischio, ed è utile vederli insieme.

Il punto non è che le monete si perdano per colpa di Bitcoin, ma che lo strumento per prevenirlo esiste da poco ed è ancora poco usato. Finché l’eredità resta un foglietto con dodici parole nascosto in un cassetto, il rischio è tutto umano. Con lo script path, invece, la logica della successione si può scrivere direttamente nell’UTXO.

Il wallet a decadimento: un piano di successione scritto nell’UTXO

Il caso d’uso più chiaro è un semplice script a due percorsi. Il primo percorso: la chiave del proprietario può spendere in qualsiasi momento, senza vincoli. Il secondo percorso: la chiave dell’erede può spendere soltanto dopo un timelock relativo, per esempio 26.280 blocchi, all’incirca sei mesi, calcolato dall’ultima conferma della moneta (Spark). Finché il proprietario è attivo e sposta i fondi anche solo occasionalmente, l’orologio si azzera e l’erede non può toccare nulla. Se il proprietario tace per sei mesi, il secondo percorso si apre da solo, senza bisogno di alcun custode.

La stessa logica si estende al multisig a decadimento (decaying multisig): si parte, poniamo, da una firma su tre, e dopo il timeout la soglia si abbassa, magari a una sola chiave superstite, in modo che la perdita di uno o due dispositivi non blocchi i fondi per sempre. È la traduzione tecnica di un principio noto agli avvocati: oltre a stabilire chi può spendere, ora si può stabilire quando ottiene l’accesso.

Il meccanismo non è gratuito. Ogni rinnovo dell’inattività, la transazione di refresh che riazzera l’orologio, è una transazione on-chain con le sue commissioni. Se ci si dimentica di rinnovare, l’erede ottiene l’accesso in anticipo. E l’erede, per spendere, non ha bisogno solo delle chiavi: gli serve anche il file descriptor, cioè la configurazione del wallet che descrive lo script. Senza quel file, le chiavi da sole non bastano. Sono attriti gestibili, ma reali, e ogni buon piano deve tenerne conto.

Gli strumenti del 2026: Liana, Nunchuk, Coldcard

La teoria è arrivata ai prodotti. Il riferimento più diretto è Liana, il wallet di Wizardsardine fondata da Antoine Poinsot (oggi in Chaincode Labs) e Kevin Loaec: combina un percorso di spesa primario con un percorso di recupero che si attiva dopo un periodo di inattività configurabile, e supporta il multisig a decadimento in cui servono meno chiavi col passare del tempo. La versione 5 ha aggiunto il supporto a Coldcard e una gestione sperimentale di Taproot. Alla presentazione del wallet, Poinsot ha riassunto il senso della cosa con parole che valgono anche oggi: il timelock aggiunge un’altra dimensione allo schema di successione, oltre a chi può spendere i fondi ora si può definire quando ne ottiene l’accesso, il tutto proteggendo dalla perdita senza degradare la sicurezza.

Nunchuk ha spinto sullo stesso terreno. Con Nunchuk 2.0 (novembre 2025) offre un’eredità on-chain autonoma per gli abbonati al piano soprannominato Honey Badger: alla scadenza del timelock, la chiave della piattaforma viene automaticamente rimossa dai requisiti di firma, e il beneficiario resta l’unico a poter muovere i fondi (Nunchuk). Coldcard, dal canto suo, è nel 2026 l’unico wallet hardware con supporto Tapscript completo (fino a otto foglie) e gestisce Miniscript sia in versione native SegWit sia in versione Taproot. Ecco un confronto sintetico.

Anche Bitcoin Core, Sparrow e Ledger (che gestisce Miniscript dal 2024) rientrano nel quadro. Il messaggio è chiaro: nel 2026 la custodia programmabile non è più un progetto da laboratorio, è una funzione che un utente attento può attivare oggi.

Quello che Miniscript non può fare: il soffitto

Qui arriva il limite, ed è importante capirlo per non vendere illusioni. Miniscript compone solo ciò che Bitcoin già conosce: firme, timelock e hashlock. Può imporre chi spende e quando, ma non ha alcun modo di imporre dove vanno le monete dopo la spesa. In altre parole, non esiste un vincolo sull’output successivo.

Questo esclude i vault reattivi, cioè le casseforti che reagiscono a un tentativo di furto. Uno script Miniscript non può obbligare un prelievo a passare da un indirizzo intermedio dove il proprietario abbia il tempo di annullarlo. Non può nemmeno garantire che le transazioni di refresh seguano uno schema preciso: senza un vincolo sull’output, lo Script non può imporre che i rinnovi rispettino un pattern specifico, il che limita l’automazione. Restano gli attriti già visti: l’onere del refresh, il rischio che l’erede acceda in anticipo se ci si dimentica, la necessità di conservare e trasmettere il descriptor. Sono limiti di progetto, non bug. Per superarli serve un tipo di primitiva che Bitcoin, per ora, non ha: i covenant.

I vault veri chiedono i covenant: OP_VAULT e la posta in gioco

Un covenant è una condizione che vincola non la spesa attuale, ma le transazioni future generate da quell’output. È esattamente il tassello mancante. La proposta pensata su misura per i vault è OP_VAULT, la BIP-345 di James O’Beirne (poi affiancato da Greg Sanders). Il suo scopo è migliorare la sicurezza dello stoccaggio introducendo un ritardo obbligatorio a ogni tentativo di prelievo: invece di poter inviare i fondi direttamente, il vault li obbliga a passare da un indirizzo intermedio (Bitcoin Magazine).

Il vantaggio è netto. Se un attaccante ruba una chiave e avvia un prelievo, il proprietario vede la transazione entrare nella fase di ritardo e ha una finestra per bloccarla, richiamando i fondi verso una custodia più fredda prima che il ladro possa completare l’operazione. È la protezione reattiva che nessuno script Miniscript può offrire. Il problema è che OP_VAULT non è attivo: appartiene alla famiglia dei covenant ancora in revisione e, per il passaggio finale di prelievo, si appoggia a una primitiva di impegno sul template come OP_CHECKTEMPLATEVERIFY. Senza quella, il vault reattivo resta sulla carta.

La corsa dei covenant nel 2026: CTV, OP_TEMPLATEHASH e il resto

Il dibattito sui covenant è la vera battaglia aperta del protocollo. La proposta storicamente più vicina all’attivazione è OP_CTV (OP_CHECKTEMPLATEVERIFY), la BIP-119 di Jeremy Rubin: impegna una transazione a rispettare un template predefinito, ed è considerata il covenant sicuro perché non ricorsivo. Nel 2026, però, il consenso non c’è: il segnale dei miner è rimasto molto sotto la soglia richiesta e non esiste un calendario di attivazione condiviso. Attivare un soft fork non è mai automatico, come ha ricordato di recente anche il confronto sul fix del bug timewarp con la BIP-54.

La novità del 2026 è un pacchetto pensato per essere Taproot-native fin dall’inizio. OP_TEMPLATEHASH, la BIP-446, è un opcode Tapscript che mette sullo stack un hash della transazione di spesa; i suoi autori, Greg Sanders (Blockstream Research), Antoine Poinsot (Wizardsardine) e Steven Roose (Blockstream), lo descrivono come un sostituto immediato di OP_CTV. La BIP-448, Transazioni ribindabili native di Taproot, lo raggruppa con due opcode esistenti ma non attivati, OP_INTERNALKEY e OP_CHECKSIGFROMSTACK, in un unico soft fork. Entrambe sono strettamente Taproot-native: usano gli hook di aggiornamento OP_SUCCESS e si impegnano sull’annex di Taproot. Il pacchetto è entrato in stato Draft con la pull request numero 1974, nel marzo 2026, ed è il primo pacchetto di covenant interamente Taproot-native a raggiungere lo standards track ufficiale.

La posta in gioco va oltre i vault. Questi opcode forniscono la primitiva necessaria a LN-Symmetry, che eliminerebbe le transazioni di penalità su Lightning, e competono direttamente con l’abbinamento OP_CTV più OP_CSFS (la BIP-348). C’è un dettaglio tecnico da segnalare: OP_TEMPLATEHASH non si impegna sugli scriptSig, quindi non può essere usato nelle costruzioni tipo BitVM dove invece CTV funzionerebbe. Sullo sfondo continua a girare anche OP_CAT (BIP-347), tornato d’attualità con la campagna dei Taproot Wizards. La tabella riassume il campo.

I covenant servirebbero anche alle Layer 2, dove il nodo resta sempre lo stesso, quanto ci si deve fidare di chi gestisce il ponte. Ma la comunità è cauta: la memoria del tentativo fallito di soft fork sui dati (la BIP-110) e il timore di cambiamenti irreversibili tengono alta la barra del consenso. Nel breve periodo, l’attivazione di un covenant resta improbabile; nel medio, l’arrivo di BIP-446 e BIP-448 sullo standards track tiene la porta aperta.

Custodia programmabile e custodia condivisa: dove si colloca

Vale la pena inquadrare lo script path nello spettro delle opzioni di custodia. A un estremo c’è la chiave singola: massimo controllo, massimo rischio di errore umano. All’altro estremo c’è il custode centralizzato: comodo, ma con rischio di controparte e perimetro regolamentare. In mezzo si è sempre collocato il multisig classico, che distribuisce la fiducia su più dispositivi.

La custodia programmabile aggiunge una terza dimensione a questo asse. Al chi (quante e quali chiavi) e al quanto ci si fida (custode o autocustodia) affianca il quando (i timelock) e, in prospettiva coi covenant, il dove (il vincolo sull’output). Ed è qui che le due metà di Taproot lavorano insieme: il key path con MuSig2 rende la firma aggregata invisibile e leggera, lo script path con Miniscript rende le condizioni ricche e private. Un wallet moderno di collaborative custody usa entrambe, un cofirmatario che interviene solo quando certe condizioni sono soddisfatte, senza mai apparire come tale sulla catena. Non è una scelta tra key path e script path: è la loro combinazione a definire lo stato dell’arte.

Italia: Consob, MiCA, fisco e il nodo della successione

Sul piano regolamentare, un punto va chiarito subito: MiCA, con Consob per la condotta di mercato e Banca d’Italia per i profili prudenziali e le stablecoin, disciplina i prestatori di servizi (i CASP) e gli emittenti, non il protocollo Bitcoin né le regole di consenso. Un soft fork come Taproot, o una futura attivazione di un covenant, non è qualcosa che un’autorità approva o blocca. La sezione MiCAR di Consob riguarda chi offre servizi al pubblico, non chi scrive uno script per custodire i propri fondi.

Ne discende una conseguenza pratica: la custodia programmabile è, per definizione, autocustodia, e quindi resta fuori dal perimetro degli intermediari, quello per cui serve una licenza CASP secondo MiCA in Italia. Nessun operatore autorizzato entra in gioco quando si costruisce un wallet a decadimento con Liana o Coldcard.

Sul fisco, la regola chiave è che spostare le proprie monete tra indirizzi che si controllano non è un realizzo e non genera plusvalenza: migrare da un vecchio indirizzo a un output Taproot con Miniscript è un’operazione fiscalmente neutra. L’imposta sostitutiva sulle plusvalenze, salita al 33% dal 1 gennaio 2026 dopo che una prima ipotesi al 42% era stata ridimensionata (CoinDesk), scatta quando si vende o si converte, non quando si cambia schema di custodia. Chi tiene le chiavi in autocustodia deve comunque monitorare i saldi, l’obbligo un tempo assolto col quadro RW e oggi confluito nel quadro T della dichiarazione.

Resta il nodo più delicato, la successione. In Italia le cripto in un’eredità rientrano nell’imposta di successione, ma il diritto non riconosce né richiede uno schema tecnico particolare: per l’ordinamento contano le chiavi e la loro trasmissione, non il fatto che esista un timelock. È esattamente il divario tra il codice e la legge. Uno script di eredità ben scritto risolve il problema tecnico (l’erede otterrà l’accesso), ma il coordinamento con notaio, testamento e adempimenti fiscali resta un lavoro umano, e va fatto a monte.

Cosa aspettarsi

Il 2026 lascia Taproot in una posizione curiosa. La metà rumorosa, le iscrizioni, ha riempito i titoli e i blocchi. La metà silenziosa, lo script path, ha finalmente iniziato a fare il lavoro per cui era stata pensata: eredità a tempo, multisig a decadimento, recupero non custodiale, tutto disponibile oggi senza attendere alcun soft fork. Con Miniscript in Bitcoin Core e strumenti maturi come Liana, Nunchuk e Coldcard, la custodia programmabile è passata dalla teoria alla pratica.

Il soffitto resta quello dei covenant. Senza un vincolo sull’output non ci sono vault reattivi né automazione completa dei rinnovi, e l’attivazione di OP_CTV, OP_VAULT o del nuovo pacchetto OP_TEMPLATEHASH e BIP-448 dipende da un consenso che nel 2026 non si è ancora formato. Ma la direzione è tracciata: il primo pacchetto di covenant interamente Taproot-native è ormai sullo standards track, e il problema che dovrebbe risolvere, mettere al sicuro un patrimonio che altrimenti rischia di perdersi, è tra i più concreti che Bitcoin abbia di fronte. La domanda per i prossimi anni non è più se la custodia di Bitcoin possa diventare programmabile, ma quanto in profondità il protocollo lascerà che lo diventi.

Domande frequenti

Che cos’è lo script path di Taproot?

Taproot offre due modi di spendere un output: il key path, una singola firma Schnorr che aggrega più chiavi (il multisig invisibile), e lo script path, in cui si rivela solo la condizione di spesa usata, nascosta in un albero MAST. Lo script path è la parte che rende programmabile la custodia: timelock, multisig e percorsi di recupero scritti direttamente nello script.

Posso lasciare i miei Bitcoin in eredità senza un intermediario?

Sì. Con Miniscript e i timelock si può costruire un percorso di spesa che si attiva solo dopo un periodo di inattività, così l’erede accede ai fondi senza custodi. Strumenti come Liana e Nunchuk lo rendono usabile, ma l’erede deve comunque disporre delle chiavi e del file descriptor del wallet.

Che differenza c’è tra Miniscript e i covenant?

Miniscript compone condizioni che Bitcoin già conosce: firme, timelock e hashlock. Può imporre chi spende e quando, ma non dove finiscono le monete dopo. I covenant, come OP_CTV o il più recente OP_TEMPLATEHASH, aggiungono proprio quel vincolo e sono ciò che manca per costruire vault reattivi; nel 2026 restano proposte non attivate.

Spostare i Bitcoin in un wallet Taproot con timelock fa scattare le tasse in Italia?

Trasferire le proprie monete tra indirizzi che si controllano non è un realizzo e non genera plusvalenza. L’imposta sostitutiva, salita al 33% dal 2026, scatta quando si vende o si converte, non quando si migra la custodia; resta l’obbligo di monitoraggio in dichiarazione per l’autocustodia.

Quali wallet supportano la custodia programmabile nel 2026?

Nel 2026 i riferimenti sono Liana di Wizardsardine (percorsi di recupero e multisig a decadimento), Nunchuk 2.0 con l’eredità on-chain autonoma e Coldcard, l’unico wallet hardware con supporto Tapscript completo. Anche Bitcoin Core gestisce Miniscript dentro le foglie Taproot dai descriptor tr().

Di Marcus Okafor, redazione HOGE Wire.