On Sat, Jan 27, 2024 at 05:50:27PM +0000, alicexbt wrote: > Hi Peter, > > In addition to the various methods shared by Brandon, users also have the > option of using multiple templates, each with different fee rates. While this > introduces some trade-offs, it remains a possibility that some users might > prefer.
I mentioned this possibility in the email that you are replying to. It is difficult to impossible to implement in many (but not all!) CTV-using constructions because you get an exponential "blow-up" of possible fee variants. > OP_IF > //Template-A > OP_PUSHBYTES_32 HASH1 OP_CHECKTEMPLATEVERIFY > OP_ELSE > //Template-B > OP_PUSHBYTES_32 HASH2 OP_CHECKTEMPLATEVERIFY > OP_ENDIF Note that with taproot, it is more efficient to do this via taproot leafs than with IF statements. > /dev/fd0 > floppy disk guy > > Sent with Proton Mail secure email. > > On Wednesday, January 24th, 2024 at 7:31 PM, 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 -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
