OP_CHECKLOCKTIMEVERIFY

Un blocco temporale scritto nella moneta invece che nella transazione che la spende. Peter Todd lo ha specificato nel BIP65, dove ha preso il posto del vecchio opcode no-op NOP2, e la regola è applicata dal blocco 388.381 di dicembre 2015. Se hai mai impostato un piano di eredità o un percorso di recupero, questo opcode è ciò che tiene chiusa la porta.

Come funziona

OP_CHECKLOCKTIMEVERIFY legge un numero dallo stack dello script, lo confronta con il campo locktime della transazione che cerca di spendere la moneta e interrompe l'intero script se la spesa è anticipata.

Il BIP65 elenca cinque modi in cui il controllo fallisce: lo stack è vuoto, l'elemento in cima è negativo, l'elemento e il locktime della transazione non concordano su se stanno contando blocchi o contando secondi, l'elemento è maggiore del locktime della transazione, oppure il numero di sequenza dell'input è impostato a 0xffffffff. Quest'ultima condizione chiude una falla evidente. Un locktime è del tutto ignorato quando ogni input è contrassegnato come finale, quindi senza di essa chi spende potrebbe semplicemente disattivare la scadenza e portarsi via il denaro.

Due dettagli sorprendono chi legge per la prima volta uno script di questo tipo. L'opcode non consuma il numero che controlla, quindi gli script reali lo fanno seguire da OP_DROP per riordinare lo stack. E accetta un operando di cinque byte invece dei quattro usuali, perché il valore più grande con cui può doversi confrontare è 2**32-1, l'intera gamma del campo che sta controllando.

La meccanica del soft fork è stata quella ordinaria. Ridefinire un no-op è invisibile al software che non è stato aggiornato: un nodo vecchio esegue l'opcode, non fa nulla e accetta comunque il blocco. L'attivazione ha usato le soglie di segnalazione dei miner dell'epoca, 750 blocchi su 1.000 per iniziare ad applicare la regola e 950 su 1.000 per renderla obbligatoria.

Dove lo vedi

OP_CHECKLOCKTIMEVERIFY compare ovunque il denaro debba restare fermo fino all'arrivo di una data.

I wallet per l'eredità e il recupero sono il caso più chiaro. Un descriptor può dire che la tua chiave spende in qualsiasi momento mentre una chiave di backup spende solo dopo un'altezza indicata, il che dà a un erede un percorso che non richiede la collaborazione di nessuno né un avvocato che custodisca una busta sigillata. Miniscript lo scrive come frammento after(), e i wallet che lo gestiscono ti mostrano l'altezza in linguaggio chiaro invece che in script grezzo.

Lightning lo usa per la scadenza assoluta di un pagamento instradato. Una fattura BOLT11 porta un delta di scadenza finale, 18 blocchi per impostazione predefinita, e i contratti con hash lungo il percorso sono impilati sopra quella cifra in modo che ogni salto possa recuperare i propri fondi in un ordine fisso se il pagamento non si completa mai.

Il deposito a garanzia e i rimborsi senza fiducia seguono la stessa forma: paga ora in uno script e, se la controparte non firma mai, riprenditi il denaro una volta passata la scadenza. L'opcode è anche la risposta onesta a chiunque venda una "cassaforte con blocco temporale" come prodotto, perché questo è tutto ciò che un simile prodotto può essere.

OP_CHECKLOCKTIMEVERIFY vs OP_CHECKSEQUENCEVERIFY

OP_CHECKLOCKTIMEVERIFY indica un momento; OP_CHECKSEQUENCEVERIFY indica una durata. Uno dice "non prima di dicembre", l'altro dice "non prima di 144 blocchi dopo che questa specifica moneta si è confermata", e solo il secondo avvia il suo orologio quando la moneta arriva. Il BIP112 ha definito la forma relativa, che si è attivata al blocco 419.328 di luglio 2016, circa sette mesi dopo la sua controparte assoluta. I protocolli di contratto usano entrambi, spesso in un solo script: una scadenza assoluta per delimitare l'intero accordo e un ritardo relativo per garantire a una parte una finestra in cui reagire.