Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

Summary:

A new opcode called CHECKLOCKTIMEVERIFY has been proposed for the Bitcoin scripting system. The opcode makes a transaction output unspendable until a certain point in the future by comparing the top stack item to the nLockTime field of the transaction containing the scriptSig. This allows for proving that a transaction output cannot be spent until some time in the future, which is useful in escrow situations where two parties want to ensure that all funds are kept in 2-of-2 multisig transaction outputs that require the cooperation of both parties to spend.There are two major drawbacks to adding such an operation, however. First, more transaction information is exposed inside the script and second, it becomes harder to enforce mempool invariants during reorgs since any script using this new opcode during its execution would need to be re-evaluated during reorgs.Despite these issues, CHECKLOCKTIMEVERIFY can be used in non-interactive time-locked refunds, two-factor wallets, and micropayment channels. In two-factor wallets, services like GreenAddress store Bitcoins with 2-of-2 multisig scriptPubKeys such that one keypair is controlled by the user, and the other keypair is controlled by the service. To spend funds, the user uses locally installed wallet software that generates one of the required signatures and then uses a 2nd-factor authentication method to authorize the service to create the second SIGHASH_NONE signature that is locked until some time in the future and sends the user that signature for storage. With CHECKLOCKTIMEVERIFY, rather than creating refund signatures on demand, scriptPubKeys can be used instead so that the user is always able to spend their funds without the cooperation of the service by waiting for the expiry time to be reached.The article also discusses vulnerabilities in various Bitcoin protocols and suggests solutions. The micropayment channels by Jeremy Spilman are analyzed, which involve a deposit controlled by 2-of-2 multisig, tx1, and tx2 that spend the output of tx1 to payor and payee, with tx3 as refund transaction. However, the process of creating the refund transaction is currently vulnerable to transaction mutability attacks, and requires the payor to store the refund. To solve this, the same scriptPubKey from the Two-factor wallets example can be used.Furthermore, the PayPub protocol makes it possible to pay for information in a trustless way by proving that an encrypted file contains the desired data, and crafting scriptPubKeys used for payment such that spending them reveals the encryption keys to the data. But, the existing implementation has a significant flaw: the publisher can delay the release of the keys indefinitely. This problem can be solved interactively with the refund transaction technique or non-interactively by using scriptPubKeys of a certain form.Proving the sacrifice of some limited resource is a common technique in cryptographic protocols, but proving sacrifices of coins to mining fees is non-trivial. Announce-commit sacrifices have been proposed as a solution, but they could encourage mining centralization. CHECKLOCKTIMEVERIFY can be used to create outputs that are provably spendable by anyone but only at a time sufficiently far into the future that large miners profitably can't sell the sacrifices at a discount.Finally, the article suggests replacing the nLockTime field entirely, where if the SignatureHash() algorithm could optionally cover part of the scriptSig, the signature could require that the scriptSig contain CHECKLOCKTIMEVERIFY opcodes, and additionally, require that they be executed. The per-signature capability could replace the per-transaction nLockTime field entirely as a valid signature would now be the proof that a transaction output can be spent. The article provides a detailed specification and references for the proposed solutions.

Updated on: 2023-05-19T19:54:12.991386+00:00