Che cos’è il linguaggio di script di Bitcoin?

Bitcoin Script è il linguaggio di programmazione che controlla ogni transazione sulla rete Bitcoin. Si tratta di un linguaggio semplice, basato su stack, che definisce le condizioni esatte alle quali è possibile spendere i bitcoin, e ogni nodo completo della rete lo esegue ogni volta che viene convalidata una transazione. Senza di esso, Bitcoin sarebbe un semplice registro di numeri privo di qualsiasi meccanismo in grado di stabilire chi possiede cosa.

La maggior parte degli utenti non vede mai direttamente il linguaggio di scripting di Bitcoin. Sono i loro portafogli a gestirlo in modo invisibile. Ma ogni volta che si inviano o si ricevono BTC, due piccoli programmi vengono eseguiti simultaneamente su migliaia di computer, verificando se le condizioni di spesa sono state soddisfatte. Comprendere come funziona questo meccanismo spiega in gran parte perché Bitcoin sia strutturato in questo modo e cosa possa o non possa fare rispetto a piattaforme come Ethereum.

Questo articolo illustra il funzionamento di Bitcoin Script, descrive i principali tipi di transazione che esso consente, spiega l'aggiornamento Taproot che nel 2021 ha modernizzato il livello di scripting e fa il punto sulla situazione del dibattito relativo all'opcode "covenant" a giugno 2026.

Gestisci i tuoi Bitcoin in tutta sicurezza con l'autocustodia App Bitcoin.com Wallet.

Punti chiave

• Bitcoin Script è un linguaggio di programmazione basato su stack integrato nel protocollo Bitcoin che definisce le condizioni alle quali è possibile spendere qualsiasi output di bitcoin.
• Ogni transazione Bitcoin include due script: uno di blocco (ScriptPubKey), impostato dal destinatario, e uno di sblocco (ScriptSig), fornito da chi effettua la transazione. Affinché una transazione sia valida, entrambi devono essere eseguiti correttamente.
• Bitcoin Script non è intenzionalmente Turing-completo. Non prevede cicli, né uno stato persistente tra un'esecuzione e l'altra, e impone limiti rigidi alle dimensioni dello script. Ciò garantisce che ogni script giunga a termine, il che costituisce una caratteristica di sicurezza, non una limitazione.
• Il linguaggio di scripting si è evoluto attraverso cinque formati principali: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) e Taproot (P2TR), ciascuno dei quali ha ampliato le possibilità offerte pur rimanendo retrocompatibile.
• Taproot (novembre 2021) ha introdotto le firme Schnorr, i percorsi di spesa basati su MAST a tutela della privacy e Tapscript, un linguaggio di scripting aggiornato dotato di un meccanismo integrato che consentirà aggiornamenti futuri più semplici.
• Tra i casi d'uso reali basati su Bitcoin Script figurano i portafogli con firma multipla, le transazioni con blocco temporale, i contratti con blocco temporale basato su hash (alla base di Lightning), i servizi di deposito a garanzia e i contratti con registro discreto.
• A differenza degli smart contract di Ethereum, Bitcoin Script è stateless: ogni script viene eseguito in modo completamente isolato, senza alcuna conoscenza delle altre transazioni. Si tratta di una scelta architettonica deliberata.
• L'area più attiva dello sviluppo di Bitcoin Script nel 2026 è quella degli opcode relativi ai covenant, in particolare OP_CTV (BIP-119) e OP_CAT (BIP-347), che consentirebbero agli script di definire i requisiti che una transazione di spesa deve soddisfare. Nessuno dei due è stato ancora attivato sulla mainnet.

Che cos’è Bitcoin Script?

Bitcoin Script è un linguaggio di scripting basato su stack e senza stato, integrato nel protocollo Bitcoin. Ogni output di transazione sulla rete Bitcoin contiene uno script di blocco (chiamato ScriptPubKey) che specifica le condizioni per spendere i fondi. Chiunque voglia spendere tali fondi deve fornire uno script di sblocco (chiamato ScriptSig, o, nelle transazioni SegWit e Taproot, i dati witness) che soddisfi tali condizioni.

