A BIP proposal for 'cancellable' transactions

Alejandro Ranchal Pedrosa and Tucci-Piergiovanni proposed a new BIP to extend OP_CSV1 and/or OP_CLTV2 to allow and interpret negative values.

The discussion that followed concluded that the BIP would be breaking a fundamental rule which is that valid transactions remain valid. This could lead to loss of funds when several transactions are made invalid.

For instance in BIP112 ,

HASH160 <revokehash> EQUAL
IF
    <Bob's pubkey>
ELSE
    "24h" CHECKSEQUENCEVERIFY DROP
     <Alice's pubkey>
ENDIF
CHECKSIG

Only Bob is entitled to the funds for the first 24 hours and then to whichever spends it first. Alejandro and Sara propose the use of the negative bit as follows:

HASH160 <revokehash> EQUAL
IF
    <Bob's pubkey>
ELSE
     "-24h" CHECKSEQUENCEVERIFY DROP
     <Alice's pubkey>
ENDIF
CHECKSIG

The second transaction gives both Alice and Bob ownership of the funds for the first 24 hours after which only Bob will own it. The key difference is that the latter considers negative values that are “at the moment discarded as for the specification of BIP-112, leaving the sign bit unused.”

Alejandro and Sara argue that this will make conditions for transaction fair for both parties and reduce the cost of modifying transactions.

However Gregory Maxwell went on reminding that functionalities like this don’t exist mainly because they have been proven to be harmful to the system.

For instance when a valid transaction is made invalid, reorganization will destroy coins. This is because any coin with any form of non-monotone validity period in its recent history behaves like a newly generated coin, which can be destroyed by reorganization. This is why current CLTV/CSV designs ensure that valid transactions remain valid and are not reversible. Coins will be destroyed even if their prior owner didn’t do anything to cause that. For instance Bitcoin addresses this issue for generated coins by preventing use of newly generated coins for 100 blocks.

Brandon Smith noted that he made a similar proposal a few months ago, and the discussion that ensued reached the same conclusion, meaning if the proposal is to be adopted, it means any UTXO spending a script with an expiration time must be subjected to the treatment of new coins (not usable till after 100 blocks).

Secondly, all currently used software take any valid transaction as permanently valid. Any proposal to change this must therefore ensure that users of current wallets are not exposed to scammers who may initiate low fee transactions that will eventually expire.

Transactions could “re-propagate between mempools of differing policies” which causes coins to get held up and unusable for an unnecessarily long time. However. There are alternative ways around the issue which include Lightning, improved fee estimation, and improved mempool eviction / re-propagation resistance.

To achieve the same goal as this proposal, Matt Corallo suggestion is to have a “multisig option with a locktime pre-signed transaction with different spendability”, that can be broadcast after 24 hours to prevent the coins being destroyed through reorg.

In general though, the BIP will be breaking a fundamental rule which is that valid transactions remain valid. This could lead to loss of funds when several transactions are made invalid.


  1. OP_CHECKSEQUENCEVERIFY: marks transaction as invalid if the relative lock time of the input (enforced by BIP 0068 with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in BIP-112. see [return]
  2. OP_CHECKLOCKTIMEVERIFY: Marks transaction as invalid if the top stack item is greater than the transaction’s nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction’s nLockTime field is less than 500000000, or vice versa; or 4. the input’s nSequence field is equal to 0xffffffff. The precise semantics are described in BIP-65. see [return]

Comments powered by Talkyard.