{"id":562,"date":"2026-09-12T16:37:59","date_gmt":"2026-09-12T16:37:59","guid":{"rendered":"https:\/\/hoge.gg\/it\/taproot-miniscript-custodia-programmabile-bitcoin-2026\/"},"modified":"2026-09-12T16:37:59","modified_gmt":"2026-09-12T16:37:59","slug":"taproot-miniscript-custodia-programmabile-bitcoin-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/it\/taproot-miniscript-custodia-programmabile-bitcoin-2026\/","title":{"rendered":"Taproot e la custodia programmabile: Miniscript, eredit\u00e0, vault"},"content":{"rendered":"

Bitcoin ha un problema che quasi nessuno ama nominare ad alta voce: una fetta enorme delle monete non torner\u00e0 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<\/a>). Nel 2025 Fidelity Digital Assets ha misurato una cosa ancora pi\u00f9 netta: la cosiddetta ancient supply, le monete ferme da oltre dieci anni, cresce pi\u00f9 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<\/a>), in un mercato che oscilla al ritmo di Tesoro e Fed<\/a>, \u00e8 un patrimonio che si scava la fossa da solo.<\/p>

La stampa specializzata ha gi\u00e0 dato un nome al fenomeno: una bomba a orologeria dell’eredit\u00e0, e il 2026 potrebbe essere l’anno in cui inizia a esplodere (CryptoSlate<\/a>). La risposta tecnica esiste, per\u00f2 non arriva da un nuovo token o da una Layer 2 alla moda. Arriva dalla met\u00e0 meno raccontata di Taproot, l’aggiornamento entrato in vigore nel novembre 2021: lo script path. \u00c8 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\u00f9 sobrio e forse pi\u00f9 utile per chi tiene i propri BTC: eredit\u00e0 a tempo, multisig che si semplifica da solo, recupero senza affidarsi a nessuno.<\/p>

Questa \u00e8 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.<\/p>

Taproot ha due strade, e la pi\u00f9 importante \u00e8 la meno raccontata<\/h2>

Ogni output Taproot, quelli con indirizzo che inizia per bc1p, pu\u00f2 essere speso in due modi diversi. Il primo \u00e8 il key path: una singola firma Schnorr che, grazie a schemi come MuSig2, pu\u00f2 nascondere dietro di s\u00e9 molte chiavi. \u00c8 il multisig invisibile, la parte di Taproot che ha preso quasi tutta l’attenzione perch\u00e9 fa risparmiare commissioni e migliora la privacy, e che l’edizione italiana di HOGE Wire ha gi\u00e0 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.<\/p>

Il secondo modo \u00e8 lo script path, ed \u00e8 quello che qui ci interessa. Invece di una sola firma, si pu\u00f2 ancorare all’output un intero albero di condizioni di spesa, e al momento di spendere se ne rivela una soltanto. \u00c8 la strada che trasforma un wallet da semplice cassaforte con una chiave in un piccolo insieme di regole: questa chiave pu\u00f2 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 \u00e8 la firma; lo script path stabilisce quali condizioni la firma deve soddisfare.<\/p>

La distinzione conta perch\u00e9 la maggior parte della cronaca su Taproot ha riguardato l’uso involontario dello script path, cio\u00e8 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\u00e0 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.<\/p>

Lo script path in breve: Tapscript e MAST<\/h2>