Il linguaggio prende la sua struttura da Forth, un linguaggio di programmazione minimalista basato su stack sviluppato negli anni ’60. Come il Forth, Bitcoin Script viene letto da sinistra a destra, opera su una struttura dati denominata stack e utilizza la notazione polacca inversa (RPN), in cui gli operatori seguono gli operandi anziché precederli. Esegue un’istruzione alla volta, non prevede cicli e non conserva alcuna memoria persistente tra un’esecuzione e l’altra.

Quest'ultimo punto è quello con cui la maggior parte delle persone si imbatte per prima quando approfondisce la conoscenza di Bitcoin Script a livello di protocollo: il linguaggio è volutamente non Turing-completo. Un linguaggio Turing-completo è in grado di eseguire qualsiasi calcolo, purché si disponga di tempo e risorse sufficienti. Bitcoin Script, per sua natura, non può farlo, e le ragioni di questa scelta sono di fondamentale importanza per il funzionamento della rete.

Come funziona lo script di Bitcoin: il modello a stack

Per capire come funziona Bitcoin Script, è necessario comprendere il concetto di stack. Uno stack è una struttura dati che opera secondo il principio “Last-In, First-Out” (LIFO). Immaginate una pila di piatti: è possibile aggiungere o rimuovere elementi solo dalla cima. In Bitcoin Script, i dati vengono inseriti nello stack e gli opcode (codici operativi) manipolano ciò che si trova in cima.

Quando un nodo Bitcoin convalida una transazione, esegue due script in sequenza:

1. Lo script di sblocco (ScriptSig o witness) forniti dalla persona che spende le monete. Questo inserisce i dati nello stack, in genere una firma digitale e una chiave pubblica.
2. Lo script di blocco (ScriptPubKey) associato all'uscita che viene spesa. Questo contiene codici operativi che agiscono sui dati dello stack e verificano se le condizioni di spesa sono soddisfatte.

Se lo script viene eseguito senza errori e alla fine lascia nello stack un valore diverso da zero (TRUE), la transazione è valida. Se invece fallisce o lascia FALSE, la transazione viene rifiutata dal nodo e non viene mai inserita in un blocco.

Questa esecuzione è completamente senza stato. Lo script non ha alcuna conoscenza delle transazioni precedenti, non è a conoscenza dei saldi attuali e non conserva alcuna memoria che permanga al termine della sua esecuzione. Ogni script viene eseguito da zero, in modo isolato, ogni volta.

Passo dopo passo: una transazione P2PKH standard

Il Pay-to-Public-Key-Hash (P2PKH) è il tipo di transazione Bitcoin originale, in uso dal 2009. Gli indirizzi P2PKH iniziano con "1". Ecco come si presentano, nella pratica, ScriptPubKey e ScriptSig:

Script di sblocco (ScriptSig):

<firma> <chiave pubblica>

Script di blocco (ScriptPubKey):

OP_DUP OP_HASH160 <hash della chiave pubblica> OP_EQUALVERIFY OP_CHECKSIG

Quando il nodo concatena ed esegue entrambe le operazioni contemporaneamente, le operazioni dello stack procedono passo dopo passo:

• La firma e la chiave pubblica provenienti da ScriptSig vengono inserite nello stack
• OP_DUP duplica la chiave pubblica in cima allo stack
• OP_HASH160 calcola l'hash del duplicato (SHA-256 seguito da RIPEMD-160), generando un hash di 20 byte
• L'hash della chiave pubblica proveniente dallo script di blocco viene inserito nello stack
• OP_EQUALVERIFY verifica che i due hash corrispondano. Se non corrispondono, l'esecuzione si interrompe e la transazione fallisce.
• OP_CHECKSIG verifica che la firma sia valida per la chiave pubblica

Se tutte le fasi vengono superate, lo stack termina con TRUE e i fondi vengono sbloccati. L'intero processo richiede pochi millisecondi e si svolge in modo identico su ogni nodo della rete.

Spiegazione degli opcode di Bitcoin

Gli opcode di Bitcoin sono i singoli comandi che compongono uno script. Ciascuno è costituito da un singolo byte, per un totale di 256 slot di opcode possibili. Di questi, circa 80 sono attualmente attivi sulla mainnet. I restanti sono riservati, disabilitati o assegnati al meccanismo di compatibilità con le versioni future OP_SUCCESS, introdotto con Tapscript.

I codici operativi si suddividono in diverse categorie:

