Hi Peter Interesting post. By implicitly committing in advance to the fee paid by the spending transaction CTV is certainly nailing its colors to the CPFP mast rather than operating in a RBF world. And in a future high fee environment (ignoring whatever is driving those high fees, monetary or non-monetary use cases) as you state paying for an additional CPFP transaction is suboptimal rather than just replacing an existing unconfirmed transaction.
I did a cursory search to look for an in depth technical comparison of CPFP and RBF and I found this from Antoine (Poinsot) on Bitcoin StackExchange [0]. In that he states his view that: "If most nodes didn't enforce mandatory BIP125 signalling, RBF would be superior in all aspects to CPFP from the perspective of the emitter of transaction. CPFP is much less efficient, and not always possible: you need the transaction to have a change output and (at least at the time of writing [0]) the parent to pass policy checks on its own, for instance if it's below the minimum feerate of most mempools on the network you won't be able to CPFP it at the moment." I assume that a CTV based LN-Symmetry also has this drawback when compared to an APO based LN-Symmetry? In theory at least an APO based LN-Symmetry could change the fees in every channel update based on what the current market fee rate was at the time of the update. In today's pre LN-Symmetry world you are always going to have justice transactions for revoked states that were constructed when the market fee rate was very different from the present day's market fee rate. Thanks Michael [0]: https://bitcoin.stackexchange.com/questions/117703/comparison-between-cpfp-and-bip125-for-fee-bumping -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Wednesday, 24 January 2024 at 19:31, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > CheckTemplateVerify(1) is a proposed covenant opcode that commits to the > transaction that can spend an output. Namely, # of inputs, # of outputs, > outputs hash, etc. In practice, in many if not most CTV use-cases intended to > allow multiple parties to share a single UTXO, it is difficult to impossible > to > allow for sufficient CTV variants to cover all possible fee-rates. It is > expected that CTV would be usually used with anchor outputs to pay fees; by > creating an input of the correct size in a separate transaction and including > it in the CTV-committed transaction; or possibly, via a transaction sponsor > soft-fork. > > This poses a scalability problem: to be genuinely self-sovereign in a protocol > with reactive security, such as Lightning, you must be able to get > transactions > mined within certain deadlines. To do that, you must pay fees. All of the > intended exogenous fee-payment mechanisms for CTV require users to have at > least one UTXO of suitable size to pay for those fees. > > This requirement for all users to have a UTXO to pay fees negates the > efficiency of CTV-using UTXO sharing schemes, as in an effort to share a UTXO, > CTV requires each user to have an extra UTXO. The only realistic alternative > is > to use a third party to pay for the UTXO, eg via a LN payment, but at that > point it would be more efficient to pay an out-of-band mining fee. That of > course is highly undesirable from a mining centralization perspective.(2) > > Recommendations: CTV in its current form be abandoned as design foot-gun. > Other > convenant schemes should be designed to work well with replace-by-fee, to > avoid > requirements for extra UTXOs, and to maximize on-chain efficiency. > > 1) > https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6d7e7605/bip-0119.mediawiki > 2) > https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a-danger-to-mining-decentralization > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
