Glossario / Protocollo e aggiornamenti
OP_CHECKSEQUENCEVERIFY
Noto anche come CSV, BIP112.
- Che cos'è OP_CHECKSEQUENCEVERIFY?
- OP_CHECKSEQUENCEVERIFY blocca una moneta per un intervallo di tempo misurato dalla sua stessa conferma, facendo fallire qualsiasi spesa il cui input non abbia atteso abbastanza a lungo.
Specificato nel BIP-112.
L'opcode legge un numero dallo stack e lo confronta con il campo sequence dell'input speso, così il conteggio parte quando la moneta arriva in un blocco, non a una data di calendario. Il BIP-112 lo ha definito e la rete ha iniziato ad applicarlo al blocco 419.328 il 4 luglio 2016. Ogni canale Lightning che apri dipende da esso.
Come funziona
L'opcode 178 era in precedenza OP_NOP3 e non faceva nulla, ed è così che la regola è arrivata alla rete come soft fork anziché come divisione della catena.
Il controllo avviene su tre input: il numero sullo stack, il campo sequence dell'input speso e la versione della transazione. È richiesta la versione 2 o superiore, perché le regole del timelock relativo del BIP-68 si applicano solo da quella versione in poi. Se il bit più alto di uno dei due valori è impostato, il timelock è disattivato e l'opcode rinuncia. Altrimenti i due devono concordare sull'unità e il valore sullo stack non deve superare il campo sequence.
Le unità sono di due tipi e non si possono mescolare in un unico confronto. Se un determinato flag è azzerato, il numero conta blocchi; se è impostato, il numero conta intervalli di 512 secondi. In entrambi i casi sono disponibili sedici bit, quindi il tetto è di 65.535 blocchi, circa 455 giorni, oppure lo stesso numero di intervalli di 512 secondi, che arriva poco sotto 389 giorni. Qualsiasi attesa più lunga richiede invece un timelock assoluto.
Un fallimento non è un ritardo, è un rifiuto. Prima che il periodo di attesa sia terminato, la spesa non è una transazione in sospeso in coda, ma una transazione non valida che nessun nodo trasmetterà e nessun miner includerà. Non serve riprovare finché la moneta non è abbastanza vecchia, e a quel punto la transazione identica diventa valida.
Dove lo vedi
Lightning è il maggiore utilizzatore per volume, e l'opcode è nello script che protegge il tuo lato di ogni canale.
Quando un canale si chiude unilateralmente, il saldo della parte che chiude finisce in un output che non può essere speso finché non è trascorso un ritardo, il to_self_delay del BOLT 3, di solito qualche centinaio di blocchi. Il ritardo esiste perché l'altro peer abbia una finestra per pubblicare una revoca e prendersi i fondi, se la chiusura ha usato uno stato superato. I tuoi fondi sono al sicuro in ogni caso, ma è per questo che una chiusura forzata ti lascia in attesa un giorno o più, mentre una chiusura cooperativa paga subito.
La stessa costruzione compare negli swap submarini e negli swap atomici, dove un percorso di rimborso deve aprirsi solo dopo che la controparte ha avuto una giusta occasione di riscuotere, e nei wallet di recupero, dove una chiave di backup diventa utilizzabile dopo un lungo periodo di inattività.
Una trappola merita un avvertimento. Un timelock relativo si misura dalla conferma della specifica moneta spesa, quindi riparte ogni volta che quella moneta si muove. Consolidare la polvere, spostare il resto o lasciare che un wallet riorganizzi i tuoi output azzera il conto alla rovescia su ogni ramo di recupero che hai impostato, e un erede che si aspettava che la chiave di backup funzionasse il mese prossimo può trovare il conto di nuovo a zero.
OP_CHECKSEQUENCEVERIFY vs OP_CHECKLOCKTIMEVERIFY
CSV chiede da quanto tempo esiste la moneta; CLTV chiede che ore sono. I due opcode sono vicini nella numerazione, 178 e 177, e si scelgono per compiti molto diversi.
Usa la forma assoluta quando la scadenza è una data reale: un trust che si sblocca nel 2030, un rimborso che scade a un'altezza nota. Usa la forma relativa quando l'attesa deve iniziare ogni volta che il contratto parte, cosa di cui ha bisogno qualsiasi script scritto una volta e riutilizzato molte volte. Lightning non poteva usare timelock assoluti per i ritardi dei canali, perché un canale aperto oggi e un canale aperto l'anno prossimo richiederebbero script diversi. Inoltre i due sono arrivati a pochi mesi di distanza, CLTV al blocco 388.381 il 14 dicembre 2015 e CSV il luglio successivo, e il secondo è esistito in gran parte perché il primo non bastava per costruire canali di pagamento.