• Codici operativi di invio dati inserire valori quali chiavi pubbliche, firme e hash nello stack
• Codici operativi aritmetici eseguire operazioni di addizione, sottrazione e confronto. Da notare che la moltiplicazione e la divisione sono disabilitate.
• Codici operativi crittografici tra cui OP_SHA256, OP_HASH160 e OP_SHA1 per l'hash, e OP_CHECKSIG per la verifica della firma
• Codici operativi di controllo del flusso abilita la logica condizionale: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Codici operativi per la manipolazione degli stack tra cui OP_DUP (duplica l'elemento in cima), OP_DROP (rimuove l'elemento in cima) e OP_SWAP (scambia i primi due elementi)

Nel 2010 Satoshi Nakamoto ha disabilitato diversi codici operativi (opcode) in seguito alla scoperta di vulnerabilità nelle loro implementazioni originali. Tra questi figurano OP_CAT (concatenazione di due elementi dello stack), OP_MUL (moltiplicazione) e OP_DIV (divisione). La loro assenza ha avuto conseguenze durature sulle possibilità espressive di Bitcoin Script, e molte delle proposte di aggiornamento di Bitcoin più dibattute nel 2026 riguardano proprio la possibilità di riattivarne alcune.

Per il riferimento completo agli opcode, compresi i valori esadecimali e le descrizioni, consultare il Pagina dello script di Bitcoin Wiki è la fonte autorevole.

Perché la non completezza di Turing è un vantaggio

La spiegazione più comune è che Bitcoin Script non preveda cicli, quindi è garantito che gli script terminino, proteggendo così la rete da un'esecuzione infinita. Ciò è vero, ma non rende appieno l'idea.

La questione più profonda riguarda la superficie di attacco. Un linguaggio Turing-completo è in grado di esprimere qualsiasi calcolo. Tale espressività è anche lo spazio in cui si annidano i bug. Solidity di Ethereum ha generato alcune delle vulnerabilità software più costose della storia. L’attacco hacker al DAO del 2016 ha sfruttato una falla di rientranza in uno smart contract, causando perdite pari a circa 60 milioni di dollari ai prezzi dell’epoca e portando infine a un controverso hard fork della rete Ethereum. L’ecosistema DeFi nel suo complesso ha visto centinaia di milioni di dollari sottratti attraverso exploit degli smart contract nel corso di diversi anni.

Bitcoin Script rende strutturalmente impossibile quella categoria di attacchi. Non è possibile scrivere uno script Bitcoin che chiami altri script, esegua un ciclo fino al cambiamento di una condizione o memorizzi lo stato tra una transazione e l’altra. Ogni script è un programma circoscritto, terminante e verificabile. La dimensione massima dello script è di 10.000 byte. Il numero massimo di opcode non di tipo "push" per script è 201. Un validatore può sempre calcolare il costo di esecuzione nel caso peggiore prima di eseguire lo script.

Per una rete che gestisce centinaia di miliardi di dollari, tale prevedibilità vale più della flessibilità a cui si rinuncia. Ethereum risolve il problema del calcolo illimitato con i limiti di gas, addebitando agli utenti ogni opcode eseguito e interrompendo gli script che esauriscono il budget. Questo sistema funziona, ma introduce una propria complessità e modalità di errore. Bitcoin aggira completamente il problema grazie alla sua stessa progettazione.

Detto questo, "non Turing-completo" non significa "non in grado di gestire una logica complessa". Bitcoin Script supporta requisiti di spesa multiparte, condizioni basate sul tempo, rivelazione delle preimmagini degli hash e combinazioni di tutti questi elementi. Il Lightning Network, che gestisce milioni di pagamenti al giorno, è interamente basato sulle primitive di Bitcoin Script.

Tipi di script: l'evoluzione da P2PKH a Taproot

Il livello di scripting di Bitcoin si è evoluto in modo significativo dal 2009; ogni aggiornamento ha introdotto un nuovo formato di transazione, pur rimanendo retrocompatibile con tutto ciò che era stato sviluppato in precedenza.

P2PK (Pay-to-Public-Key, 2009)

