Author: Dmitry Petukhov 2020-02-14 11:18:26
Published on: 2020-02-14T11:18:26+00:00
The 'revocation utxo' feature enabled by OP_CTV commiting to scriptSig may have wider implications that can slightly change the behavior of Bitcoin as a system, and some might not expect such changes or might not find them desirable. During reorgs of depth less than 100, it is always possible to eventually replay transactions from the old branch into the new branch as long as no double spends are attempted, but this principle can be violated with the use of RBF. Some may hold an opinion that introducing new rules that violate that principle should be done with caution. The 'revocation utxo' feature essentially introduces a manually triggered 'inverse timelock', which makes tx invalid _after_ certain point in time, in this case by spending an unrelated UTXO. In a reorg, one branch can have that UTXO spent before the OP_CTV transaction that depends on it is included in the block, and the OP_CTV transaction and its children can't be replayed. This is the same issue as an 'automatic inverse timelock' that could be enforced by the structure of the transaction itself, if there was appropriate mechanism, with the difference that 'revocation utxo' is manually triggered. The absense of 'automatic inverse timelock' mechanism in Bitcoin hints that it was not seen as desireable historically. The behaviour enabled by inverse timelocks could be useable in various schemes with covenants, like the vaults with access revocable by spending the 'revocation utxo', or in the trustless lending schemes where the covenant scripts can enforce different amounts of interest paid to lender based on the point in time when the loan is returned - the obsolete script paths (with smaller interest paid) can be disabled by inverse timelock. Another idea for smart vaults is the ability to commit to scriptSig of a non-segwit input could be used for on-chain control of spending authorization (revoking the spending authorization), where CTV ensures that certain input is present in the transaction. ScriptSig of that input can contain a signature that commits to certain prevout. Unless it is possible to forge an identical signature, such an input can only be valid if that prevout was not spent. Thus spending such prevout makes it impossible to spend the input with CTV that commits to such scriptSig, in effect revoking an ability to spend this input via CTV path, and alternate spending paths should be used (like, another taproot branch).
Updated on: 2023-06-13T22:30:15.620251+00:00