TL; DR:

|  Absolute Timelock  |  Relative Timelock  |
-------------------- | ------------------- | ------------------- |
  Transaction Level  |      nLockTime      |     nSequence       |
-------------------- | ------------------- | ------------------- |
     UTXO Level      | CheckLockTimeVerify | CheckSequenceVerify |  
  (or Script Level)  |         CLTV        |         CSV         |
------------------------------------------------------------------

Terminologies

• Horloge absolue : l'heure de verrouillage sera définie de manière absolue. Il peut être interprété de deux manières: par hauteur de bloc ou par heure, qui sera l'horodatage de l'époque Unix. S'il est interprété comme une hauteur de bloc , il sera enregistré comme au bloc 479083 . S'il est interprété comme l' heure , il sera défini sur 1507574976 , ce qui signifie 10/09/2017 à 18h49 (UTC).
  (Convertissez l'horodatage:https://www.unixtimestamp.com/index.php)
• Timelock relatif : identique au timelock absolu, le timelock relatif peut également être présenté par hauteur de bloc ou par heure. Par exemple, si le blocage temporel est interprété comme la hauteur du bloc, le blocage temporel sera comme après 144 blocs . S'il est interprété comme l'heure, il sera défini comme après 86400 secondes . Tous sont relatifs au bloc parent!
• Timelock au niveau de la transaction: définit l'heure au plus tôt à laquelle la transaction peut être ajoutée dans la blockchain . Autrement dit, il permet au signataire de créer une transaction, qui ne sera valide que dans le futur. De plus, le timelock au niveau tx est également un champ de la transaction bitcoin.
• Timelock UTXO ou Script Level : Ce type de timelock sera ajouté dans le script de l'UTXO, au lieu d'être un champ de la transaction. Il permet à l'UTXO (Sortie de transaction non dépensée) d'être dépensé uniquement après que le temps / les blocs spécifiés se sont écoulés / ont été générés.

nLockTime (Transaction Locktime)

• nLockTime, en tant que fonctionnalité de verrouillage au niveau des transactions, fait partie de l'implémentation originale de Bitcoin. Autrement dit, en regardant dans la transaction Bitcoin, vous pouvez trouver un champ appelé « locktime », qui est exactement le nLockTime.

Wiki Bitcoin

• Comme je l'ai mentionné précédemment, tous les timelocks peuvent être implémentés soit par heure unix, soit par blockheight . Par exemple, si une transaction a un «nLockTime de 3 jours», cela signifie que cette transaction ne peut être valide qu'après trois jours et peut être ajoutée à un bloc et relayer sur le réseau trois jours après la création de cette transaction.
• N'oubliez pas que nLockTime est un délai absolu , il doit donc être enregistré de manière absolue. Si nLockTime est enregistré en dessous de 500 millions, il est interprété comme la hauteur de bloc spécifique. Par exemple, si nLockTime d'une transaction est défini sur 49 999 999, cela signifie que cette transaction ne peut être ajoutée à la blockchain que valablement au bloc 49 999 999. Si nLockTime est défini sur une valeur supérieure à 500 millions, cela signifie que le verrou temporel est enregistré en tant qu'horodatage unix, et cette transaction ne peut être valide qu'après l'heure spécifiée.

# This is a Bitcoin transaction, and there's actually a field named "locktime".
{
    "txid" : "c80b343d2ce2b5d829c2de9854c7c8d423c0e33bda264c4013\
              8d834aab4c0638",
    "hash" : "c80b343d2ce2b5d829c2de9854c7c8d423c0e33bda264c40138d834aab4c0638",
    "size" : 85,
    "vsize" : 85,		
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "3f4fa19803dec4d6a84fae3821da7ac7577080ef75\
                      451294e71f9b20e0ab1e7b",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "",
                "hex" : ""
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 49.99990000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 cbc20a7664f2f69e5355a\
                         a427045bc15e7c6c772 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914cbc20a7664f2f69e5355aa427045bc15e\
                         7c6c77288ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "mz6KvC4aoUeo6wSxtiVQTo7FDwPnkp6URG"
                ]
            }
        }
    ]
}

• CLTV, un calendrier absolu de niveau UTXO , a été ajouté à Bitcoin par une mise à niveau de soft fork en décembre 2015, sur la base de la spécification BIP65 . CLTV est implémenté dans le script du Bitcoin, donc il apparaîtra dans le script du Bitcoin comme OP_CHECKLOCKTIMEVERIFY .

«Lorsque l'opcode CLTV est appelé, cela entraînera l'échec du script à moins que le nLockTime de la transaction soit égal ou supérieur au paramètre time fourni à l'opcode CLTV.»

Wiki Bitcoin