Il formato originale, utilizzato nelle prime transazioni in Bitcoin, compreso il pagamento effettuato da Satoshi a Hal Finney nel blocco 170. I fondi venivano associati direttamente a una chiave pubblica completa anziché al suo hash. Oggi viene usato raramente nelle nuove transazioni perché espone la chiave pubblica sulla blockchain prima della spesa, il che è considerato un approccio di sicurezza più debole rispetto all’hash della chiave effettuato in precedenza.

P2PKH (Pay-to-Public-Key-Hash, 2009)

Il formato standard da oltre un decennio. Il P2PKH associa i fondi a un hash della chiave pubblica anziché alla chiave stessa, mantenendo la chiave pubblica privata fino al momento della spesa, generando un indirizzo più breve di 20 byte e costituendo la base di tutti gli indirizzi che iniziano con "1". Secondo i dati on-chain forniti da Unchained (aprile 2026), gli indirizzi P2PKH detengono attualmente circa il 43% dell’offerta di bitcoin estratti.

P2SH (Pay-to-Script-Hash, 2012, BIP 16)

Introdotto tramite soft fork il 1° aprile 2012, il P2SH ha trasferito l’onere degli script di spesa complessi dal mittente al destinatario. Anziché incorporare uno script di blocco completo nell’output, il P2SH genera un hash di 20 byte di uno “script di riscatto”. Lo script completo viene rivelato solo quando le monete vengono spese. Ciò ha reso la multisig praticabile per gli utenti comuni: una configurazione multisig 2 su 3 non richiedeva più che tutte e tre le chiavi pubbliche fossero visibili al mittente al momento del pagamento. Gli indirizzi P2SH iniziano con “3.”

Per una descrizione dettagliata di come funziona la convalida P2SH a livello di protocollo, Guida alle transazioni su developer.bitcoin.org illustra passo dopo passo il funzionamento dello script "redeem".

P2WPKH e P2WSH (SegWit nativo, 2017, BIP 141)

Segregated Witness, attivato nell’agosto 2017 al blocco 481.824, ha spostato i dati della firma fuori dal corpo principale della transazione in una struttura witness separata. I dati witness beneficiano di uno sconto del 75% sul peso, rendendo le transazioni SegWit notevolmente più economiche. Una transazione P2WPKH standard a un solo input e due output pesa circa 141 byte virtuali, rispetto ai 226 vbyte della transazione P2PKH equivalente, secondo Analisi dei tipi di indirizzi Bitcoin di Spark a partire da marzo 2026. SegWit ha inoltre risolto il problema della malleabilità delle transazioni, che rappresentava un prerequisito per il Lightning Network. Gli indirizzi SegWit nativi iniziano con "bc1q."

P2TR (Pay-to-Taproot, 2021, BIP 340/341/342)

Taproot è stato attivato nel novembre 2021 al blocco 709.632 e rappresenta l'aggiornamento più significativo al livello di scripting di Bitcoin dai tempi di SegWit. Ha introdotto le firme Schnorr, un nuovo tipo di output con supporto MAST e Tapscript come linguaggio di scripting aggiornato. Gli indirizzi Taproot iniziano con "bc1p."

Taproot e Tapscript: come è cambiato il linguaggio di scripting di Bitcoin nel 2021

Taproot non è una singola modifica. Si tratta di tre proposte di miglioramento di Bitcoin (Bitcoin Improvement Proposals) progettate insieme e attivate contemporaneamente.

BIP 340: Firme Schnorr

Inizialmente, Bitcoin utilizzava l'ECDSA (Elliptic Curve Digital Signature Algorithm). Satoshi lo scelse in parte perché all'epoca le firme Schnorr erano protette da brevetto. Tale brevetto è scaduto nel 2008 e Taproot ha finalmente introdotto le firme Schnorr nel protocollo.

Le firme Schnorr occupano meno spazio (64 byte) rispetto a quelle ECDSA (71-73 byte). Ma soprattutto, supportano l’aggregazione delle chiavi attraverso uno schema denominato MuSig2. L’aggregazione delle chiavi consente a più firmatari di combinare le proprie chiavi e firme individuali in un’unica chiave e firma aggregate, indistinguibili sulla blockchain da un normale pagamento con firma singola. Un portafoglio multisig 2 su 3 che effettua una transazione tramite il percorso cooperativo delle chiavi di Taproot appare identico a un pagamento standard sulla blockchain. Si tratta di un reale vantaggio in termini di privacy per chiunque detenga bitcoin nell’ambito di un complesso accordo di custodia.