Due specifiche fanno funzionare tutto questo. La prima \u00e8 MAST, definita dalla BIP-341<\/a> (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\u00f9 una breve prova crittografica (il control block), fatta dalla chiave interna e da un hash per ogni livello dell’albero. Un wallet pu\u00f2 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.<\/p>

La seconda \u00e8 Tapscript, la BIP-342<\/a>. 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. \u00c8 una differenza tecnica che sembra minore, e invece \u00e8 proprio ci\u00f2 che permette a script complessi, dai piani di successione fino ai verificatori usati dalle Layer 2, di esistere.<\/p>

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\u00f2 congelare i fondi per sempre. Serviva un linguaggio pi\u00f9 sicuro. Quel linguaggio \u00e8 Miniscript.<\/p>

Miniscript: rendere leggibile lo Script di Bitcoin<\/h2>

Lo Script di Bitcoin \u00e8 potente ma ostico: \u00e8 uno stack di operazioni difficile da leggere, da comporre e da analizzare. Un errore non si vede a occhio, e non c’\u00e8 un modo automatico per sapere quanto coster\u00e0 spendere n\u00e9 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.<\/p>

Il vantaggio pratico \u00e8 enorme. Con Miniscript un wallet pu\u00f2 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\u00e0 usato. Wuille stesso, alla presentazione, notava che il compilatore trovava script leggermente migliori di quelli scritti a mano<\/a> che Blockstream usava allora in Liquid. La specifica \u00e8 oggi la BIP-379<\/a> (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.<\/p>

Il salto decisivo \u00e8 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 \u00e8 entrato dentro le foglie Taproot attraverso i descriptor tr(), la funzione soprannominata MiniTapscript (Bitcoin Optech<\/a>). Da quel momento la custodia programmabile smette di essere un esperimento e diventa qualcosa che un portafoglio pu\u00f2 gestire in produzione.<\/p>

I timelock: come si insegna al tempo a firmare<\/h2>

La custodia programmabile ha bisogno di un ingrediente in pi\u00f9: il tempo. Bitcoin lo fornisce con due tipi di timelock. Il primo \u00e8 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 \u00e8 relativo, OP_CHECKSEQUENCEVERIFY (CSV, BIP-112) unito al conteggio della BIP-68: qui l’orologio parte dal momento in cui la moneta \u00e8 stata confermata e si azzera ogni volta che la si sposta.<\/p>

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

L’eredit\u00e0 \u00e8 un problema di ingegneria, non solo di avvocati<\/h2>

Il paradosso dell’autocustodia \u00e8 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’\u00e8 un ufficio reclami. Le chiavi esistono da qualche parte, ma chi le capiva \u00e8 sparito, e il patrimonio diventa un monumento inaccessibile. \u00c8 la definizione stessa della bomba a orologeria descritta nel 2026.<\/p>

I numeri danno la misura del rischio, ed \u00e8 utile vederli insieme.<\/p>

Dato<\/th>Valore<\/th>Fonte<\/th><\/tr><\/thead>
BTC ritenuti persi<\/td>tra 2,3 e 3,7 milioni<\/td>Chainalysis (via BitGo)<\/td><\/tr>
Ancient supply che invecchia (ferma da oltre 10 anni)<\/td>oltre 566 BTC al giorno<\/td>Fidelity (via BitGo)<\/td><\/tr>
Nuovi BTC minati al giorno (dopo l’halving 2024)<\/td>circa 450 BTC<\/td>BitGo<\/td><\/tr>
Prezzo di Bitcoin<\/td>circa 66.700 EUR<\/td>CoinGecko<\/td><\/tr><\/tbody><\/table>
Fonti: BitGo<\/a>, CoinGecko<\/a> (12 settembre 2026).<\/figcaption><\/figure>

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

Il wallet a decadimento: un piano di successione scritto nell’UTXO<\/h2>

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

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. \u00c8 la traduzione tecnica di un principio noto agli avvocati: oltre a stabilire chi pu\u00f2 spendere, ora si pu\u00f2 stabilire quando ottiene l’accesso.<\/p>

Il meccanismo non \u00e8 gratuito. Ogni rinnovo dell’inattivit\u00e0, la transazione di refresh che riazzera l’orologio, \u00e8 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\u00e8 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.<\/p>

Gli strumenti del 2026: Liana, Nunchuk, Coldcard<\/h2>

La teoria \u00e8 arrivata ai prodotti. Il riferimento pi\u00f9 diretto \u00e8 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\u00e0 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\u00f2 spendere i fondi ora si pu\u00f2 definire quando ne ottiene l’accesso<\/a>, il tutto proteggendo dalla perdita senza degradare la sicurezza.<\/p>

Nunchuk ha spinto sullo stesso terreno. Con Nunchuk 2.0 (novembre 2025) offre un’eredit\u00e0 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<\/a>). Coldcard, dal canto suo, \u00e8 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.<\/p>

Strumento<\/th>Modello di successione<\/th>Timelock<\/th>Supporto<\/th>Custodia<\/th><\/tr><\/thead>
Liana (Wizardsardine)<\/td>percorso primario pi\u00f9 recupero a inattivit\u00e0, multisig a decadimento<\/td>relativo (CSV)<\/td>Miniscript, Taproot sperimentale (v5)<\/td>non custodiale<\/td><\/tr>
Nunchuk 2.0<\/td>eredit\u00e0 on-chain autonoma (Honey Badger), chiave della piattaforma rimossa alla scadenza<\/td>assoluto e relativo<\/td>Miniscript \/ MiniTapscript<\/td>non custodiale assistito<\/td><\/tr>
Coldcard<\/td>firma hardware con Tapscript completo (fino a 8 foglie)<\/td>CLTV \/ CSV via descriptor<\/td>Miniscript nativo pi\u00f9 Taproot<\/td>non custodiale (hardware)<\/td><\/tr><\/tbody><\/table>
Fonti: Spark<\/a>, Wizardsardine<\/a>, Nunchuk<\/a>.<\/figcaption><\/figure>

Anche Bitcoin Core, Sparrow e Ledger (che gestisce Miniscript dal 2024) rientrano nel quadro. Il messaggio \u00e8 chiaro: nel 2026 la custodia programmabile non \u00e8 pi\u00f9 un progetto da laboratorio, \u00e8 una funzione che un utente attento pu\u00f2 attivare oggi.<\/p>

Quello che Miniscript non pu\u00f2 fare: il soffitto<\/h2>

Qui arriva il limite, ed \u00e8 importante capirlo per non vendere illusioni. Miniscript compone solo ci\u00f2 che Bitcoin gi\u00e0 conosce: firme, timelock e hashlock. Pu\u00f2 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.<\/p>

Questo esclude i vault reattivi, cio\u00e8 le casseforti che reagiscono a un tentativo di furto. Uno script Miniscript non pu\u00f2 obbligare un prelievo a passare da un indirizzo intermedio dove il proprietario abbia il tempo di annullarlo. Non pu\u00f2 nemmeno garantire che le transazioni di refresh seguano uno schema preciso: senza un vincolo sull’output, lo Script non pu\u00f2 imporre che i rinnovi rispettino un pattern specifico<\/a>, il che limita l’automazione. Restano gli attriti gi\u00e0 visti: l’onere del refresh, il rischio che l’erede acceda in anticipo se ci si dimentica, la necessit\u00e0 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.<\/p>

I vault veri chiedono i covenant: OP_VAULT e la posta in gioco<\/h2>

Un covenant \u00e8 una condizione che vincola non la spesa attuale, ma le transazioni future generate da quell’output. \u00c8 esattamente il tassello mancante. La proposta pensata su misura per i vault \u00e8 OP_VAULT, la BIP-345<\/a> di James O’Beirne (poi affiancato da Greg Sanders). Il suo scopo \u00e8 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<\/a>).<\/p>

