Verrouillage temporel relatif

Le BIP-68 a donné un sens de consensus au champ de séquence de quatre octets de chaque entrée, mais uniquement pour les transactions déclarant la version 2 ou supérieure. La règle est arrivée sur le réseau via un déploiement versionbits du BIP-9 sur le bit 0, ouvert le 1er mai 2016 et livré aux côtés des BIP-112 et BIP-113. Si vous détenez des bitcoins derrière un script de récupération ou de canal, le compte à rebours redémarre chaque fois que ces bitcoins sont déplacés.

Comment cela fonctionne

Les verrouillages temporels relatifs sont encodés dans le champ de séquence, et le bit de poids fort décide si quelque chose se produit.

Avec le bit 31 défini, le champ n'a aucun sens de consensus et l'entrée peut être incluse dans n'importe quel bloc. Avec le bit 31 effacé, les nœuds masquent le champ avec 0x0000ffff et lisent les 16 bits restants comme une période d'attente. Le bit 22 choisit l'unité. Effacé, le nombre compte des blocs, et le BIP-68 donne la plage de 0 à 65 535 blocs, qu'il appelle 1,25 années. Défini, le nombre compte des périodes de 512 secondes, une plage que le BIP énonce comme inférieure à 33 554 431 secondes, soit environ 1,06 années. Le 512 inhabituel a été choisi parce que les blocs arrivent environ toutes les 600 secondes, de sorte que les deux unités couvrent une durée similaire avec les mêmes 16 bits.

Une entrée portant une valeur en blocs de n peut être incluse n blocs après le bloc qui a miné la sortie qu'elle dépense, de sorte qu'une valeur de 1 est levée dès le bloc suivant et non celui d'après. Les valeurs temporelles ne sont jamais comparées à une horloge. Le BIP-68 mesure à partir du median time past du bloc précédant celui qui a miné la sortie, et par rapport au median time past du bloc précédant celui en cours de construction, et le BIP-113 définit cette valeur comme la médiane des 11 derniers horodatages de blocs. Les médianes sont utilisées plutôt que les horodatages bruts parce que les règles de consensus garantissent que la médiane progresse de façon monotone, ce qui empêche un mineur de percevoir des frais supplémentaires en mentant sur l'heure d'un bloc.

Deux exceptions comptent. Les règles ne s'appliquent jamais au champ de séquence de l'entrée d'une transaction coinbase. Et six positions, de 16 à 21, ont été laissées indéfinies afin qu'un futur soft fork puisse augmenter la granularité ou le plafond sans nouveau champ.

Où cela se voit

Le BIP-112 fait fonctionner un verrouillage temporel relatif dans un contrat de dépôt sous séquestre qui expire 30 jours après son financement.

Alice, Bob et un agent séquestre partagent un script 2-sur-3. Deux d'entre eux peuvent dépenser à tout moment ; après le délai, Alice signe seule. Le BIP est catégorique sur le déclencheur : le compte à rebours ne commence pas avant que le paiement vers l'adresse du séquestre ne soit confirmé. C'est toute la différence avec une échéance calendaire, et c'est pourquoi un seul script sert à chaque nouveau séquestre sans réécriture.

La règle façonne aussi le comportement des mempools. La vérification du verrou de séquence de Bitcoin Core s'exécute par rapport à la hauteur du bloc suivant plutôt qu'à la pointe actuelle, et traite un parent non confirmé comme s'il allait se confirmer dans ce bloc, de sorte qu'une dépense dont l'attente expire avec le bloc à venir est relayée légèrement avant d'être dépensable. En dehors de cette marge, il n'y a pas de file d'attente : une dépense prématurée est invalide, pas en attente.

Verrouillage temporel relatif vs OP_CHECKSEQUENCEVERIFY

Un verrouillage temporel relatif réside sur l'entrée de la transaction, tandis qu'OP_CHECKSEQUENCEVERIFY réside dans le script du bitcoin et vérifie qu'une entrée qui dépense le bitcoin en respecte un.

Le BIP-68 à lui seul ne lie personne. Celui qui construit la dépense choisit la valeur de séquence, de sorte qu'un délai qui y est écrit est une préférence, pas une règle sur laquelle une contrepartie peut compter. Le BIP-112 comble l'écart en rendant le champ lisible depuis un script : l'opcode échoue si la version de la transaction est inférieure à 2, si la séquence de l'entrée a le drapeau de désactivation défini, si les deux valeurs divergent sur leur unité, ou si le nombre sur la pile dépasse la séquence masquée. Une valeur de pile portant elle-même le drapeau de désactivation fait que l'opcode se comporte comme un NOP, une marge délibérée pour un futur soft fork. Ce n'est qu'avec ces vérifications en place que l'attente devient quelque chose sur quoi un agent séquestre ou un pair Lightning peut compter.