BIP 341: Pay-to-Taproot e MAST

P2TR introduce un nuovo tipo di output con due percorsi di spesa:

• A percorso chiave effettuare il pagamento utilizzando una firma Schnorr, che viene impiegata quando tutte le parti sono d’accordo e desiderano la soluzione più semplice ed economica
• A percorso dello script utilizzare MAST (Merkelized Abstract Syntax Tree, ovvero l'implementazione del concetto in Taproot)

MAST consente a un singolo output di essere associato a un albero composto da più script di spesa tramite una radice di Merkle. Al momento della spesa, sulla blockchain viene rivelata solo la condizione specifica effettivamente utilizzata. Tutti gli altri possibili percorsi di spesa presenti nell’albero rimangono permanentemente nascosti. Per un utente che ha configurato una politica di spesa complessa, ad esempio «Posso spendere normalmente, oppure due dei tre amministratori fiduciari possono spendere dopo sei mesi, oppure una chiave di recupero può spendere dopo due anni», sulla blockchain compare sempre e solo il percorso effettivamente eseguito.

Nel 2024, la quota di Taproot nelle transazioni in Bitcoin era cresciuta fino a circa il 42%, trainata in gran parte dall’attività di iscrizione di Ordinals e BRC-20, secondo i dati di Glassnode citati da Spark nel marzo 2026. Da allora tale quota ha subito fluttuazioni in base alle condizioni di mercato, ma l’infrastruttura è ormai uno standard nei principali portafogli e exchange. Pagina dedicata a Taproot su Bitcoin Optech tiene traccia dello sviluppo in corso del protocollo Taproot.

BIP 342: Tapscript

Tapscript è il linguaggio di scripting aggiornato utilizzato per le transazioni "script-path" all'interno di Taproot. Condivide la maggior parte degli opcode con il Bitcoin Script tradizionale, ma introduce diverse modifiche significative:

• OP_CHECKMULTISIG e OP_CHECKMULTISIGVERIFY sono obsolete. Il vecchio codice operativo multisig presentava una peculiarità che richiedeva l'inserimento di un elemento fittizio nello stack come soluzione alternativa. Tapscript lo rimuove e lo sostituisce con OP_CHECKSIGADD, che verifica le firme Schnorr una alla volta e ne tiene il conteggio. Gli schemi multisig a soglia diventano più semplici e meno costosi da eseguire.
• I limiti di dimensione degli script per ogni foglia MAST sono stati rimossi. I singoli script all’interno di un ramo Taproot possono avere dimensioni illimitate.
• Codici operativi OP_SUCCESS rappresentano il cambiamento più lungimirante. Nello Script tradizionale, l’incontro con un opcode non definito causa il fallimento dello script. In Tapscript, gli opcode nell’intervallo OP_SUCCESS determinano il successo incondizionato dello script. I futuri soft fork potranno assegnare un comportamento effettivo a questi opcode aggiungendo vincoli sulle condizioni in cui hanno esito positivo, senza richiedere una nuova versione dello script o un ciclo completo di reimplementazione in tutto l’ecosistema. È possibile aggiungere nuove funzionalità al livello di scripting di Bitcoin in modo più pulito rispetto a qualsiasi altro momento precedente nella storia del protocollo.

Miniscript

Accanto a Tapscript, un progetto correlato chiamato Miniscript ha acquisito sempre maggiore rilevanza per gli sviluppatori. Miniscript rappresenta un approccio strutturato alla scrittura di un sottoinsieme di Bitcoin Script che è analizzabile, componibile e firmabile in modo generico. Mentre lo Script grezzo richiede una costruzione manuale ed è difficile da verificare, gli script Miniscript possono essere verificati automaticamente per garantirne la correttezza e combinati in policy più ampie. Non amplia le funzionalità di Script, ma rende ciò che già fa significativamente più accessibile agli sviluppatori che realizzano portafogli e strumenti di custodia.

Cosa consente Bitcoin Script: casi d'uso nel mondo reale

I seguenti tipi di transazione sono attualmente attivi sulla mainnet di Bitcoin, tutti basati sulle primitive di Bitcoin Script:

Portafogli multisignatura (multisig) richiedono M su N chiavi private per autorizzare una transazione di spesa. La tesoreria di un’azienda potrebbe richiedere 3 approvazioni su 5 per qualsiasi prelievo. Una coppia sposata potrebbe utilizzare 2 su 2 per i risparmi comuni. Grazie a Taproot e all’aggregazione delle chiavi Schnorr, le transazioni multisig cooperative sono ora indistinguibili on-chain dalle transazioni standard con firma singola.

Transazioni con vincolo temporale Utilizzare OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, o CLTV) e OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, o CSV) per impedire che i fondi vengano trasferiti prima che sia raggiunta una determinata altezza del blocco o sia trascorso un determinato periodo di tempo. Tra le applicazioni figurano la pianificazione successoria, i piani di maturazione dei token per i dipendenti, i meccanismi di risparmio obbligatorio e le transazioni con penali utilizzate all’interno dei canali della rete Lightning.

