CLTV ou CheckLockTimeVerify est une fonctionnalité de blocage de temps intéressante qui existe dans Bitcoin conçue pour permettre à ses scripts d'effectuer des horaires avancés sur leurs transactions. Une fonction qui permet de programmer des scripts avancés ajustés à la demande toujours croissante de fonctions au sein de Bitcoin.
Là l'arrivée de Bitcoin, avec la technologie innovante Blockchain, a ouvert un monde de possibilités; y compris l'argent programmable. Oui, comme vous l'entendez, de l'argent programmable. Bitcoin intègre de nombreuses fonctions, et l'une de ces fonctions est connue sous le nom de Vérifier le temps de verrouillage Vérifier (CLTV), ce qui permet de sorties non dépensées (UTXO) de Bitcoin sont bloqués et ne peuvent pas être dépensés avant l'arrivée d'une heure préalablement déterminée.
La fonction CLTV a été intégré dans Bitcoin Core à travers la fourche souple BIP-0065, dans lequel son développeur Peter Todd décrire le nouveau opcode (OP_CODE) OP_CHECKLOCKTIMEVERIFY. Cette fonction permet à une transaction effectuée en Bitcoin de rester bloquée dans le temps et de ne devenir effective qu'après une certaine date, heure ou hauteur de bloc.
Ainsi, la fonction CLTV est très utile et positive pour divers cas d'utilisation au sein du système Bitcoin. Par exemple, pour l'épargne à long terme de fonds destinés au paiement de l'université ou à l'obtention du diplôme d'un parent. Il est également possible de planifier des paiements futurs à des dates spécifiques, telles que des locations, des services, des rendez-vous médicaux ou même un héritage intelligent entre autres.
De même, cette fonction est particulièrement importante pour ouvrir de nouvelles alternatives de paiement. Par exemple créer Chaînes payantes de style CLTV. ces canaux de paiement Ils permettent des transactions en dehors de la blockchain tout en conservant toute la sécurité et les avantages d'une transaction conventionnelle qui s'est produite au sein de la chaîne. De plus, la fonction CLTV permet également la mise en place d'autres alternatives telles que des remboursements limités dans le temps ou des fiducies. Les applications et les cas d'utilisation de cette fonction sont vraiment infinis.
Comment fonctionne CLTV?
Lorsqu'un utilisateur établit et effectue une transaction avec le code OP_CHECKLOCKTIMEVERIFY, les sorties de ladite transaction ne seront activées que lorsque la condition établie est remplie, et non lorsque la transaction est effectuée. Ce qui signifie que la transaction est effectuée correctement mais que les crypto-monnaies resteront bloquées dans le temps jusqu'à un moment ultérieur.
Le code OP_CHECKLOCKTIMEVERIFY s'exécute dans le cadre d'un script Bitcoin, et sa programmation est basée sur l'utilisation du UNIX Times (horodatage Unix) ou sur les hauteurs de blocs au sein de la blockchain. Autrement dit, il est nécessaire d'établir une condition dans l'un de ces paramètres pour effectuer une comparaison avec l'heure actuelle. Alors lui OP_CHECKLOCKTIMEVERIFY vérifie l'élément supérieur de la pile avec le verrou temporel (nLockTime) qui a été établie dans la transaction. Si lors de cette comparaison, il s'avère que la condition est remplie, le script peut être exécuté, sinon le script échouera.
Les conditions d'échec du script dans une transaction CLTV sont les suivantes:
- Que la pile est vide et qu'il n'y a pas de temps défini pour que le code effectue la comparaison et la vérification.
- Que, comme déjà mentionné, l'élément supérieur de la pile est inférieur à celui de la condition établie pour déverrouiller les sorties non dépensées. Cela indique que le temps nécessaire pour déverrouiller la transaction ne s'est pas écoulé.
- Une autre condition de défaut se produira si le verrou de temps établi est mesuré en hauteur de bloc et l'élément supérieur de la pile utilise des mesures de temps (en secondes) ou vice versa.
- La campagne nSequence de cette entrée est définie sur 0xFFFFFFFF.
Ensuite, Une transaction CLTV ne peut être incluse dans la blockchain qu'une fois qu'elle a dépassé la durée ou la condition établie. Une fois que cela se produit, les transactions CLTV sont immédiatement vérifiées et ajoutées à la blockchain, et sont considérées comme dépensées.
Relation entre CLTV et nLockTime
CLTV et nLockTime sont deux fonctions qui permettent à Bitcoin de programmer des actions qui dépendent de l'heure ou de la hauteur du bloc pour leur exécution correcte. Mais la relation et la portée des deux vont beaucoup plus loin. D'une part, nLockTime garantit que Bitcoin peut planifier des transactions pour s'exécuter à une certaine hauteur de bloc (verrouillage de l'heure de blocage) ou par horodatage ou horodatage (verrouillage de l'heure spécifique). Avec cela, Bitcoin permet de planifier des paiements en utilisant ces paramètres.
Mais d'un autre côté, CLTV vous permet d'ajouter une couche de vérification et de programmation supplémentaire à nLockTime. En effet, CLTV prend le nLockTime et vérifie qu'un ensemble agrégé de conditions prévues pour son activation est en place, une situation qui était beaucoup plus simple avec le nLockTime d'origine. CLTV permet même de modifier certaines conditions originales de la transaction si certaines conditions sont remplies.
Par exemple, une adresse multi-signature 2 sur 3, qui n'a pas été mobilisée dans un certain laps de temps, peut changer ses paramètres d'authentification en 1 sur 3, afin que certaines des personnes initialement autorisées puissent mobiliser les fonds qui s'y trouvent Contenu. C'est une fonctionnalité unique que CLTV peut offrir et que nLockTime seul ne peut pas.
Que savez-vous, cryptonuta?
CLTV est-il capable de modifier les propriétés des scripts au fil du temps et sous certaines conditions?VRAI!
L'une des plus grandes caractéristiques de CLTV est que son utilisation permet la création de scripts qui peuvent facilement modifier les conditions d'activation d'un événement ou d'une transaction dans la blockchain Bitcoin.
Implémentation CLTV
L'un des plus grands et des plus importants potentiels de la fonction CLTV est de permettre la création de canaux de paiement et que ceux-ci puissent être correctement implémentés. Grâce aux canaux de paiement, des micro-transactions peuvent être créées en dehors de la blockchain. Tout cela sans avoir à payer autant de frais de commission pour chacun et sans effondrer la blockchain.
Dans les canaux de paiement, un utilisateur peut effectuer une transaction vers une autre en déposant une certaine quantité de crypto-monnaies dans un adresse multi-signature (MultiSig). Les deux utilisateurs auront accès à cette adresse. Et l'utilisateur qui effectue la transaction peut signer de petites transactions qui seront faites à l'autre utilisateur à partir de ces fonds. Ceci jusqu'à ce que vous obteniez le produit souhaité. Le reste des fonds vous sera restitué dans une transaction de retour pour chaque micro-transaction que vous effectuez. Alors que le commerçant pourra réclamer le paiement final accumulé, qui aura été effectué sans faire tomber la blockchain et pour lequel Maria n'a payé qu'une commission.
Exemple de fonctionnement de CLTV
Si Maria veut voir une vidéo, mais pour cela, elle doit payer 1 séance par seconde regardée. Il n'est pas pratique pour Maria d'effectuer ces transactions de 1 assis par seconde via une transaction classique en Bitcoin. Puisque pour cela, vous devez payer les frais de commission pour chaque transaction que vous effectuez. Vous devez également attendre que la transaction soit confirmée dans un bloc; ce qui se passe toutes les 10 minutes en Bitcoin.
Voyant que ce n'est pas pratique, Maria décide de créer un canal de paiement. Dans ce canal, vous effectuerez un dépôt dans une adresse multi-signature de 0.5 BTC, ce qui équivaut à 50.000.000 satoshis. Le commerçant et Maria auront accès à l'adresse multi-signature. Ainsi, lorsque Maria commencera à visionner la vidéo, elle signera une transaction où elle enverra 1 assis au marchand pour la première seconde vue. Et 49.999.999 XNUMX XNUMX sats à une adresse de changement de votre adhésion.
Ce processus sera répété plusieurs fois tant que Maria continuera à regarder la vidéo. Autrement dit, elle continuera à signer des micro-transactions et à payer le montant de satoshis équivalent aux secondes qu'elle voit de la vidéo, et à déposer ses retours dans une adresse de retour. Si Maria n'a visionné que 2 secondes de vidéo, elle signera une nouvelle transaction, mais cette fois, 2 se sont assis pour le marchand et 49.999.998 3 3 pour son adresse de retour. Si vous n'avez vu que 49.999.997 secondes, vous signerez une autre transaction, mais cette fois, XNUMX se sont assis pour le commerçant et XNUMX XNUMX XNUMX se sont assis pour votre adresse de retour.
Au cours de ce processus, le commerçant ne réclamera ni ne signera les transactions 1 sat ou 2 sat reçues. Il attendra plutôt que Maria voie tout ce qu'elle veut de la vidéo et réclamera le paiement final. Autrement dit, la plus grosse transaction. Le reste des transactions effectuées au début ne sera pas signé car cela impliquerait une double dépense. Le commerçant doit donc opter pour la plus grosse transaction contenant tous les satoshis reçus, dans cet exemple la transaction 3 satoshis.
De plus, à la fin, le commerçant ne signe qu'une seule transaction, c'est celle qui sera ajoutée à la blockchain et sera la seule pour laquelle les frais de commission correspondant aux mineurs doivent être annulés. De plus, Maria peut implémenter un Transaction CLTV au début pour garantir la restitution de vos fonds déposés à l'adresse multi-signature. Si vous définissez une certaine heure pour que vous puissiez tous les deux signer la transaction, et pour quelque raison que ce soit, l'un ou l'autre d'entre vous peut la signer avant cette heure. Pour que Maria puisse récupérer son argent. Puisque si la transaction n'est pas signée avant la condition établie, Maria peut signer la transaction et se faire rembourser une fois le délai imparti écoulé.
Donc en bref le code OP_CHECKLOCKTIMEVERIFY offre un avantage positif pour la mise en œuvre de contrats intelligents. Cela garantit donc l'intégrité des fonds jusqu'à ce que l'horodatage établi ou la hauteur de bloc soit atteint. Tout en évitant les pannes du système par malléabilité des transactions.