Glossaire / Protocole et mises à jour
OP_CHECKSEQUENCEVERIFY
Aussi appelé CSV, BIP112.
- Qu'est-ce qu'OP_CHECKSEQUENCEVERIFY ?
- OP_CHECKSEQUENCEVERIFY verrouille une pièce pendant une durée mesurée depuis sa propre confirmation, et fait échouer toute dépense dont l'entrée n'a pas attendu assez longtemps.
Spécifié dans BIP-112.
L'opcode lit un nombre sur la pile et le compare au champ sequence de l'entrée dépensée, de sorte que le compte à rebours démarre quand la pièce arrive dans un bloc et non à une date du calendrier. Le BIP-112 l'a défini et le réseau a commencé à l'appliquer au bloc 419 328 le 4 juillet 2016. Chaque canal Lightning que vous ouvrez en dépend.
Comment cela fonctionne
L'opcode 178 s'appelait auparavant OP_NOP3 et ne faisait rien, ce qui explique que la règle soit parvenue au réseau comme un soft fork plutôt qu'une scission.
La vérification s'appuie sur trois éléments : le nombre sur la pile, le champ sequence de l'entrée dépensée et la version de la transaction. La version 2 ou supérieure est requise, car les règles de verrou temporel relatif du BIP-68 ne s'appliquent qu'à partir de cette version. Si le bit de poids fort de l'une des deux valeurs est activé, le verrou temporel est désactivé et l'opcode abandonne. Sinon, les deux doivent s'accorder sur leur unité et la valeur de la pile ne doit pas dépasser le champ sequence.
Les unités existent en deux variantes et elles ne peuvent pas être mélangées dans une même comparaison. Désactivez un indicateur précis et le nombre compte des blocs ; activez-le et le nombre compte des intervalles de 512 secondes. Seize bits sont disponibles dans les deux cas, le plafond est donc de 65 535 blocs, soit environ 455 jours, ou du même nombre d'intervalles de 512 secondes, ce qui donne un peu moins de 389 jours. Toute durée plus longue exige un verrou temporel absolu.
Un échec n'est pas un délai, c'est un rejet. Avant la fin de la période d'attente, la dépense n'est pas une transaction en attente dans une file, c'est une transaction invalide qu'aucun nœud ne relaiera et qu'aucun mineur n'inclura. Rien n'a besoin d'être retenté tant que la pièce n'est pas assez ancienne, moment où la transaction identique devient valide.
Où vous le rencontrez
Lightning est le plus grand utilisateur en volume, et l'opcode figure dans le script qui protège votre propre côté de chaque canal.
Lorsqu'un canal se ferme unilatéralement, le solde de la partie qui ferme part dans une sortie qui ne peut pas être dépensée avant l'écoulement d'un délai, le to_self_delay du BOLT 3, souvent quelques centaines de blocs. Ce délai existe pour que l'autre pair dispose d'une fenêtre pour publier une révocation et récupérer les fonds si la fermeture a utilisé un état périmé. Votre argent est en sécurité dans les deux cas, mais c'est pourquoi une fermeture forcée vous fait attendre un jour ou plus, tandis qu'une fermeture coopérative paie immédiatement.
La même construction apparaît dans les swaps sous-marins et les swaps atomiques, où un chemin de remboursement ne doit s'ouvrir qu'après que la contrepartie a eu une occasion équitable de réclamer, et dans les portefeuilles de récupération où une clé de secours devient utilisable après un long silence.
Un piège mérite une mise en garde. Un verrou temporel relatif se mesure depuis la confirmation de la pièce précise dépensée, il redémarre donc chaque fois que cette pièce bouge. Consolider de la poussière, balayer de la monnaie ou laisser un portefeuille réorganiser vos sorties remettra à zéro le compte à rebours de chaque branche de récupération que vous avez mise en place, et un héritier qui attendait que la clé de secours fonctionne le mois suivant peut retrouver le compteur à zéro.
OP_CHECKSEQUENCEVERIFY vs OP_CHECKLOCKTIMEVERIFY
CSV demande depuis combien de temps la pièce existe ; CLTV demande quelle heure il est. Les deux opcodes se suivent dans la numérotation, 178 et 177, et ils sont choisis pour des tâches très différentes.
Utilisez la forme absolue lorsque l'échéance est une vraie date : une fiducie qui se débloque en 2030, un remboursement qui expire à une hauteur connue. Utilisez la forme relative lorsque l'attente doit commencer dès que le contrat démarre, ce dont a besoin tout script écrit une fois et réutilisé de nombreuses fois. Lightning ne pouvait pas utiliser de verrous temporels absolus pour les délais de canal, car un canal ouvert aujourd'hui et un canal ouvert l'année suivante auraient besoin de scripts différents. Le couple est aussi apparu à quelques mois d'intervalle, CLTV au bloc 388 381 le 14 décembre 2015 et CSV en juillet suivant, et le second a existé en grande partie parce que le premier ne suffisait pas à construire des canaux de paiement.