Contratti con blocco temporale (HTLC) combinano un requisito relativo alla preimmagine di un hash con un timelock. La condizione di spesa funziona così: se non si rivela la preimmagine di questo hash prima che il blocco raggiunga una determinata altezza, i fondi tornano al mittente. Gli HTLC sono la primitiva fondamentale della Lightning Network e consentono l’instradamento dei pagamenti senza necessità di fiducia attraverso catene di canali tra parti che non hanno alcun rapporto diretto.

Deposito a garanzia Tali meccanismi bloccano i fondi in uno script P2SH o Taproot, che richiede l’accordo di più parti prima del loro sblocco; in genere, un arbitro terzo detiene la chiave di decisione in caso di parità.

Contratti di registro discreti (DLC) utilizzare firme con adattatore Schnorr basate su oracolo per consentire la liquidazione di contratti finanziari sulla base di dati del mondo reale, quali feed di prezzi o esiti di eventi, senza che l’oracolo debba assumere la custodia di alcun fondo. I DLC sono attivi sulla mainnet di Bitcoin e vengono utilizzati per prodotti di opzioni e futures con liquidazione in Bitcoin.

Bitcoin Script contro gli smart contract di Ethereum

Sia Bitcoin Script che Solidity di Ethereum definiscono le condizioni alle quali è possibile trasferire fondi, ma rappresentano scelte architetturali fondamentalmente diverse. Vale la pena effettuare un confronto diretto, poiché le differenze spiegano in larga misura i compromessi che ciascuna rete ha accettato.

La differenza fondamentale sta nella natura "stateful". I contratti di Ethereum memorizzano e modificano dati che permangono da una transazione all’altra, rendendo possibili i protocolli di prestito, gli exchange decentralizzati, la governance on-chain e gli standard dei token. Bitcoin Script non ha nulla di equivalente. Ogni script viene eseguito in modo isolato, senza alcuna consapevolezza delle altre transazioni.

Si tratta di una scelta architettonica deliberata, non di una lacuna da colmare. Il livello di scripting di Bitcoin è stato progettato per un unico scopo specifico: garantire, in modo prevedibile e sicuro su larga scala, il rispetto delle condizioni necessarie per spendere i bitcoin. Per tale scopo, l’assenza di stato rappresenta un punto di forza. La superficie di attacco è più ridotta, l’esecuzione è deterministica su milioni di validatori indipendenti e non esiste alcuna categoria di exploit degli smart contract a livello di protocollo, poiché a tale livello non esistono contratti con stato.

I progetti che mirano a una maggiore programmabilità su Bitcoin la realizzano attraverso un approccio a livelli. Il Lightning Network gestisce i pagamenti. I protocolli DLC gestiscono i contratti finanziari riferiti a dati esterni. I sistemi di secondo livello, come Ark e Liquid Network, rispondono a diversi profili di scalabilità. Nulla di tutto ciò richiede la modifica del modello di scripting del livello di base.

Il dibattito sul Covenant: cosa potrebbe cambiare nello script di Bitcoin

L'evoluzione di Bitcoin Script è sempre stata lenta e prudente. L'area di sviluppo più attiva al momento è quella degli opcode "covenant", ovvero proposte che consentirebbero a uno script di limitare non solo chi può spendere un output, ma anche come deve essere strutturata la transazione risultante. Si tratta di un'espansione significativa della capacità espressiva di Script.

