Author: Joachim Strömbergson 2020-06-07 16:51:10
Published on: 2020-06-07T16:51:10+00:00
The author of the email is enquiring about OP_CTV in relation to a scaling use case, specifically an exchange (or similar) who wants to batch pay to OP_CTV to many users. The author asks how the exchange will communicate proof of payment to user wallets so they can construct follow-up transactions and accept payment. They also question who pays the fees for the transaction within the structure that OP_CTVed output is committed to. Furthermore, the author points out a concern that it may be possible for a malicious entity among the many users being paid with a small UTXO relative to others to create a middle transaction with RBF disabled and use a very small fee rate to DoS other participants. Jeremy Rubin announces refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY, which replaces previous OP_SECURETHEBAG BIP. Changes include changing the name to something more fitting and acceptable to the community, changing the opcode specification to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead, permitting future soft-fork updates to loosen or remove "constexpr" restrictions, and providing a more detailed comparison to alternatives in the BIP, and why OP_CHECKTEMPLATEVERIFY should be favored even if a future technique may make it semi-redundant. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY, and improvements to the mempool are also under development which will help make it safe to lift some of the mempool's restrictions on longchains specifically for OP_CHECKTEMPLATEVERIFY output trees.
Updated on: 2023-06-13T22:30:43.948270+00:00