10 KiB
11.2: Utilizzo di CLTV negli Script
OP_CHECKLOCKTIMEVERIFY (o CLTV) è il complemento naturale di nLockTime. Porta l'idea di bloccare le transazioni per un tempo assoluto o altezza di blocco nel regno degli opcode, permettendo il blocco di singoli UTXO.
⚠️ AVVISO VERSIONE: CLTV è diventato disponibile con Bitcoin Core 0.11.2, ma dovrebbe essere abbastanza ampiamente distribuito a questo punto.
Ricorda nLockTime
Prima di approfondire CLTV, dovremmo prima ricordare come funziona nLockTime.
Come dettagliato in §8.1: Invio di una Transazione con un Locktime, il locktime è abilitato impostando due variabili, nLockTime e nSequence. Il nSequence deve essere impostato a meno di 0xffffffff (di solito: 0xffffffff-1), poi il nLockTime è interpretato come segue:
- Se il
nLockTimeè inferiore a 500 milioni, è interpretato come altezza di blocco. - Se il
nLockTimeè 500 milioni o più, è interpretato come un timestamp UNIX.
Una transazione con nLockTime impostato non può essere spesa (o anche inserita nella blockchain) fino a quando non viene raggiunta l'altezza del blocco o il tempo. Nel frattempo, la transazione può essere annullata spendendo nuovamente uno qualsiasi degli UTXO che compongono la transazione.
Comprendere l'Opcode CLTV
OP_CHECKLOCKTIMEVERIFY funziona nello stesso paradigma delle altezze di blocco assolute o dei tempi UNIX assoluti, ma viene eseguito come parte di uno Script Bitcoin. Legge un argomento, che può essere un'altezza di blocco o un tempo UNIX assoluto. Attraverso una metodologia alquanto complicata, confronta quell'argomento con il tempo corrente. Se è troppo presto, lo script fallisce; se la condizione temporale è stata soddisfatta, lo script continua.
Poiché CLTV è solo parte di uno script (e presumibilmente parte di una transazione P2SH), una transazione CLTV non è tenuta fuori dalla mempool come una transazione nLockTime; non appena viene verificata, entra nella blockchain e i fondi sono considerati spesi. Il trucco è che tutti gli output bloccati con il CLTV non sono disponibili per spendere nuovamente fino a quando il CLTV non lo consente.
Comprendere un Tempo Assoluto CLTV
Ecco come OP_CHECKLOCKTIMEVERIFY sarebbe usato per verificare contro il 24 maggio 2017:
1495652013 OP_CHECKLOCKTIMEVERIFY
Ma di solito lo rappresenteremo in un'astrazione così:
<May24> OP_CHECKLOCKTIMEVERIFY
O cosi:
<AbsoluteTime> OP_CHECKLOCKTIMEVERIFY
Comprendere un'Altezza di Blocco Assoluta CLTV
Ecco come OP_CHECKLOCKTIMEVERIFY verificherebbe contro un'altezza di blocco raggiunta il 24 maggio 2017:
467951 OP_CHECKLOCKTIMEVERIFY
Ma di solito lo astrarremo così:
<AbsoluteBlockHeight> OP_CHECKLOCKTIMEVERIFY
Comprendere Come Funziona Davvero CLTV
La spiegazione sopra è sufficiente per usare e comprendere CLTV. Tuttavia, BIP 65 espone tutti i dettagli.
Uno script di blocco permetterà di spendere nuovamente un UTXO bloccato con un CLTV solo se OP_CHECKLOCKTIMEVERIFY verifica tutte le seguenti condizioni:
- Il campo
nSequencedeve essere impostato a meno di 0xffffffff, di solito 0xffffffff-1 per evitare conflitti con i timelock relativi. - CLTV deve estrarre un operando dallo stack e deve essere 0 o maggiore.
- Sia l'operando dello stack che il valore di
nLockTimedevono essere sopra o sotto i 500 milioni, per rappresentare lo stesso tipo di timelock assoluto. - Il valore di
nLockTimedeve essere maggiore o uguale all'operando dello stack.
Quindi la prima cosa da notare qui è che nLockTime è ancora usato con CLTV. Per essere precisi, è richiesto nella transazione che cerca di spendere nuovamente un UTXO bloccato con CLTV. Ciò significa che non fa parte dei requisiti dello script. È solo il timer usato per rilasciare i fondi, come definito nello script.
Questo è gestito attraverso una comprensione intelligente di come funziona nLockTime: un valore per nLockTime deve sempre essere scelto che sia inferiore o uguale al tempo presente (o altezza del blocco), in modo che la transazione di spesa possa essere inserita nella blockchain. Tuttavia, a causa dei requisiti di CLTV, deve anche essere scelto un valore maggiore o uguale all'operando di CLTV. L'unione di questi due insiemi è NULL fino a quando il tempo presente non corrisponde all'operando di CLTV. Successivamente, può essere scelto qualsiasi valore tra l'operando di CLTV e il tempo presente. Di solito, lo imposteresti semplicemente al tempo presente (o al blocco).
Scrivere uno Script CLTV
OP_CHECKLOCKTIMEVERIFY include un OP_VERIFY, il che significa che interromperà immediatamente lo script se la sua verifica non riesce. Ha un'altra peculiarità: a differenza della maggior parte dei comandi "verify", lascia ciò che sta testando sullo stack (nel caso in cui tu voglia fare altri controlli contro il tempo). Ciò significa che un OP_CHECKLOCKTIMEVERIFY è di solito seguito da un OP_DROP per pulire lo stack.
Il seguente semplice script di blocco potrebbe essere usato per trasformare un output P2PKH in una transazione P2PKH bloccata nel tempo:
<NextYear> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Codificare uno Script CLTV
Ovviamente, come per qualsiasi script Bitcoin complesso, questo script CLTV sarebbe effettivamente codificato in uno script P2SH, come spiegato in §10.1: Comprendere le Basi di P2SH e §10.2: Costruire la Struttura di P2SH.
Supponendo che <NextYear> fosse l'intero "1546288031" (hex little-endian: 0x9f7b2a5c) e <pubKeyHash> fosse "371c20fb2e9899338ce5e99908e64fd30b789313", questo redeemScript sarebbe costruito come:
OP_PUSHDATA (4 bytes) 0x9f7b2a5c OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 OP_PUSHDATA (20 bytes) 0x371c20fb2e9899338ce5e99908e64fd30b789313 OP_EQUALVERIFY OP_CHECKSIG
Che si traduce in hex come:
04 9f7b2a5c b1 75 76 a9 14 371c20fb2e9899338ce5e99908e64fd30b789313 88 ac
Oppure, se preferisci:
$ btcc 0x9f7b2a5c OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 0x371c20fb2e9899338ce5e99908e64fd30b789313 OP_EQUALVERIFY OP_CHECKSIG
049f7b2a5cb17576a914371c20fb2e9899338ce5e99908e64fd30b78931388ac
L'RPC decodescript può verificare che abbiamo fatto tutto correttamente:
{
"asm": "1546288031 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 371c20fb2e9899338ce5e99908e64fd30b789313 OP_EQUALVERIFY OP_CHECKSIG",
"type": "nonstandard",
"p2sh": "2MxANZMPo1b2jGaeKTv9rwcBEiXcXYCc3x9",
"segwit": {
"asm": "0 07e55bf1eaedf43ec52af57b77ad7330506c209a70d17fa2e1853304aa8e4e5b",
"hex": "002007e55bf1eaedf43ec52af57b77ad7330506c209a70d17fa2e1853304aa8e4e5b",
"reqSigs": 1,
"type": "witness_v0_scripthash",
"addresses": [
"tb1qqlj4hu02ah6ra3f274ah0ttnxpgxcgy6wrghlghps5esf25wfedse4yw4w"
],
"p2sh-segwit": "2N4HTwMjVdm38bdaQ5h3X3VktLY74D2qBoK"
}
}
Non mostreremo continuamente come tutti gli Script Bitcoin vengono codificati in transazioni P2SH, ma offriremo invece queste abbreviazioni: quando descriviamo uno script, sarà un redeemScript, che sarebbe normalmente serializzato e hashato in uno script di blocco e serializzato nello script di sblocco; quando mostriamo una procedura di sblocco, sarà il secondo turno di convalida, dopo la conferma dell'hash dello script di blocco.
Spendere un UTXO CLTV
Per spendere un UTXO bloccato con un CLTV, è necessario impostare nLockTime sulla nuova transazione. Di solito, vuoi solo impostarlo al tempo presente o al blocco presente, come appropriato. Finché il tempo CLTV o l'altezza del blocco è nel passato, e finché fornisci tutti gli altri dati richiesti dallo script di sblocco, sarai in grado di elaborare l'UTXO.
Nel caso dell'esempio sopra, il seguente script di sblocco sarebbe sufficiente, a condizione che nLockTime fosse impostato a un momento successivo alla data <NextYear>, e a condizione che fosse effettivamente almeno <NextYear>:
<signature> <pubKey>
Eseguire uno Script CLTV
Per eseguire lo Script, dovresti prima concatenare gli script di sblocco e blocco:
Script: <signature> <pubKey> <NextYear> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Stack: [ ]
I tre costanti verrebbero spinti nello stack:
Script: OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Stack: [ <signature> <pubKey> <NextYear> ]
Poi, OP_CHECKLOCKTIMEVERIFY viene eseguito. Trova qualcosa nello stack e verifica che nSequence non sia 0xffffffff. Infine, confronta <NextYear> con nLockTime. Se sono entrambi dello stesso tipo di rappresentazione e se nLockTime ≥ <NextYear>, allora viene elaborato con successo (altrimenti, termina lo script):
Script: OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Running: <NextYear> OP_CHECKLOCKTIMEVERIFY
Stack: [ <signature> <pubKey> <NextYear> ]
Poi, OP_DROP elimina quel <NextYear> rimasto:
Script: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Running: <NextYear> OP_DROP
Stack: [ <signature> <pubKey> ]
FInfine, il resto dello script viene eseguito, che è un controllo normale di una firma e una chiave pubblica.
Riepilogo: Utilizzo di CLTV negli Script
OP_CHECKLOCKTIMEVERIFY è un semplice opcode che guarda un singolo argomento, lo interpreta come un'altezza di blocco o un timestamp UNIX, e permette solo che il suo UTXO venga sbloccato se quell'altezza di blocco o timestamp UNIX è nel passato. Impostare nLockTime sulla transazione di spesa è ciò che permette a Bitcoin di fare questo calcolo.
🔥 Qual è il Potere di CLTV? Hai già visto che i semplici locktime erano una delle basi dei Contratti Intelligenti. CLTV fa il passo successivo. Ora puoi sia garantire che un UTXO non possa essere speso prima di un certo momento sia garantire che non venga speso diversamente. Nella sua forma più semplice, questo potrebbe essere usato per creare un trust che qualcuno potrebbe accedere solo quando raggiunge i 18 anni o un fondo pensione che potrebbe essere accessibile solo quando compie 50 anni. Tuttavia, il suo vero potere si manifesta quando combinato con i condizionali, dove il CLTV si attiva solo in determinate situazioni.
Cosa Succede Dopo?
Continua a "Potenziare Timelock" col Capitolo 11.3: Usare CSV negli Scripts.