Published on: 2020-09-03T17:47:35+00:00
In a discussion between Jeremy Rubin and Dmitry Petukhov, the concept of an "inverse timelock" was explored. The idea involves a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it can only be spent along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the revocation UTXO is spent, the covenant path that commits to having it in the inputs becomes unspendable, constituting an "inverse timelock." CTV does not enable this because it does not commit to the inputs, leading to a hash cycle for predicting the output's TXID. However, setting up this scheme requires an ordering around when the tx intended to be the inverse lock is set up before creating the tx using it.On September 3, 2020, Dmitry Petukhov proposed an idea for an "inverse timelock" that could be made almost-certainly automatic. This would involve a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it would only be spendable along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the timeout expires, a multitude of entities would be incentivized to spend this UTXO because it would be free money for them. It would likely be spent by a miner who could replace the spending transaction with their own and claim the amount. Once the revocation UTXO is spent, the covenant path that commits to having it in the inputs would become unspendable, effectively constituting an "inverse timelock. "However, CTV does not enable this because it does not commit to the inputs. Otherwise, there would be a hash cycle for predicting the output's TXID.The context discusses a proposed feature called "inverse timelock" that incentivizes spending a revocation UTXO after a timeout, making it unspendable. This feature has potential use cases in various covenant schemes like trustless lending and access-revocable vaults. The ability to commit to scriptSig of a non-segwit input could also be used for on-chain control of spending authorization, effectively revoking the ability to spend a certain input via CTV path, and alternate spending paths should be used.The implications of this feature on Bitcoin's behavior during reorgs were discussed, with some arguing that new rules violating certain principles should be introduced cautiously. A draft of changes for CTV was prepared but has not been updated yet, leaving time for further feedback.A member of the bitcoin-dev group, Jeremy, proposed a new way to contribute fees to another transaction chain as an observer. This method can help solve issues related to application-DoS attacks beyond child-pays-for-parent (CTV). He has a design for this idea but is not ready to share it yet. Another member suggested the 'Pay for neighbor' (PFN) transaction, where a transaction that is not directly a child of another transaction can pay fees for other transactions. It would be like a "ghost child" transaction and could only be mined after its "ghost parents" are confirmed. The PFN transaction would require a hard fork, but Anthony Towns suggested making it a soft fork by putting the txids of the ghost parents into taproot annex. If some of the ghost parents are confirmed, the miners can get more fees than necessary, similar to CPFP. The mempool code needs to adjust the relationships between parent/child transactions for this ghost relationship idea. However, there could be complications regarding the transaction package size, which requires further analysis.Recently, there have been some refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY and the name has been changed. The opcode specification has also been changed to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead. It permits future soft-fork updates to loosen or remove "constexpr" restrictions. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. In terms of today's scenario, exchanges can do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. Exchanges pay reasonable fees for the transactions so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Business wallets (like exchanges) are able to credit deposits from CTV trees without requiring full expansion.
Updated on: 2023-08-02T01:36:12.880650+00:00