• Pour simplifier les choses, ce qui différencie CLTV de nLockTIme, c'est que CLTV limite l'UTXO (bitcoin dépensable) à dépenser uniquement après que le temps / les blocs spécifiés se soient écoulés / ont été générés, tandis que nLockTime limite la transaction pour être valide et peut être ajoutée à la block / blockchain après un certain temps.
• Pourquoi avoir besoin de CLTV? Voici une bonne explication . (PS, je vais essayer d'expliquer le concept de canaux de paiement et les limites de nLockTime dans la prochaine série d'explications sur Lightning Network!)
• Application: HTLC dans Lightning Network
  (je l'expliquerai dans mon article sur Lightning Network!)

• Les timelcoks relatifs, y compris nSequence et CSV, ont été activés en mai 2016 en tant que mise à niveau soft fork, sur la base des spécifications BIP68 , BIP112 et BIP113 .
• Pourquoi avoir besoin de timelocks relatifs au lieu d'utiliser les timelocks absolus, nLockTime et CLTV?
• Les délais relatifs sont beaucoup plus flexibles, rendant les transactions / UTXO valides / utilisables une fois le temps relatif écoulé, en fonction du temps que le parent bloque ou des transactions à ajouter à la blockchain. (Ne vous inquiétez pas si cela semble assez déroutant pour le moment. Je vous donnerai des exemples spécifiques plus tard!)

• nSequence, le numéro de séquence dans Bitcoin, est un délai relatif au niveau de la transaction , ajouté par la mise à niveau du travail logiciel . Il est maintenant dans l'entrée de chaque transaction , représentée par «séquence».

Wiki Bitcoin

• Par exemple, si une transaction a une entrée avec nSequence défini sur 10 blocs, cela signifie que cette transaction ne peut être valide qu'après que 10 blocs ont été ajoutés à la blockchain à partir du moment où l'UTXO référencé a été extrait.
• Pour le dire plus simplement, considérez qu'il y a deux transactions, une transaction et une transaction B, et B Tx va dépenser le Bitcoin de la sortie d'une transaction. Si l'entrée de la transaction B a un numéro de séquence de 10 blocs, cela signifie que la transaction B ne peut être ajoutée au bloc (enfant) qu'après que 10 blocs ont été générés depuis le moment où une transaction a été incluse dans le bloc (parent).

Vérifier la séquence de vérification (CSV)

• CSV, ajouté avec nSequence à la fourchette souple en mai 2016, est un verrou temporel relatif au niveau UTXO . Il apparaît dans le script Bitcoin sous le nom d'opcode OP_CHECKSEQUENCEVERIFY .

"Lorsque l'opcode CSV est appelé, cela entraînera l'échec du script à moins que la nSequence de la transaction n'indique qu'une quantité égale ou supérieure de temps de verrouillage relatif a dépassé le paramètre fourni à l'opcode CSV."

Wiki Bitcoin

• Fondamentalement, ce que CSV fait à l'UTXO est exactement de la même manière que le CLTV, mais juste de manière relative .
• CSV limite l'UTXO à être dépensé après un certain temps / blocs se sont écoulés par rapport au temps que l'UTXO a été miné. Pour parler simplement, imaginez le CSV comme un verrou (ou plus techniquement, un encombrement) d'un UTXO. Par exemple, 100 blocs. Cela signifie que cet UTXO ne peut être dépensé qu'après 100 temps de bloc depuis que l'UTXO a été miné.
• Considérez le blocage du temps CSV comme un compte à rebours, lorsque l'UTXO a été miné (ou vous pouvez dire que lorsque la transaction a été ajoutée dans le bloc / blockchain), par exemple à une hauteur de bloc de 5000, le CSV de 100 blocs a commencé à compter à rebours. Ce n'est qu'après que 100 blocs ont été ajoutés derrière le bloc 5000 que cet UTXO peut être dépensé. En d'autres termes, cet UTXO ne peut être dépensé qu'au moins après que le bloc 5100, qui est 100 blocs plus tard que l'UTXO a été miné.
• Application: RSMC dans Lightning Network.

C'est tout! La brève introduction à quatre types différents de timelocks utiles dans Bitcoin. Si vous n'êtes pas familier avec Lightning Netowrk de Bitcoin , vous pourriez être vraiment confus sur la raison pour laquelle ces timelocks sont super puissants, et ce que je veux dire pour quelque chose comme HTLC, RSMC pour Lightning Network en tant qu'application de CLTV et CSV.

Tout ce qui concerne le Lightning Network sera présenté et expliqué en détail dans ma prochaine série d'articles, principalement sur le Lightning Network. Restez à l'écoute!

Merci d'avoir lu!

Robin Hung

Référence:

• https://en.bitcoin.it/wiki/Timelock
• https://bitcoin.org/en/developer-guide#signature-hash-types
• https://github.com/bitcoinbook/bitcoinbook/blob/second_edition/ch07.asciidoc