Protocollo · Script
Bitcoin Covenant
Un covenant (patto, vincolo) è un costrutto che limita come un UTXO può essere speso in futuro — non solo chi può spenderlo, ma dove e come i fondi possono andare nella transazione successiva. Attualmente Bitcoin non supporta covenant nativi. Il dibattito su come (e se) aggiungerli è uno dei più accesi nel protocollo dal 2021.
Come funziona un covenant
Oggi Bitcoin Script permette di specificare le condizioni di spesa di un UTXO: firma della chiave corretta, timelock, multisig. Ma lo script non può ispezionare la transazione di spesa stessa: non sa dove vanno i fondi, quale importo, quanti output ci sono.
Un covenant aggiunge questa capacità: lo script di un UTXO può vincolare la struttura della transazione futura. Esempi:
I fondi possono andare SOLO all'indirizzo X (whitelist di destinazione).
L'output di spesa deve avere esattamente N sat di commissione.
Dopo N blocchi, i fondi possono andare a un indirizzo di recovery — altrimenti solo all'indirizzo originale.
Un vault: qualunque spesa deve aspettare 144 blocchi; in quell'intervallo può essere annullata.
Le principali proposte
| Proposta | BIP | Meccanismo |
|---|---|---|
| OP_CTV | BIP 119 | CheckTemplateVerify: vincola l'hash della transazione futura (output, locktime, nSequence). Semplice e conservativo. |
| OP_VAULT | BIP 345 | Vault nativi con periodo di cooldown e annullamento. Costruito sopra OP_CTV. |
| APO / ANYPREVOUT | BIP 118 | Firma che non vincola l'UTXO di input. Permette re-binding: base per Eltoo/LN simmetrico. |
| OP_CHECKSIGFROMSTACK | CSFS | Verifica firme su dati arbitrari nello stack. Covenant generico, flessibile ma complesso. |
| LNHANCE | — | Bundle: OP_CTV + OP_CSFS + OP_INTERNALKEY. Abilita vault, PTLCs migliorati e canali LN avanzati. |
| CAT | BIP 347 | Ri-abilitazione di OP_CAT: concatena elementi dello stack. Molto flessibile, anche controverso. |
Perché servono: i casi d'uso principali
Vault Bitcoin
Un vault con covenant funziona così: spendere l'UTXO richiede prima una transazione di "sblocco" — poi un cooldown di 144-1000 blocchi prima che i fondi arrivino alla destinazione.
In quella finestra, una chiave di recupero ("clawback") può annullare il tutto e mandare tutto a cold storage.
Risultato: anche se un attaccante ruba la chiave hot, ha una finestra ristretta — e il proprietario può bloccare la transazione.
Oggi vault simili esistono ma richiedono transazioni pre-firmate complesse. Con OP_VAULT/OP_CTV diventano nativi e più sicuri.
Lightning Network ottimizzato
APO/ANYPREVOUT abilita Eltoo: canali LN con stato simmetrico (non asimmetrico come LN attuale). Elimina la necessità di penalty transactions e la torre di guardia.
OP_CTV e LNHANCE abilitano canali condivisi (channel factories) e batched channel opens — aprire 100 canali in una transazione.
PTLCs (Point Time Lock Contracts) con CSFS: pagamenti LN più privati, eliminano la correlazione di pagamento.
Congestion Control
Con OP_CTV: un exchange può inviare centinaia di pagamenti con una singola transazione on-chain. I destinatari ricevono un covenant che garantisce il loro pagamento, confermabile in un secondo momento.
Riduce drasticamente la pressione sulla mempool durante i picchi.
DeFi su Bitcoin
Covenant più espressivi (CSFS, CAT) permetterebbero smart contract semplici senza sidechain: escrow, DLC (Discrete Log Contracts) più efficienti, stablecoin collateralizzate da BTC.
Questo è uno dei punti più controversi: molti bitcoiner considerano DeFi su L1 indesiderata.
La controversia: perché non è ancora attivato
Il dibattito fondamentale
Bitcoin cambia per consenso degli sviluppatori e dei nodi — non per voto, non per autorità centrale. Un soft fork richiede un accordo ampio che storicamente richiede anni. OP_CTV è proposto dal 2020, ancora senza consenso chiaro al 2026.
Fungibilità e censura
Il rischio più citato: covenant whitelist potrebbero permettere di 'marcare' certi Bitcoin come non spendibili verso destinazioni specifiche. Un UTXO con covenant potrebbe valere meno di uno senza. I critici parlano di rischio per la fungibilità — proprietà fondamentale di una valuta.
Complessità e superficie d'attacco
Ogni opcode aggiunto aumenta la complessità di Bitcoin Script. Più complessità = più superficie per bug. I puristi preferiscono mantenere il protocollo semplice. CAT e CSFS sono particolarmente criticati per questo motivo.
Mancanza di consensus
A differenza di Taproot (attivato nel 2021 con ampio consenso dopo anni di lavoro), le proposte covenant mancano di un accordo tecnico su quale implementare. OP_CTV vs APO vs LNHANCE: ogni gruppo ha la sua soluzione preferita.
Vault sicuri per tutti
I sostenitori, tra cui Jeremy Rubin (OP_CTV) e James O'Beirne (OP_VAULT), argomentano che vault nativi renderebbero self-custody accessibile e sicura per la massa — inclusa la possibilità di recuperare fondi se compromessi.
Scalabilità di Lightning
Eltoo (richiede APO) è considerato da molti sviluppatori LN un miglioramento fondamentale alla gestione dello stato dei canali — più semplice, più robusto. Senza APO, LN mantiene limitazioni architetturali importanti.
Status al 2026
Mavrck Wuille propone ANYPREVOUT (ex NOINPUT). Prima discussione seria su covenant in Bitcoin.
Jeremy Rubin propone BIP 119 (OP_CTV). Controversia immediata sulla fungibilità e sul processo di attivazione.
Taproot attivato (BIP 340/341/342). Aggiunge Schnorr e Tapscript — base per future covenant più efficienti.
James O'Beirne propone OP_VAULT (BIP 345). Dibattito si amplia. Luke Dashjr e altri core developer rimangono scettici.
OP_CAT ri-proposto (BIP 347). Interesse crescente per covenant da sviluppatori DeFi/Ordinals. Diventa più politicamente carico.
LNHANCE bundle proposto: OP_CTV + OP_CSFS + OP_INTERNALKEY. Tenta di unire le proposte. Ancora nessun consensus.
Nessuna delle proposte covenant ha raggiunto consenso per l'attivazione. Il dibattito continua — probabilmente anni prima di una decisione.
Analisi protocollo ogni settimana
Il Report Fides Bitcoin copre sviluppi del protocollo, on-chain e macro — in italiano, ogni lunedì.
Iscriviti gratis →