Il vantaggio \u00e8 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\u00f9 fredda prima che il ladro possa completare l’operazione. \u00c8 la protezione reattiva che nessuno script Miniscript pu\u00f2 offrire. Il problema \u00e8 che OP_VAULT non \u00e8 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.<\/p>

La corsa dei covenant nel 2026: CTV, OP_TEMPLATEHASH e il resto<\/h2>

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

La novit\u00e0 del 2026 \u00e8 un pacchetto pensato per essere Taproot-native fin dall’inizio. OP_TEMPLATEHASH, la BIP-446, \u00e8 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<\/a>. 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 \u00e8 entrato in stato Draft con la pull request numero 1974, nel marzo 2026, ed \u00e8 il primo pacchetto di covenant interamente Taproot-native a raggiungere lo standards track ufficiale.<\/p>

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

Proposta<\/th>Cosa fa<\/th>Stato (2026)<\/th><\/tr><\/thead>
OP_CTV (BIP-119)<\/td>impegna la transazione a un template predefinito<\/td>proposta, nessun consenso di attivazione<\/td><\/tr>
OP_VAULT (BIP-345)<\/td>vault con ritardo e indirizzo intermedio, dipende da CTV<\/td>proposta, in revisione<\/td><\/tr>
OP_TEMPLATEHASH (BIP-446)<\/td>opcode Tapscript, sostituto di CTV<\/td>Draft (marzo 2026)<\/td><\/tr>
Transazioni ribindabili (BIP-448)<\/td>pacchetto Taproot-native, primitiva per LN-Symmetry<\/td>Draft (marzo 2026)<\/td><\/tr>
OP_CHECKSIGFROMSTACK (BIP-348)<\/td>verifica firme su messaggi arbitrari<\/td>proposta<\/td><\/tr><\/tbody><\/table>
Fonti: bips.dev<\/a>, bips.dev<\/a>, HyperSinc<\/a>.<\/figcaption><\/figure>

