liberlume-content-v3
lang: it
title: Le serrature di Bitcoin
summary: Ogni moneta su Bitcoin sta dietro una serratura: lo scriptPubKey, il programma che dice a quali condizioni si spende. La voce di riferimento sui tipi di serratura, dai primi output del 2009 a Taproot e alle proposte quantum-resistant: P2PK, P2PKH, bare multisig, P2SH, SegWit (P2WPKH e P2WSH), P2TR, ciascuno mostrato byte per byte su una transazione reale verificabile con un nodo. Che cosa espone ciascun tipo della chiave pubblica, perché serratura e indirizzo non sono la stessa cosa, e come si legge il linguaggio degli script: push, op e pila.
btc-anchor: 961200,000000000000000000011cfa417c07445190afe0a7be85c1c3d8d3ffaf119931
prev: sha256:e22dd13b20c3be960d6616679f99d51289f23449f0f4eb65604f490c0a17a4fd
--- body ---
Ogni moneta su Bitcoin sta dietro una serratura: un piccolo programma, lo
scriptPubKey, che dice a quali condizioni quella moneta si può spendere.
Spendere significa presentare ciò che la serratura chiede, di norma una firma
che prova il possesso della chiave giusta. I tipi di serratura sono pochi,
nati uno dopo l'altro lungo la storia del protocollo, e ciascuno risponde a
modo suo alla stessa domanda: **quanto si vede, da fuori, di ciò che chiude la
moneta**. Alcune serrature mettono la chiave pubblica in chiaro sull'output dal
primo istante; altre ne espongono soltanto l'impronta, e la chiave si vede solo
quando la moneta si muove. Qui si guarda a questo: che forma hanno le
serrature, come sono cambiate, cosa distingue l'una dall'altra.
Questo testo si tiene sul piano d'insieme: la cronologia dei tipi, le tabelle
che li mettono in fila, e la forma in byte di ciascuna serratura. Come si
costruisce e si firma davvero un'intera transazione, il suo formato pezzo per
pezzo, è materia di un secondo passaggio, più tecnico. Chi arriva dai pezzi sul
[quantum computing](/it/bitcoin-e-quantum-computing/) e sui suoi [numeri
misurati](/it/bitcoin-e-quantum-computing-dati-luglio-2026/) trova qui il
meccanismo che quelli danno per noto.
## Serratura e indirizzo non sono la stessa cosa
Conviene chiarirlo subito, perché è l'equivoco più comune. La serratura è lo
scriptPubKey, lo script che sta sull'output e ne fissa le condizioni di spesa.
L'**indirizzo** non è la serratura: è solo un modo compatto di scriverla, una
codifica pensata per stare in un messaggio, con un controllo di integrità che
evita di sbagliare una cifra. Da un indirizzo il portafoglio ricava la
serratura da mettere sull'output; sul registro, di indirizzi non ce ne sono,
ci sono script.
Tenere separate le due cose spiega diverse asimmetrie. Alcuni tipi di serratura
non hanno un indirizzo proprio (i più antichi). Codifiche diverse convivono
nello stesso momento, una per famiglia di serrature. E lo stesso identico
indirizzo, riusato per ricevere due volte, produce due output con la stessa
serratura: quando si spende il primo, la chiave diventa pubblica, e il secondo
si ritrova scoperto senza che nessuno l'abbia toccato.
## Il linguaggio delle serrature
Una serratura è un programma, e il linguaggio in cui è scritta si chiama
Script: una sequenza di istruzioni, gli **op** (opcode), eseguite su una pila
di dati. Chi spende presenta i propri dati di sblocco, di norma una firma e
una chiave, a volte uno script intero; i nodi mettono quei dati sulla pila e
poi eseguono la serratura: se alla fine sulla pila resta «vero», la spesa è
valida. Tutto qui: non c'è un guardiano che decide, c'è un programma che
ogni nodo del mondo riesegue e che dà a tutti lo stesso esito.
Quando a un nodo arriva un blocco, i controlli si fanno in un ordine preciso,
dal più economico al più caro: prima l'intestazione e il proof-of-work, che
costano un hash; poi la forma del blocco; poi, per ogni transazione, che le
monete spese esistano davvero e non risultino già spese; e soltanto alla fine
si eseguono le serrature, cioè si verificano le firme. È il passaggio che costa
di più, ed è l'ultimo apposta: chi manda spazzatura viene fermato prima di
farla pagare a tutti. Per molte transazioni, poi, quel lavoro il nodo l'ha già
fatto quando le ha viste passare, e se lo ricorda. Le serrature di questa voce
sono quell'ultimo anello.
Le operazioni permesse sono poche e concrete: mettere dati sulla pila,
duplicarli e confrontarli (`OP_DUP`, `OP_EQUAL`), calcolarne l'impronta
(`OP_HASH160`, `OP_SHA256`), verificare firme (`OP_CHECKSIG`,
`OP_CHECKMULTISIG`), aprire un bivio (`OP_IF`), vincolare la spesa al tempo
(`OP_CHECKLOCKTIMEVERIFY`, `OP_CHECKSEQUENCEVERIFY`). Mancano di proposito i
cicli: uno script non può ripetersi, quindi ogni verifica termina di sicuro e
costa un tempo prevedibile. Nel 2010, dopo la scoperta di alcune falle, una
parte degli op fu disabilitata (`OP_CAT` e altri): da allora il linguaggio è
più stretto di com'era nato.
Le famiglie, in tabella; le serrature della cronologia stanno tutte nelle prime
cinque righe.
| famiglia | op principali | a che servono |
|---|---|---|
| costanti e push | `OP_0`…`OP_16`, i push diretti | mettere dati sulla pila (firme, chiavi, impronte) |
| pila | `OP_DUP`, `OP_DROP`, `OP_SWAP` | duplicare e riordinare ciò che c'è sopra |
| confronto | `OP_EQUAL`, `OP_EQUALVERIFY` | confrontare due elementi in cima |
| hash | `OP_HASH160`, `OP_SHA256` | calcolare impronte |
| firme | `OP_CHECKSIG`, `OP_CHECKMULTISIG` (in tapscript: `OP_CHECKSIGADD`) | verificare firme contro chiavi |
| flusso | `OP_IF` / `OP_ELSE` / `OP_ENDIF`, `OP_VERIFY`, `OP_RETURN` | bivi, arresti, output dichiaratamente inspendibili |
| tempo | `OP_CHECKLOCKTIMEVERIFY`, `OP_CHECKSEQUENCEVERIFY` | vincolare la spesa a un'altezza o a un'attesa |
| aritmetica (ridotta) | `OP_ADD`, `OP_SUB`, i confronti numerici | piccoli conti su numeri piccoli |
| disabilitati (2010) | `OP_CAT`, `OP_MUL`, `OP_LSHIFT`… | rimossi dopo le falle; qualcuno oggi si ridiscute |
Conviene vederlo su una serratura vera. Questa è la P2PKH, la serratura degli
indirizzi che iniziano per `1`, presa dal più celebre dei pagamenti (i
diecimila bitcoin della pizza, 2010), byte per byte:
La serratura P2PKH byte per byte: lo scriptPubKey dell'output 0 (10.000 BTC) di una transazione reale, l'output da 10.000 BTC della transazione della pizza, blocco 57043 (2010). Caselle: blu = op, giallo = dati, grigio = lunghezza; i numeri sopra le caselle sono i loro byte. Verificabile con getrawtransaction a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d.
Ogni casella è un byte, o un gruppo di byte, col suo valore esadecimale dentro
e il conto dei byte sopra. Le caselle blu sono **op**, le istruzioni; quelle
gialle sono **dati**; quelle grigie sono un tipo speciale di byte, il **push**,
e vale la pena fermarcisi perché ritorna in ogni serratura. Un byte di push non
ordina nulla: dichiara «i prossimi N byte sono dati, mettili sulla pila così
come sono». Il `14` grigio, per esempio, è il numero venti, e annuncia che
seguono venti byte, l'impronta della chiave. È così che lo script separa i dati
dalle istruzioni senza ambiguità: un valore non si confonde mai con un comando,
perché a introdurlo c'è sempre il suo push.
Prima di seguire un'esecuzione conviene mettere in chiaro chi porta che cosa,
perché non tutto arriva da chi spende.
La serratura il nodo ce l'ha già. Non gliela manda chi spende: sta scritta
sull'output di una transazione precedente, di norma confermata tempo prima,
e ogni nodo la conserva nell'UTXO set, l'insieme di tutte le monete
spendibili in quel momento. La transazione di spesa si limita a puntarla,
dicendo quale transazione passata e quale dei suoi output. Non potrebbe
essere altrimenti: se la serratura la portasse chi spende, ciascuno
porterebbe la propria.
Da fuori arriva una cosa sola, i dati di sblocco: viaggiano dentro la
transazione di spesa, nello scriptSig, e da SegWit in poi in una zona separata
della transazione, il witness.
E il messaggio, il testo su cui la firma viene verificata, non viaggia affatto.
È la transazione di spesa ridotta a un numero secondo regole fisse, che
lasciano fuori i dati di sblocco: se li comprendessero, la firma dovrebbe
coprire sé stessa. Chi firma lo calcola prima di firmare, il nodo lo ricalcola
per conto suo su quello che ha ricevuto, e i due numeri coincidono solo se la
transazione è rimasta quella. Nessuno lo trasmette perché nessuno ha bisogno
di riceverlo: la transazione ce l'hanno entrambi.
Resta fuori da questo giro una cosa sola, la chiave privata, che non compare né
nella serratura, né nei dati di sblocco, né nel messaggio.
Quanto chi spende debba portare dipende poi dal tipo di serratura: dove c'è
un'impronta la chiave va esibita, perché il nodo non ce l'ha; dove c'è già la
chiave, basta la firma.
Gli op non si «accendono» a chiamata: si scorre lo script da sinistra a
destra, un elemento alla volta, e ogni op agisce quando arriva il suo turno,
su ciò che i passi precedenti hanno lasciato sulla pila. Prima però si
impilano i dati di sblocco: chi spende premette la propria firma e la propria
chiave, e solo dopo si esegue la serratura. Sblocco prima, serratura poi,
sulla stessa pila. Nella P2PKH qui sopra l'ordine è questo:
1. i dati di sblocco vanno sulla pila: la firma e la chiave pubblica;
2. `OP_DUP` duplica la chiave, `OP_HASH160` ne calcola l'impronta;
3. `OP_EQUALVERIFY` confronta quell'impronta con i venti byte scritti nella
serratura: se non coincidono, l'esecuzione si ferma qui e la spesa è nulla;
4. `OP_CHECKSIG` verifica la firma contro la chiave: se regge, lascia «vero»
sulla pila e la spesa è valida.
Sono i quattro op e l'unico push che si leggono nella striscia, eseguiti in
quell'ordine.
Vale la pena guardare da vicino il passo 4, perché è lì che il meccanismo si
chiude. `OP_CHECKSIG` non mette a confronto due valori: ricostruisce il testo
che la firma doveva coprire, cioè la transazione ridotta a un numero secondo
regole fisse, e poi verifica che fra quel numero, la chiave pubblica e i due
numeri della firma valga una certa relazione. La relazione torna solo se chi ha
firmato possedeva la chiave privata, e torna solo per quella transazione: la
stessa firma, spostata su un'altra, non tornerebbe. Quali parti della
transazione entrino nel conto lo dichiara la firma stessa, con un byte in coda.
Quello che il controllo accerta si ferma però lì: che chi ha firmato possedeva
la chiave in quel momento, e che acconsentiva a quella spesa. Non chi fosse, non
se la chiave fosse solo sua, non se gliel'avessero sottratta. Su Bitcoin la
proprietà è definita così, come possesso della chiave, e la serratura non ha
modo di guardare oltre.
C'è poi un limite dello stesso genere: `OP_CHECKSIG` giudica la firma che
riceve, non il modo in cui è stata prodotta. Anche quel lato ha condizioni sue,
tutte dalla parte di chi firma: la più delicata riguarda il
[**nonce**](/it/nonce-firma/), il numero che ogni firma consuma una volta
sola e che non deve ripetersi mai.
Resta una domanda sul linguaggio, e regge tutto il seguito: se permette
combinazioni a piacere, perché i tipi di serratura sono una manciata? Perché
i nodi, quando decidono se rilanciare una transazione, riconoscono poche
forme fisse, gli script **standard**: fuori da quelle forme una serratura può
essere valida per le regole del consenso ma non viaggia bene sulla rete. I
tipi della tabella che segue sono precisamente queste forme, e la loro
cronologia è la storia di come la lista si è allungata. Col tempo è cambiato
anche *dove* stanno i dati di sblocco (dentro il corpo della transazione,
poi in una sezione a parte: se ne parla alla voce SegWit), ma il meccanismo
della pila è rimasto quello.
## Una manciata di tipi
Prima della cronologia, il colpo d'occhio. Questa tabella si consulta, non si
studia: conviene tornarci mentre si leggono le sezioni che seguono.
| serratura | forma (schematica) | indirizzo | quando compare la chiave |
|---|---|---|---|
| **P2PK** | ` OP_CHECKSIG` | nessuno | subito: la chiave è già sull'output |
| **P2PKH** | `OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG` | `1…` | alla prima spesa |
| **bare multisig** | `m n OP_CHECKMULTISIG` | nessuno | subito: le chiavi sono sull'output |
| **P2SH** | `OP_HASH160 OP_EQUAL` | `3…` | alla spesa, quando si rivela lo script |
| **P2WPKH** | `OP_0 ` (witness v0) | `bc1q…` (corto) | alla prima spesa |
| **P2WSH** | `OP_0 ` (witness v0) | `bc1q…` (lungo) | alla spesa, quando si rivela lo script |
| **P2TR** | `OP_1 ` (witness v1) | `bc1p…` | subito: la chiave (con tweak) è sull'output; l'albero di script solo se usato |
Le sigle che iniziano per `P2` si leggono tutte allo stesso modo: *pay to*,
«paga a», e il resto dice a che cosa si paga, una chiave pubblica (PK),
l'impronta di una chiave (PKH), l'impronta di uno script (SH), con la `W` di
*witness* per le forme segwit e la `TR` di Taproot.
Fuori tabella restano gli script non standard e le forme che non sono
serrature da spendere (per esempio gli output `OP_RETURN`, che portano dati e
si sa già che nessuno riscuoterà). La distinzione utile è tra chi mette la
chiave **in vista per costruzione** (P2PK, bare multisig, e in parte P2TR) e
chi la tiene **dietro un'impronta** finché non arriva la spesa (le famiglie con
hash: P2PKH, P2SH, P2WPKH, P2WSH).
## La cronologia: come sono nate, una dopo l'altra
### P2PK, le origini (2009)
La prima serratura è anche la più diretta: la chiave pubblica in chiaro sullo
script, seguita dall'ordine di verificare la firma. È la forma degli output di
conio dei primi tempi e del primo pagamento mai fatto, da Satoshi a Hal
Finney (blocco 170, gennaio 2009). Non ha un indirizzo: si maneggiava la
chiave direttamente. Semplice, e per questo esposta: la chiave sta sul registro
dal primo momento, senza alcuna schermatura.
La serratura P2PK byte per byte: lo scriptPubKey dell'output 0 (10 BTC) di una transazione reale, il primo pagamento della storia (Satoshi → Hal Finney), blocco 170 (2009). Caselle: blu = op, giallo = dati, grigio = lunghezza; i numeri sopra le caselle sono i loro byte. Verificabile con getrawtransaction f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16.
### P2PKH, l'indirizzo classico (2009)
Poco dopo arriva la forma che ha retto per anni come standard di fatto, quella
degli indirizzi che iniziano per `1`. La serratura non porta la chiave ma la
sua **impronta**, un hash di venti byte; la chiave vera si mostra solo al
momento della spesa, dentro i dati che sbloccano l'output. Due vantaggi: un
indirizzo più corto da scambiare, e una chiave che resta coperta fintanto che
la moneta non si muove. Da qui in poi «indirizzo» diventa sinonimo, nell'uso
comune, di questa impronta codificata. La sua striscia di byte è quella della
sezione sul linguaggio: quattro op e un push attorno all'impronta di venti
byte.
### bare multisig, la firma multipla grezza (dal principio, standard nel 2011)
L'operazione per chiedere più firme, `m` firme valide su `n` chiavi elencate,
sta nel protocollo fin dall'inizio; come forma riconosciuta dalle regole di
inoltro arriva nel 2011 (BIP 11). Nella versione «grezza» le chiavi stanno per
intero sullo script dell'output, in chiaro. Funziona, ma occupa spazio ed
espone le chiavi per costruzione; con l'arrivo di una soluzione più pulita
(sotto) cade in disuso come forma diretta, e resta soprattutto dentro altre
serrature.
La serratura bare multisig byte per byte: lo scriptPubKey dell'output 0 (0,01 BTC) di una transazione reale, 1-di-2: due chiavi in chiaro, una firma basta, blocco 164467 (2012). Caselle: blu = op, giallo = dati, grigio = lunghezza; i numeri sopra le caselle sono i loro byte. Verificabile con getrawtransaction 60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1.
Nella striscia si leggono le due chiavi intere, una dopo l'altra, ciascuna
introdotta dal suo push. A far da cornice ci sono i due numeri della regola:
`OP_1` in testa, le firme che servono, e `OP_2` in coda, le chiavi elencate,
prima di `OP_CHECKMULTISIG`. Nessuna impronta, tutto in chiaro.
### P2SH, l'impegno a uno script (2012, BIP 16)
Il passo che generalizza l'idea dell'impronta. Invece di impegnare una singola
chiave, la serratura impegna l'hash di uno **script** intero, il redeem script,
che al momento della spesa va rivelato e soddisfatto. Nascono gli indirizzi che
iniziano per `3`. Con P2SH la firma multipla diventa comoda: chi paga vede solo
un indirizzo corto, e la complessità (quante chiavi, quali condizioni) resta
nascosta dietro l'impronta finché non serve. Da qui il multisig si usa quasi
sempre così, dentro P2SH, e non più grezzo.
La serratura P2SH byte per byte: lo scriptPubKey dell'output 0 (0,0099 BTC) di una transazione reale, pagamento all'indirizzo 3P14159…, blocco 272295 (2013). Caselle: blu = op, giallo = dati, grigio = lunghezza; i numeri sopra le caselle sono i loro byte. Verificabile con getrawtransaction 40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8.
Ventitré byte in tutto: `OP_HASH160`, i venti byte dell'impronta dello
script, `OP_EQUAL`. Che dietro ci sia una singola chiave o un multisig
complicato, da fuori la serratura è identica.
### SegWit v0, il witness separato (2017, BIP 141/143)
Un cambiamento strutturale. I dati che sbloccano l'output (firma e chiave, o
script e firme) escono dal corpo della transazione e finiscono in una sezione
a parte, il **witness**. Due tipi nuovi ricalcano i precedenti:
**P2WPKH** è il corrispettivo di P2PKH (impronta di una chiave), **P2WSH**
quello di P2SH (impronta di uno script), con un hash più robusto per gli
script. Cambia anche la codifica dell'indirizzo, che passa a `bc1q`. La
separazione del witness risolve un difetto storico (la possibilità di
alterare l'identificativo di una transazione prima della conferma) e apre la
strada ai livelli superiori come Lightning.
La serratura P2WPKH byte per byte: lo scriptPubKey dell'output 0 (0,001943 BTC) di una transazione reale, nel blocco di attivazione di SegWit, blocco 481824 (2017). Caselle: blu = op, giallo = dati, grigio = lunghezza; i numeri sopra le caselle sono i loro byte. Verificabile con getrawtransaction dfcec48bb8491856c353306ab5febeb7e99e4d783eedf3de98f3ee0812b92bad.La serratura P2WSH byte per byte: lo scriptPubKey dell'output 0 (0,005 BTC) di una transazione reale, nel blocco di attivazione di SegWit, blocco 481824 (2017). Caselle: blu = op, giallo = dati, grigio = lunghezza; i numeri sopra le caselle sono i loro byte. Verificabile con getrawtransaction 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6.
Le due strisce dicono la semplificazione a colpo d'occhio: `OP_0` seguito da
un push e da un'impronta, e nient'altro. Venti byte per la chiave (P2WPKH),
trentadue per lo script (P2WSH): l'unica differenza visibile tra le due è la
lunghezza dell'impronta.
Per la transizione esiste una forma ibrida, il segwit **annidato** dentro
P2SH: mantiene un indirizzo `3` compatibile con i portafogli vecchi, ma dentro
lavora come segwit. È un ponte, non un tipo nuovo.
### Taproot, la chiave e l'albero (2021, BIP 340/341/342)
L'ultima famiglia attiva. Introduce un tipo di firma diverso, più pulito da
verificare e da combinare (Schnorr), e una serratura, **P2TR**, che tiene
insieme due vie di spesa: una **chiave interna**, per il caso semplice e
comune, e un **albero di script** nascosto, che resta invisibile finché non
lo si usa. Chi spende per la via della chiave mostra pochissimo, e le spese
complesse diventano indistinguibili da quelle semplici. Indirizzi che iniziano
per `bc1p`, con una codifica rivista rispetto a segwit v0. Sul fronte
dell'esposizione, Taproot mette la chiave in vista per costruzione, come P2PK:
sull'output non c'è un'impronta ma la chiave stessa, ritoccata da un piccolo
aggiustamento (il tweak) che impegna l'albero di script. È un tratto che i
pezzi sul quantum computing pesano nei loro conti.
La serratura P2TR byte per byte: lo scriptPubKey dell'output 0 (0,0003 BTC) di una transazione reale, nel blocco di attivazione di Taproot, blocco 709632 (2021). Caselle: blu = op, giallo = dati, grigio = lunghezza; i numeri sopra le caselle sono i loro byte. Verificabile con getrawtransaction 777c998695de4b7ecec54c058c73b2cab71184cf1655840935cd9388923dc288.
La striscia somiglia a quella di P2WSH, `OP_1` al posto di `OP_0` e trentadue
byte, ma quei trentadue byte non sono un'impronta: sono la chiave, in chiaro.
### Le proposte quantum-resistant (in discussione)
La riga aperta. Di fronte alla prospettiva di una macchina in grado di ricavare
la chiave privata da quella pubblica, sono allo studio serrature di nuovo tipo,
basate su firme che si ritengono resistenti a quel genere di attacco (la bozza
più avanti nel percorso è BIP 360, oggi *Pay-to-Merkle-Root*), insieme a
proposte per ritirare nel tempo le firme legacy (BIP 361). Sono proposte, non
parti attive del protocollo. Il perché di tutto questo, e quanto peserebbe, sta
nel pezzo sul [quantum computing](/it/bitcoin-e-quantum-computing/); qui basta
segnarne il posto nella fila: il prossimo gradino, se e quando arriverà.
## Le codifiche degli indirizzi
Alla cronologia delle serrature corre in parallelo quella delle codifiche, il
modo di scrivere un indirizzo. Sono poche e si accompagnano alle famiglie.
| codifica | serrature | indirizzi | note |
|---|---|---|---|
| **Base58Check** | P2PKH, P2SH | `1…`, `3…` | alfabeto senza caratteri ambigui, checksum in coda |
| **Bech32** | P2WPKH, P2WSH (witness v0) | `bc1q…` | un solo registro di caratteri, comoda nei codici QR, rilevamento degli errori garantito dal checksum |
| **Bech32m** | P2TR (witness v1) | `bc1p…` | variante di Bech32 corretta per le versioni di witness dalla 1 in poi |
## Le coppie che si confondono
Alcune distinzioni che, tenute ferme, sciolgono gran parte della confusione:
- **serratura ≠ indirizzo**: lo scriptPubKey sull'output è la serratura;
l'indirizzo è solo una sua codifica leggibile;
- **chiave ≠ impronta della chiave**: i tipi con hash (P2PKH, P2WPKH) non
mostrano la chiave finché non si spende, quelli senza (P2PK, la via chiave di
P2TR) la mostrano subito;
- **nonce di firma ≠ nonce del blocco**: la stessa parola sta in due posti che
non c'entrano niente fra loro; quello del mining è pubblico e si cerca a
tentativi, quello di firma è segreto e non va cercato affatto;
- **nonce ripetuto ≠ chiave debole**: la chiave può essere perfetta, è la firma
ad averla consegnata;
- **segwit annidato ≠ segwit nativo**: un indirizzo `3` può essere un P2SH
qualunque oppure un segwit avvolto in P2SH per compatibilità; da fuori si
somigliano, dentro no;
- **valido ≠ standard**: il linguaggio accetta molte più forme di quante i
nodi rilancino; i tipi di questa voce sono le forme standard, non tutto il
possibile.
## In breve
Le serrature di Bitcoin sono poche e si leggono in fila storica: la chiave nuda
delle origini (P2PK), l'impronta di una chiave che diventa lo standard (P2PKH),
le chiavi multiple messe in chiaro (bare multisig), l'impegno a uno script
intero (P2SH), la separazione del witness (P2WPKH e P2WSH), l'unione di
chiave e albero di script (P2TR), e la riga ancora aperta delle proposte
pensate per un mondo con computer quantistici. Il movimento non è una linea
sola: ciò che serve a spendere prima sta in chiaro sull'output, poi arretra
dietro un'impronta e si mostra solo alla spesa, e con Taproot torna in vista,
per ragioni che con la riservatezza della chiave non c'entrano. Sotto ogni tipo
resta la stessa domanda pratica: se e quando la chiave pubblica finisce in
chiaro sul registro.
## Riferimenti
- BIP 11, *M-of-N Standard Transactions*: [github.com/bitcoin/bips/blob/master/bip-0011.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki)
- BIP 16, *Pay to Script Hash*: [github.com/bitcoin/bips/blob/master/bip-0016.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki)
- BIP 141, *Segregated Witness (Consensus layer)*: [github.com/bitcoin/bips/blob/master/bip-0141.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)
- BIP 143, *Transaction Signature Verification for Version 0 Witness Program*: [github.com/bitcoin/bips/blob/master/bip-0143.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki)
- BIP 173, *Base32 address format for native v0-16 witness outputs* (Bech32): [github.com/bitcoin/bips/blob/master/bip-0173.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)
- BIP 340, *Schnorr Signatures*: [github.com/bitcoin/bips/blob/master/bip-0340.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki);
BIP 341, *Taproot*: [github.com/bitcoin/bips/blob/master/bip-0341.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki);
BIP 342, *Tapscript*: [github.com/bitcoin/bips/blob/master/bip-0342.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)
- BIP 350, *Bech32m format for v1+ witness addresses*: [github.com/bitcoin/bips/blob/master/bip-0350.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)
- BIP 360, *Pay-to-Merkle-Root (P2MR)* (bozza): [github.com/bitcoin/bips/blob/master/bip-0360.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki);
BIP 361, *Post Quantum Migration and Legacy Signature Sunset* (bozza): [github.com/bitcoin/bips/blob/master/bip-0361.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki).
Il contesto sta nel pezzo [«Bitcoin e quantum computing»](/it/bitcoin-e-quantum-computing/).
- Il linguaggio Script e l'elenco degli op: la pagina [Script del wiki di Bitcoin](https://en.bitcoin.it/wiki/Script)
e, per la semantica di esecuzione, il sorgente di Bitcoin Core,
[`src/script/interpreter.cpp`](https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp)
- A. M. Antonopoulos, D. A. Harding, *Mastering Bitcoin* (3ª ed., O'Reilly 2023),
capitoli su transazioni, Script e indirizzi; il testo è anche in un
[repo pubblico](https://github.com/bitcoinbook/bitcoinbook)
- Le pagine tecniche di [learn me a bitcoin](https://learnmeabitcoin.com/technical/script/)
(G. Walker): percorsi byte per byte su script, transazioni e codifiche
- I numeri di quante monete hanno la chiave già in vista stanno nel pezzo dei
[dati](/it/bitcoin-e-quantum-computing-dati-luglio-2026/).