Alle 09:30 UTC del 9 novembre 2026 blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il blocco 975.157 ha confermato una transazione di 223 byte il cui ID comincia con 47b6082f. Spende un output precedente da 9.109.701 satoshi e ne crea due nuovi, da 288.100 e da 8.820.000 satoshi; gli 1.601 satoshi che mancano sono andati al miner come commissione. In quei byte non c’è né il saldo di chi invia né il nome di chi riceve. Ci sono due piccoli lucchetti e una chiave che ha aperto un lucchetto più vecchio. Quei lucchetti sono scritti in Bitcoin Script, il minuscolo linguaggio di programmazione che ogni nodo completo esegue per decidere se una moneta può muoversi.
Diciassette anni prima, il 12 gennaio 2009, il blocco 170 conteneva una transazione con lo stesso scheletro: un input, due output, un numero di versione e un lock time. Mandava 10 BTC verso un nuovo lucchetto e riportava 40 BTC al suo creatore. Hal Finney scrisse sul forum Bitcointalk il 19 marzo 2013 di essere stato il destinatario della prima transazione bitcoin, dieci monete inviate da Satoshi Nakamoto come prova, e il pagamento da 10 BTC nel blocco 170 è quello che di solito si identifica con quella prova. Da allora il formato ha guadagnato dei campi, ma l’opcode che giudicò quel pagamento, OP_CHECKSIG, fa ancora parte delle regole che ogni nodo applica.
Ogni prefisso di indirizzo che un wallet mostra, 1, 3, bc1q o bc1p, indica uno di pochi lucchetti standard. Multisig, timelock e regole di inoltro dei nodi sono in fondo regole su come quei lucchetti vengono scritti ed eseguiti, e si possono leggere direttamente nei byte.
Una transazione bitcoin sposta lucchetti, non saldi
Bitcoin non tiene conti. Tiene un insieme di output non spesi, ciascuno un importo con un lucchetto attaccato, e una transazione ne distrugge alcuni e ne crea di nuovi. Un output si spende sempre per intero, quindi un pagamento di solito produce un resto che torna a chi invia, e il saldo di un wallet è soltanto la somma degli output che le sue chiavi sanno aprire. Selezione delle monete, dust, consolidamento e gli indizi di privacy che gli output lasciano sono trattati nella nostra lezione su i modelli UTXO e account; qui si danno per noti.
Lo stesso vale per le commissioni. Una transazione paga in base alla dimensione, misurata in unità di peso e in byte virtuali, a una tariffa in satoshi per byte virtuale che sceglie chi invia e che i miner mettono in classifica. Come funziona quell’asta, come replace-by-fee e child-pays-for-parent salvano un pagamento bloccato e perché sei conferme sono diventate un’abitudine è spiegato nella nostra guida alla mempool e alle commissioni di transazione. Da dove vengano quei byte, e che cosa faccia ciascuno, è un’altra questione.
Un’idea del white paper dà la cornice a tutto il resto. Satoshi Nakamoto scrisse nella sezione 2: «Definiamo una moneta elettronica come una catena di firme digitali.» Ogni output dice quale firma vuole; ogni input la fornisce. Se chiavi pubbliche e firme sono una novità per te, leggi prima come funzionano le chiavi private e pubbliche, perché ogni lucchetto qui sotto finisce con un controllo di firma.
I byte di una transazione Bitcoin, campo per campo
Una transazione è una breve stringa di byte con un ordine fisso. Il riferimento per sviluppatori di Bitcoin la documenta campo per campo. Conteggi e lunghezze usano un intero di dimensione variabile chiamato compactSize: un byte per i valori fino a 252, poi un byte marcatore (0xfd, 0xfe o 0xff) seguito da 2, 4 o 8 byte. I numeri sono memorizzati in little-endian, cioè col byte meno significativo per primo, ed è per questo che i dump esadecimali sembrano rimescolati all’occhio umano.
Sette campi, due dei quali solo nelle transazioni SegWit
| Campo | Dimensione | Che cosa contiene |
|---|---|---|
| version | 4 byte | 1 o 2 nella maggior parte delle transazioni; 2 attiva i timelock relativi (BIP 68). Bitcoin Core inoltra le versioni da 1 a 3 |
| marker e flag | 2 byte (0x00 0x01) | Presenti solo quando la transazione porta dati witness (SegWit) |
| input count | compactSize | Numero di input |
| inputs | 36 byte + script + 4 byte ciascuno | Outpoint (txid precedente e indice dell’output), scriptSig, sequence |
| output count | compactSize | Numero di output |
| outputs | 8 byte + script ciascuno | Valore in satoshi e scriptPubKey (il lucchetto) |
| witness | variabile | Una pila di elementi per input, solo SegWit |
| lock time | 4 byte | Altezza di blocco o istante più prossimi in cui la transazione è valida |
Un input punta a un output precedente e porta la prova
Un input non dice quanto spende. Indica un output precedente tramite il suo outpoint: l’ID di 32 byte della transazione che l’ha creato più un indice di 4 byte dell’output all’interno di quella transazione. Il nodo cerca l’outpoint nel proprio UTXO set, trova importo e lucchetto e controlla la prova. Questa ricerca è il motivo per cui una transazione non può essere convalidata da chi non conosce le monete che spende.
Il txid dentro un outpoint è memorizzato in ordine di byte interno, l’inverso di quello che mostrano i block explorer. L’input della nostra transazione del 9 novembre spende un output della transazione 403f3c54…f864, eppure l’esadecimale grezzo comincia quel campo con 64f81cf0. Sono gli stessi 32 byte letti in direzioni opposte.
Dopo l’outpoint viene lo scriptSig, i dati che soddisfano il vecchio lucchetto, con la sua lunghezza davanti. Nei vecchi tipi di indirizzo contiene una firma e una chiave pubblica; nelle spese SegWit è vuoto e la prova passa al witness. L’input termina con un numero di sequenza di 4 byte. Oggi svolge tre compiti: un valore inferiore a 0xffffffff permette al lock time di applicarsi, 0xfffffffd è il valore che i wallet usano per segnalare che accettano l’aumento della commissione (BIP 125), e nelle transazioni di versione 2 può portare un timelock relativo (BIP 68).
Un output è un importo e un lucchetto
Un output ha solo due parti: un valore in satoshi su 8 byte e una scriptPubKey, lo script di blocco. Il valore può essere zero, ed è così che funzionano gli output di dati. La scriptPubKey decide tutto sulla proprietà: chi sa produrre dati che la fanno riuscire può spendere l’importo, e nient’altro nel protocollo registra a chi appartenga.
Un input per blocco è diverso. La transazione coinbase che paga il miner ha un solo input con outpoint nullo, 32 byte a zero e indice 0xffffffff, e uno script libero fino a 100 byte che dal BIP 34 deve cominciare con l’altezza del blocco. I suoi output rivendicano il sussidio più le commissioni, l’importo che si dimezza ogni 210.000 blocchi come spiega la nostra lezione su il halving di bitcoin e il sussidio di blocco.
La transazione 47b6082f, letta byte per byte
Ecco l’esadecimale completo della transazione del blocco 975.157 su mempool.space, tagliato ai confini dei campi. Pesa 565 unità di peso e spende un output SegWit nativo, quindi marker, flag e witness sono presenti.
02000000 version 2
00 01 SegWit marker and flag
01 1 input
64f81cf0...543c3f40 previous txid (403f3c54...f864 reversed)
00000000 output index 0
00 scriptSig length 0 (empty)
fdffffff sequence 0xfffffffd
02 2 outputs
6465040000000000 288,100 sat (0x046564)
16 0014 08696e26...a99d96 22-byte script: OP_0, push 20 bytes (P2WPKH)
2095860000000000 8,820,000 sat (0x869520)
17 a914 33972a6d...8e5177 87 23-byte script: OP_HASH160, push 20, OP_EQUAL (P2SH)
02 witness: 2 items for input 0
47 3044...01 71 bytes: DER signature + sighash byte 0x01
21 02e1b9f5...213edd 33 bytes: compressed public key
33e10e00 lock time 975,155 (0x0ee133)Letti in ordine, i byte raccontano una piccola storia. Versione 2. Un input, che prende l’output 0 di una transazione precedente, il quale secondo l’explorer conteneva 9.109.701 satoshi in un lucchetto P2WPKH. Uno scriptSig vuoto, perché la prova sta nel witness. Una sequence di 0xfffffffd, che segnala che chi invia accetta l’aumento della commissione. Due output: 288.100 satoshi verso un indirizzo bc1q e 8.820.000 satoshi verso un indirizzo che comincia con 3. Poi il witness: una firma che termina con 0x01, il flag SIGHASH_ALL, e la chiave pubblica il cui hash corrisponde al vecchio lucchetto. Infine un lock time di 975.155.
Quale output è il pagamento e quale il resto? I byte non lo dicono. Un explorer o un analista di blockchain può solo tirare a indovinare, e l’ipotesi può essere sbagliata. I conti confermano soltanto la commissione: 9.109.701 meno 288.100 meno 8.820.000 lascia 1.601 satoshi, che nessun output rivendica e che il miner incassa.
Da dove vengono il txid, il peso e la tariffa
Il txid è il doppio hash SHA-256 della transazione serializzata senza marker, flag e witness, mostrato in ordine di byte inverso. Togliendo quei campi dall’esadecimale qui sopra restano 114 byte; il loro doppio SHA-256, invertito, è 47b6082f…d26a. Lasciare il witness fuori dall’ID è ciò che permette a una firma di cambiare senza cambiare il txid, una proprietà introdotta da SegWit.
Il peso conta i byte non-witness quattro volte e quelli witness una volta: 114 x 3 + 223 = 565 unità di peso, cioè 141,25 byte virtuali, che gli explorer arrotondano per eccesso a 142 vB. La commissione di 1.601 satoshi divisa per 141,25 dà circa 11,3 satoshi per byte virtuale. È la tariffa che questa transazione ha pagato quando è stata minata; non dice nulla sulla tariffa da pagare oggi, che alla stessa ora mempool.space quotava a 1-2 sat/vB.
Bitcoin Script: un linguaggio a pila senza cicli
Bitcoin Script si legge da sinistra a destra. Gli elementi di dati vengono messi sulla pila; gli opcode tolgono elementi, li elaborano e rimettono i risultati. Ci sono condizionali (OP_IF, OP_ELSE) ma niente cicli e nessun salto all’indietro, quindi ogni script finisce in un numero di passi noto in anticipo. È un limite voluto: un nodo deve poter controllare migliaia di script per blocco senza rischiare un programma che non finisce mai.
Il codice sorgente di Bitcoin Core aggiunge tetti rigidi. Un singolo elemento inserito può contenere al massimo 520 byte, uno script al massimo 10.000 byte, uno script può eseguire al massimo 201 opcode che non siano push, la pila può contenere al massimo 1.000 elementi e OP_CHECKMULTISIG accetta al massimo 20 chiavi pubbliche. Gli opcode aritmetici lavorano su numeri di al massimo 4 byte. Questi valori sono nel file script.h e nell’interprete, e sono regole di consenso: un blocco che contiene uno script che le viola non è valido.
Spendere un output P2PKH, un opcode alla volta
La spesa P2PKH più famosa è forse quella nel blocco 57.043. Il 18 maggio 2010 un utente del forum di nome laszlo offrì su Bitcointalk 10.000 bitcoin in cambio di un paio di pizze grandi, e il 22 maggio riferì che lo scambio era fatto. La transazione confermata quel giorno alle 18:16 UTC ha 131 input, tutti di tipo P2PKH, e un solo output da 10.000 BTC. Il suo primo input spende un output da 150 BTC il cui lucchetto è questo:
OP_DUP OP_HASH160 <05bf3a3aea6335a3949c0a351ff3afcba884e125> OP_EQUALVERIFY OP_CHECKSIGLo scriptSig dell’input è di 140 byte: una firma di 73 byte e una chiave pubblica non compressa di 65 byte, due push e nient’altro. Il nodo esegue prima lo scriptSig, che lascia quei due elementi sulla pila, poi esegue la scriptPubKey su quella pila. La tabella mostra la pila dopo ogni passo, con la cima a destra.
| Passo | Elemento eseguito | Pila dopo il passo |
|---|---|---|
| 0 | lo scriptSig mette i suoi due elementi | sig, pubKey |
| 1 | OP_DUP copia l’elemento in cima | sig, pubKey, pubKey |
| 2 | OP_HASH160 ne calcola l’hash: RIPEMD-160 di SHA-256 | sig, pubKey, hash(pubKey) |
| 3 | si inseriscono i 20 byte 05bf3a3a…e125 dal lucchetto | sig, pubKey, hash(pubKey), 05bf3a3a…e125 |
| 4 | OP_EQUALVERIFY confronta i due hash e fa fallire lo script se differiscono | sig, pubKey |
| 5 | OP_CHECKSIG controlla sig rispetto a pubKey e alla transazione | true |
Al passo 4 si ferma una chiave sbagliata: una chiave pubblica diversa dà un hash diverso, e lo script finisce in errore prima che qualsiasi firma sia controllata. Al passo 5 si ferma una firma sbagliata. Solo chi possiede la chiave privata dietro quella chiave pubblica può firmare questa particolare transazione, quindi solo lui può produrre dati che lasciano true sulla pila.
La transazione della pizza mostra anche quanto spazio costava questo primo formato di script. 111 dei suoi 131 input erano output da 0,01 BTC ciascuno, e ognuno portava il proprio scriptSig da 138 a 140 byte, in gran parte una chiave pubblica non compressa da 65 byte e una firma. Con outpoint e sequence, ogni input occupava circa 180 byte, e l’intera transazione 23.620 byte per un solo output. Un input SegWit nativo con chiave compressa oggi occupa circa 68 byte virtuali.
Perché il lucchetto contiene l’hash della chiave, non la chiave
I primissimi output, come quelli del blocco 170, mettevano l’intera chiave pubblica nel lucchetto, seguita da OP_CHECKSIG. Quel tipo, pay-to-public-key, occupa 65 byte di chiave pubblica in ogni output, e chiunque può vedere la chiave prima ancora che venga usata. Pay-to-public-key-hash l’ha sostituito con un hash di 20 byte. L’output è più corto, e la chiave pubblica compare sulla blockchain solo quando la moneta viene spesa.
L’hash di 20 byte è anche ciò che un indirizzo codifica. Un indirizzo legacy è quell’hash più un byte di versione e un checksum, scritti in Base58 in modo che un errore di battitura venga rilevato prima che il denaro parta. La nostra lezione su che cos’è un indirizzo crypto mostra la codifica; il punto qui è che un indirizzo è una descrizione compatta di una scriptPubKey, non un conto.
I due script vengono eseguiti uno dopo l’altro, non incollati
Nella prima versione di Bitcoin il nodo univa scriptSig e scriptPubKey in un unico script e lo eseguiva. Questo permetteva a uno scriptSig di contenere opcode che interferivano con il lucchetto, e una correzione successiva ha diviso l’esecuzione in due. L’interprete di Bitcoin Core porta ancora il commento secondo cui i due script devono essere valutati in sequenza sulla stessa pila e non concatenati, con riferimento a CVE-2010-5141.
Il successo ha un significato preciso. Dopo l’esecuzione di entrambi gli script, la pila non deve essere vuota e il suo elemento in cima deve contare come vero. In Script una stringa di byte è falsa quando è vuota, fatta solo di byte a zero, oppure zero con il bit del segno acceso (zero negativo); tutto il resto è vero. Se un qualsiasi opcode fallisce lungo la strada, per esempio un opcode VERIFY che incontra un falso, l’intera spesa non è valida.
Quindici opcode spenti nell’agosto 2010
Il linguaggio di script che Satoshi distribuì all’inizio era più ampio. Un commit fatto sotto il nome s_nakamoto il 15 agosto 2010, con il messaggio «misc changes», aggiunse un controllo che fa fallire qualsiasi script contenga OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT, OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT o OP_RSHIFT. Lo stesso commit abbassò l’elemento inseribile massimo da 5.000 a 520 byte e ridusse gli operandi numerici da 258 a 4 byte. Il messaggio del commit non dà alcun motivo; l’attuale Bitcoin Core etichetta il controllo «Disabled opcodes (CVE-2010-5137)», un riferimento a un bug in quella famiglia di opcode.
«Disabilitati» è dire poco. Anche dentro un ramo di un OP_IF che non viene mai eseguito, uno di quegli opcode fa fallire lo script. Riportare in vita OP_CAT è una proposta ancora aperta, il BIP 347, uno dei dibattiti della nostra prossima lezione su governance di Bitcoin e BIP.
Cinque tipi di output, quattro prefissi di indirizzo
I wallet non inventano i lucchetti. Usano un piccolo insieme di modelli standard, ciascuno con il proprio formato di indirizzo. Conoscere il modello dietro un indirizzo dice che cosa dovrà rivelare chi spende e più o meno quanti byte costerà.
P2PK e P2PKH: i lucchetti del 2009
Pay-to-public-key (P2PK) è il lucchetto del blocco 170: una chiave pubblica e OP_CHECKSIG; per spenderlo lo scriptSig contiene soltanto una firma. Non ha un formato di indirizzo proprio. Pay-to-public-key-hash (P2PKH) è il lucchetto a cinque opcode eseguito nella tabella qui sopra. I suoi indirizzi cominciano con 1 sulla mainnet, come l’indirizzo 1XPTgDRh… dietro l’input della pizza.
P2SH: il lucchetto che contiene solo l’hash di uno script
Scritto da Gavin Andresen, il BIP 16 e applicato ai blocchi dal 1° aprile 2012, ha introdotto pay-to-script-hash. La scriptPubKey è OP_HASH160, un hash di 20 byte e OP_EQUAL. Chi spende rivela lo script completo, il redeemScript, come ultimo push dello scriptSig, insieme ai dati che gli servono. Un nodo controlla prima che il redeemScript abbia come hash il valore nel lucchetto, poi esegue il redeemScript stesso sulla pila restante.
P2SH ha spostato costo e complessità da chi paga a chi spende. Chi paga un wallet multisig 2-di-3 invia a un indirizzo corto che comincia con 3, come fa l’output da 8.820.000 satoshi della nostra transazione del 9 novembre, e non vede mai le chiavi. Il redeemScript è un elemento inserito, quindi vale il limite di 520 byte: al massimo 15 chiavi pubbliche compresse in un multisig. Il BIP 16 era un soft fork, una modifica delle regole che i vecchi nodi accettano ancora, come spiega la nostra lezione su soft fork e hard fork.
Gli output SegWit e Taproot, in due righe
SegWit versione 0, attivato nell’agosto 2017, ha aggiunto P2WPKH (OP_0 più un hash di chiave di 20 byte) e P2WSH (OP_0 più un hash di script di 32 byte), con indirizzi che cominciano con bc1q; la prova passa nel witness. Taproot, attivato nel 2021, ha aggiunto P2TR (OP_1 più una chiave di 32 byte), con indirizzi che cominciano con bc1p. Come funzionano witness, peso, firme Schnorr e alberi di script è l’argomento della prossima lezione di questo percorso, SegWit e Taproot.
OP_RETURN, multisig nudo e anchor
Altri tre tipi di output compaiono in ogni blocco. Un output OP_RETURN comincia con un opcode che fallisce subito, quindi non può mai essere speso; porta dati, di solito con valore zero, e i nodi non lo conservano nell’UTXO set. Il multisig nudo mette nell’output lo script m-di-n completo, senza hash. E gli explorer mostrano ormai un minuscolo output etichettato anchor (pay-to-anchor): lo script di quattro byte OP_1 seguito dai due byte 0x4e73, che Bitcoin Core riconosce proprio da quel modello e che si spende con un witness vuoto, senza alcuna firma. Esiste perché una transazione figlia successiva possa aggiungere commissione.
I tipi di output in nove blocchi del 9 novembre 2026: un piccolo campione
Non esiste un conteggio ufficiale unico dei tipi di output, e i grafici di lunga data di transactionfee.info vivono ora su mainnet.observer come grafici interattivi. Per questo Coindaro ha fatto il proprio conteggio: ha letto i blocchi grezzi da 975.149 a 975.157 da mempool.space il 9 novembre 2026 e ha classificato ogni output in base al suo modello di script. È un campione piccolo, nove blocchi i cui timestamp di intestazione vanno dalle 08:30 alle 09:33 UTC di quella mattina, e le sue due metà sono già in disaccordo, che è proprio il senso della tabella.
| Tipo di output | Prefisso dell’indirizzo | Blocchi 975.149-975.154 (42.379 output) | Blocchi 975.155-975.157 (40.551 output) | Tutti i nove blocchi (82.930 output) |
|---|---|---|---|---|
| P2WPKH | bc1q | 60,3% | 46,6% | 53,6% |
| OP_RETURN (dati) | nessuno | 18,9% | 40,2% | 29,3% |
| P2TR | bc1p | 8,2% | 3,2% | 5,8% |
| P2SH | 3 | 5,7% | 1,9% | 3,8% |
| P2PKH | 1 | 5,4% | 1,9% | 3,7% |
| P2WSH | bc1q (più lungo) | 1,6% | 0,5% | 1,0% |
| Pay-to-anchor | nessuno | 0,0% | 5,7% | 2,8% |
Fonte: conteggio di Coindaro dei 82.930 output creati nei blocchi da 975.149 a 975.157 (37.675 transazioni), blocchi grezzi da mempool.space, 9 novembre 2026. Un campione di nove blocchi, circa un’ora di catena, non una tendenza. Output P2PK e multisig nudi non vi sono comparsi.
Le chiavi SegWit native dominano in entrambe le metà. Il resto oscilla: gli output di dati erano il 19% degli output nei primi sei blocchi e il 40% nei tre successivi, e gli anchor sono passati da nessuno a 2.323, tutti nel blocco 975.155. Il solo blocco 975.157 conteneva 7.941 output di dati tra i suoi 15.923 output, quasi uno per ciascuna delle sue 7.959 transazioni. Bastano pochi grandi lotti di transazioni che portano dati o usano anchor per spostare di decine di punti la quota su tre blocchi, quindi una fotografia di un solo giorno dei tipi di output va letta come il tempo che fa, non come il clima. Lasciando da parte gli output di dati, P2WPKH rappresentava comunque circa tre quarti degli output spendibili creati in ciascuna metà (74,3% e 77,9%).
Che cosa impegna una firma: i flag sighash
OP_CHECKSIG non controlla una firma rispetto all’intera transazione così com’è sulla rete. La controlla rispetto a un digest costruito da una copia modificata della transazione, e l’ultimo byte della firma, il flag sighash, dice quali parti sono entrate in quella copia. La guida per sviluppatori di Bitcoin elenca le opzioni. Tutte firmano il lock time.
| Flag (byte) | A che cosa si impegna chi firma | Che cosa possono ancora cambiare gli altri |
|---|---|---|
| SIGHASH_ALL (0x01) | Tutti gli input e tutti gli output | Nulla, tranne gli script di firma degli altri input |
| SIGHASH_NONE (0x02) | Tutti gli input, nessun output | Dove va il denaro, a meno che un’altra firma protegga gli output |
| SIGHASH_SINGLE (0x03) | Tutti gli input e l’unico output con lo stesso indice | Ogni altro output |
| ALL | ANYONECANPAY (0x81) | Questo input e tutti gli output | Altri input possono essere aggiunti o tolti |
| NONE | ANYONECANPAY (0x82) | Solo questo input | Tutto il resto |
| SINGLE | ANYONECANPAY (0x83) | Questo input e il suo output corrispondente | Altri input e altri output |
Quasi ogni pagamento da wallet usa SIGHASH_ALL; sia la nostra transazione del 2026 sia l’input della pizza terminano la firma con 0x01. Gli altri flag esistono per la cooperazione tra persone che non si fidano l’una dell’altra. Con ALL | ANYONECANPAY, per esempio, un gruppo potrebbe finanziare un unico output, con ogni partecipante che firma solo il proprio input e l’obiettivo fissato, e la transazione diventa valida solo quando gli input raggiungono la somma.
SIGHASH_SINGLE porta con sé una vecchia trappola. Se chi firma lo usa su un input il cui indice non ha un output corrispondente, il codice originale firma il valore 1 invece di un vero digest, cosa che la guida per sviluppatori descrive come una rottura dello schema di sicurezza: una firma fatta così può essere riutilizzata. I wallet evitano del tutto il caso.
Le firme stesse sono ECDSA codificate in DER negli script legacy e SegWit v0, di solito di 71 o 72 byte col flag. Il BIP 66, in vigore dal blocco 363.725 nel luglio 2015, ha reso la codifica DER rigorosa una regola di consenso. Anche allora una terza parte poteva trasformare una firma valida in un’altra firma valida e quindi cambiare il txid di una transazione non confermata, un problema noto come malleabilità. SegWit l’ha eliminato togliendo le firme dal txid, come spiega la prossima lezione.
Multisig e l’elemento in più che OP_CHECKMULTISIG si mangia
Un lucchetto multisig richiede m firme su n chiavi pubbliche. Lo script è un numero m, le n chiavi, il numero n e OP_CHECKMULTISIG, con m e n scritti come gli opcode da OP_1 a OP_16. Un lucchetto 2-di-3 ha questo aspetto:
OP_2 <pubKeyA> <pubKeyB> <pubKeyC> OP_3 OP_CHECKMULTISIG
scriptSig: OP_0 <sigA> <sigC>L’opcode toglie n, le chiavi, m e le firme, poi scorre le due liste. Le firme devono arrivare nello stesso ordine delle loro chiavi, perché il codice avanza tra le chiavi e non torna mai indietro. Poi toglie ancora un elemento. L’interprete di Bitcoin Core lo dice chiaramente: «A bug causes CHECKMULTISIG to consume one extra argument whose contents were not checked in any way.» Eliminare quel pop in più avrebbe cambiato il modo in cui vengono valutati gli script già presenti sulla blockchain, quindi il bug è rimasto, e ogni spesa multisig comincia il proprio scriptSig con un OP_0 usa e getta per alimentarlo.
Poiché l’elemento in più non è mai stato controllato, chiunque inoltrasse una spesa multisig poteva sostituire l’OP_0 con un altro valore e cambiare l’ID della transazione senza invalidarla. Quella falla è stata chiusa dal BIP 147 quella falla con la regola NULLDUMMY: il dummy deve essere un array di byte vuoto. Bitcoin Core la applicava come policy di inoltro dalla versione 0.10.0, ed è diventata regola di consenso con il rilascio di SegWit nel 2017.
Il multisig è il modo in cui aziende, fondi e privati prudenti ripartiscono il controllo del cold storage su più dispositivi o più persone, e in cui funziona un escrow senza un agente che tenga le monete; la nostra voce del glossario sui wallet multisig ne tratta il lato pratico. Nella pratica quasi nessuno usa più gli output multisig nudi. La policy di inoltro di Bitcoin Core accetta il multisig nudo con al massimo 3 chiavi, e l’incapsulamento in P2SH o P2WSH tiene lo script lungo fuori dall’output finché non viene speso. Con P2SH il limite standard di 1.650 byte per lo scriptSig è, secondo la guida per sviluppatori, abbastanza grande per un multisig 15-di-15 con chiavi compresse.
Timelock: monete che non possono muoversi prima di una data
Bitcoin ha quattro strumenti di timelock. Due stanno nella transazione stessa e dicono quando la transazione diventa valida; due sono opcode dentro un lucchetto e dicono quando un output può essere speso. Due sono assoluti (un’altezza di blocco o una data), due sono relativi (un ritardo contato dal momento in cui la moneta è stata creata).
nLockTime e la protezione anti fee sniping nella nostra transazione
Il lock time di 4 byte alla fine di ogni transazione viene letto come altezza di blocco quando è inferiore a 500.000.000 e come ora Unix altrimenti. Una transazione con un lock time nel futuro non può ancora entrare in un blocco. La regola ha un’insidia del 2009: si applica solo se almeno un input ha un numero di sequenza inferiore a 0xffffffff, ed è per questo che i wallet che impostano un lock time abbassano anche la sequence.
La nostra transazione del 9 novembre ha lock time 975.155, e mempool.space la mostra confermata nel blocco 975.157. Quale wallet l’abbia costruita non si sa, ma lo schema è un’abitudine nota chiamata anti-fee-sniping, seguita tra gli altri dal wallet di Bitcoin Core. Il sorgente di Core imposta il lock time all’altezza dell’attuale punta della catena, così la transazione può entrare solo nel blocco successivo o in uno più avanti. Lo scopo è scoraggiare il fee sniping, un attacco in cui un grande miner rifà il blocco più recente per prenderne le commissioni: una transazione che non può essere collocata a un’altezza precedente dà a quel miner meno da portare via. In circa un caso su dieci Core sceglie a caso un’altezza più vecchia fino a 100 blocchi, in modo che le transazioni trasmesse qualche tempo dopo la firma, come alcune transazioni CoinJoin, si confondano con le altre.
OP_CHECKLOCKTIMEVERIFY: un lucchetto con una data
nLockTime ritarda solo una transazione già firmata da qualcuno, e chi firma può sempre firmarne un’altra senza ritardo. Opera di Peter Todd, il BIP 65 mette la data dentro l’output. OP_CHECKLOCKTIMEVERIFY confronta un numero nello script con l’nLockTime della transazione che spende e fallisce a meno che il lock time sia dello stesso tipo e almeno altrettanto grande, con una sequence dell’input inferiore a 0xffffffff. Poiché la transazione non può essere minata prima del suo lock time, la moneta non può muoversi prima della data nello script. Il BIP 65 ha ridefinito un opcode inattivo, OP_NOP2, quindi era un soft fork; Bitcoin Core registra la sua attivazione al blocco 388.381, minato il 14 dicembre 2015.
<expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIGLock relativi: nSequence e OP_CHECKSEQUENCEVERIFY
Con il BIP 68 il campo sequence ha avuto una seconda vita nelle transazioni di versione 2 o superiore. Quando il bit 31 non è acceso, i 16 bit bassi contengono un ritardo che deve trascorrere tra la conferma dell’output speso e la transazione che lo spende. Il bit 22 sceglie l’unità: blocchi, oppure unità di 512 secondi. Il massimo è 65.535 blocchi, circa 455 giorni a dieci minuti per blocco, oppure 65.535 x 512 secondi, circa 388 giorni.
Con il BIP 112 è arrivato l’opcode corrispondente, OP_CHECKSEQUENCEVERIFY, al posto di OP_NOP3, perché un output possa pretendere un simile ritardo. I due sono stati rilasciati insieme al BIP 113, che misura il tempo con il timestamp mediano dei blocchi recenti, e Bitcoin Core registra la loro attivazione al blocco 419.328, minato alle 23:16 UTC del 4 luglio 2016. Un lock relativo è ciò che serve ai canali di pagamento: una parte può chiudere un canale da sola, ma deve attendere un numero fisso di blocchi prima di prendere la sua quota, lasciando all’altra il tempo di reagire. Il Lightning Network, argomento di una lezione successiva di questo percorso, è costruito su quel ritardo.
| Strumento | Dove si trova | Assoluto o relativo | Introdotto |
|---|---|---|---|
| nLockTime | Campo della transazione | Assoluto (altezza o ora) | 2009, codice originale |
| OP_CHECKLOCKTIMEVERIFY | Script dell’output | Assoluto | BIP 65, blocco 388.381, 14 dic 2015 |
| Lock nSequence | Campo dell’input (versione 2+) | Relativo (blocchi o unità di 512 secondi) | BIP 68, blocco 419.328, 4 lug 2016 |
| OP_CHECKSEQUENCEVERIFY | Script dell’output | Relativo | BIP 112, blocco 419.328, 4 lug 2016 |
I piani di successione usano gli stessi strumenti in modo più lento: un wallet può bloccare le monete sulla chiave del proprietario oggi e aggiungere un secondo percorso che si apre con la chiave di un parente solo dopo un anno senza movimenti. Pochi wallet per il pubblico espongono queste opzioni, ma gli opcode che le sostengono fanno parte del consenso dal 2015 e dal 2016.
Regole di consenso e standardness
Tutto ciò che sopra rende invalido un blocco è consenso: i limiti degli script, gli opcode disabilitati, NULLDUMMY dal 2017, le regole dei timelock. I nodi applicano un secondo livello, più severo, alle transazioni che non hanno ancora visto in un blocco, chiamato standardness o policy di inoltro. Una transazione non standard non è invalida; i nodi con le impostazioni predefinite semplicemente rifiutano di trasmetterla. La lezione sulla mempool linkata sopra spiega i limiti di policy su dimensione, dust e tariffa (400.000 unità di peso, dust calcolato a 3 sat/vB, commissione minima di inoltro di 0,1 sat/vB nell’attuale Bitcoin Core). Qui conta la policy relativa agli script.
| Policy di Bitcoin Core (policy.h, ramo master, 9 nov 2026) | Valore | Limite di consenso a confronto |
|---|---|---|
| scriptSig standard massimo | 1.650 byte | script da 10.000 byte |
| Multisig nudo inoltrato | Fino a 3 chiavi | Fino a 20 chiavi |
| Operazioni di firma in un redeemScript P2SH | 15 | Nessun limite specifico |
| Script witness P2WSH massimo | 3.600 byte | 10.000 byte |
| Versioni di transazione inoltrate | Da 1 a 3 | Qualsiasi |
| Dimensione minima senza witness | 65 byte | Nessuna |
Oltre ai numeri, la policy accetta solo i modelli di output noti elencati prima e richiede scriptSig che si limitino a inserire dati. Uno script costruito con una combinazione insolita di opcode può essere perfettamente valido, ma viaggerà solo se un miner lo riceve direttamente e sceglie di includerlo. Una volta in un blocco, ogni nodo lo accetta, perché i blocchi sono giudicati solo dal consenso.
La policy può cambiare con un rilascio del software senza fork; il consenso non può cambiare senza un soft fork o un hard fork, con il coordinamento descritto nella lezione sui fork. Il limite più ampio per i dati OP_RETURN che Bitcoin Core 30.0 ha portato nell’ottobre 2025, descritto nella lezione sulla mempool, è stato un cambiamento di policy di questo tipo (la documentazione scritta prima parla ancora di 80 byte); la disputa che lo ha accompagnato appartiene alla prossima lezione sulla governance di Bitcoin.
Leggere le proprie transazioni su un explorer
Con questi pezzi, la pagina di un explorer si legge in modo diverso. La scheda degli input elenca gli outpoint e, per ciascuno, il tipo di lucchetto che è stato aperto; la scheda degli output elenca i nuovi lucchetti. Un input di tipo P2PKH mostra una firma e una chiave pubblica intera, un input P2WPKH mostra gli stessi due elementi nel witness, e un input P2TR con key path mostra una sola firma di 64 o 65 byte. La nostra guida su come leggere un block explorer passa in rassegna le schermate.
Ne seguono due abitudini. Controlla il lock time e i numeri di sequenza quando un pagamento sembra bloccato: un lock time nel futuro, o una sequence non finale su una transazione che ne dipende, spiega un ritardo che nessuna commissione risolverà. E ricorda che la rete vede script, non persone: un explorer non sa dire se un output va a un commerciante o torna a chi invia come resto.
Quest’ultimo punto conta al momento delle imposte. In Italia l’Agenzia delle Entrate indica, nella brochure sulla legge di bilancio 2025, l’imposta del 33% sulle plusvalenze da cripto-attività realizzate dal 1° gennaio 2026, senza soglia di esenzione; la nostra guida alle tasse sulle crypto in Italia spiega come si applica. Poiché la catena non può mostrare chi controlla un output, la prova spetta a te: conserva il txid, la data e un appunto su quali output erano tuoi.
La prossima lezione di questo percorso riparte da dove si è fermata la tabella dei tipi di output: come SegWit ha spostato le firme nel witness e perché Taproot ha fatto sembrare un multisig un pagamento a chiave singola.