Le proposte principali al giugno 2026 sono:

• OP_CTV (BIP-119, CheckTemplateVerify), ideato da Jeremy Rubin, aggiunge un unico codice operativo che associa un UTXO a uno specifico modello di spesa prestabilito, comprendente la versione della transazione, il locktime, il numero di input, le sequenze, il numero di output e gli output stessi. È progettato per essere non ricorsivo, è considerato la proposta principale più conservativa e si rivolge principalmente ai vault, al controllo della congestione e ad alcuni miglioramenti di Lightning. Ad aprile 2026, OP_CTV presenta parametri di implementazione concreti che specificano una finestra di segnalazione Speedy Trial, ma non ha ancora raggiunto l’ampio consenso della comunità necessario per l’attivazione, secondo Analisi dei vincoli contrattuali di BlockEden per aprile 2026.
• OP_CAT (BIP-347), proposto da Ethan Heilman e Armin Sabouri, riattiverebbe un opcode che Satoshi aveva disabilitato nel 2010. OP_CAT concatena due elementi dello stack: un’operazione semplice nella descrizione, ma dalle ampie implicazioni. Se combinato con le firme Schnorr, consente un’introspezione delle transazioni simile a quella dei covenant. Sulla rete di test Signet di Bitcoin, secondo l’analisi on-chain condotta da sCrypt alla fine del 2024, OP_CAT aveva generato un numero significativamente maggiore di transazioni da parte degli sviluppatori rispetto sia ad APO che a CTV. OP_CAT è già attivo su Liquid Network e Fractal Bitcoin senza che gli siano stati attribuiti exploit. Il BIP-347 ha un numero di proposta ufficiale ed è supportato da una ricerca attiva, ma l’attivazione sulla mainnet richiede un consenso della comunità che al momento non esiste.
• LNHANCE combina OP_CTV con OP_CHECKSIGFROMSTACK (CSFS) e OP_INTERNALKEY, con l'obiettivo di apportare miglioramenti specifici alla creazione dei canali della rete Lightning, tra cui l'apertura di canali non interattivi e una gestione più efficiente dei canali multiparte.

A giugno 2026, nessuna di queste proposte è stata attivata sulla mainnet di Bitcoin. Le divergenze tecniche tra di esse sono in gran parte risolvibili. Il problema più complesso riguarda le modalità di attivazione. Il processo di soft fork di Bitcoin richiede un ampio consenso, e il dibattito sul patto porta con sé tensioni residue derivanti da precedenti aggiornamenti controversi. Ciò che emerge chiaramente dal dibattito è che il livello di scripting di Bitcoin ha un margine significativo di crescita all’interno del suo quadro conservativo. La questione su cui si sta lavorando riguarda la sequenza delle operazioni e l’accordo della comunità, non se il linguaggio di scripting abbia un futuro.

Conclusione

Bitcoin Script è l’infrastruttura invisibile alla base di ogni transazione sulla rete. La maggior parte degli utenti non entra mai direttamente in contatto con esso. I portafogli creano script validi, li firmano e li trasmettono senza mai rivelarne il funzionamento. Tuttavia, ogni pagamento, ogni canale Lightning, ogni piano con blocco temporale e ogni vault multisig passa attraverso lo stesso linguaggio di scripting Bitcoin basato su stack che è stato introdotto con il protocollo nel 2009.

Da allora il livello di scripting si è notevolmente ampliato: P2SH ha reso praticabili transazioni complesse, SegWit ha ridotto le commissioni e reso possibile Lightning, mentre Taproot ha introdotto le firme Schnorr, la privacy basata su MAST e il design degli opcode di Tapscript, compatibile con le versioni future. Le proposte di covenant attualmente oggetto di discussione rappresentano il prossimo potenziale capitolo. Se alcune di esse entreranno in vigore, e in quale arco temporale, rimane una questione davvero aperta a metà del 2026.

Per comprendere lo Script non è necessario essere uno sviluppatore. È invece necessario riconoscere che il conservatorismo di Bitcoin, le limitazioni deliberate, la cadenza lenta degli aggiornamenti e la mancanza di completezza di Turing non costituiscono una carenza. Le proprietà che rendono prevedibile lo Script di Bitcoin sono le stesse che hanno mantenuto pulito il livello di consenso per sedici anni.