I covenant servirebbero anche alle Layer 2, dove il nodo resta sempre lo stesso, quanto ci si deve fidare di chi gestisce il ponte<\/a>. Ma la comunit\u00e0 \u00e8 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.<\/p>

Custodia programmabile e custodia condivisa: dove si colloca<\/h2>

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

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 \u00e8 qui che le due met\u00e0 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 \u00e8 una scelta tra key path e script path: \u00e8 la loro combinazione a definire lo stato dell’arte.<\/p>

Italia: Consob, MiCA, fisco e il nodo della successione<\/h2>

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\u00e9 le regole di consenso. Un soft fork come Taproot, o una futura attivazione di un covenant, non \u00e8 qualcosa che un’autorit\u00e0 approva o blocca. La sezione MiCAR di Consob<\/a> riguarda chi offre servizi al pubblico, non chi scrive uno script per custodire i propri fondi.<\/p>

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

Sul fisco, la regola chiave \u00e8 che spostare le proprie monete tra indirizzi che si controllano non \u00e8 un realizzo e non genera plusvalenza: migrare da un vecchio indirizzo a un output Taproot con Miniscript \u00e8 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<\/a>), 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<\/a>.<\/p>

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

Cosa aspettarsi<\/h2>

Il 2026 lascia Taproot in una posizione curiosa. La met\u00e0 rumorosa, le iscrizioni, ha riempito i titoli e i blocchi. La met\u00e0 silenziosa, lo script path, ha finalmente iniziato a fare il lavoro per cui era stata pensata: eredit\u00e0 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 \u00e8 passata dalla teoria alla pratica.<\/p>

Il soffitto resta quello dei covenant. Senza un vincolo sull’output non ci sono vault reattivi n\u00e9 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 \u00e8 ancora formato. Ma la direzione \u00e8 tracciata: il primo pacchetto di covenant interamente Taproot-native \u00e8 ormai sullo standards track, e il problema che dovrebbe risolvere, mettere al sicuro un patrimonio che altrimenti rischia di perdersi, \u00e8 tra i pi\u00f9 concreti che Bitcoin abbia di fronte. La domanda per i prossimi anni non \u00e8 pi\u00f9 se la custodia di Bitcoin possa diventare programmabile, ma quanto in profondit\u00e0 il protocollo lascer\u00e0 che lo diventi.<\/p>

Domande frequenti<\/h2>

Che cos’\u00e8 lo script path di Taproot?<\/h3>

Taproot offre due modi di spendere un output: il key path, una singola firma Schnorr che aggrega pi\u00f9 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 \u00e8 la parte che rende programmabile la custodia: timelock, multisig e percorsi di recupero scritti direttamente nello script.<\/p>

Posso lasciare i miei Bitcoin in eredit\u00e0 senza un intermediario?<\/h3>

S\u00ec. Con Miniscript e i timelock si pu\u00f2 costruire un percorso di spesa che si attiva solo dopo un periodo di inattivit\u00e0, cos\u00ec 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.<\/p>

Che differenza c’\u00e8 tra Miniscript e i covenant?<\/h3>

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

Spostare i Bitcoin in un wallet Taproot con timelock fa scattare le tasse in Italia?<\/h3>

Trasferire le proprie monete tra indirizzi che si controllano non \u00e8 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.<\/p>

Quali wallet supportano la custodia programmabile nel 2026?<\/h3>

Nel 2026 i riferimenti sono Liana di Wizardsardine (percorsi di recupero e multisig a decadimento), Nunchuk 2.0 con l’eredit\u00e0 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().<\/p>