Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
On Thu, Jan 25, 2024 at 05:49:26PM +, jlspc wrote: > Hi Peter, > > If feerate-dependent timelocks (FDTs) (1) are supported, it would be possible > to use CTV to define a transaction with a fixed fee and no anchor outputs, as > long as it's racing against a transaction with an FDT. Fee-rate-dependant timelocks have obvious issues around manipulation of observed fee-rates by miners. It not unreasonable to say they assume miners are honest, which is a significant weakening of the economic incentive-based security model we usually assume in Bitcoin. -- 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
Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
On Fri, Jan 26, 2024 at 10:28:54PM -0800, Brandon Black wrote: > Hi Peter, > > On 2024-01-24 (Wed) at 19:31:07 +, Peter Todd via bitcoin-dev wrote: > > 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. > > I understand your reservations with regard to CTV-based protocols for > scaling bitcoin and lightning. Fortunately, the "user gotta have a UTXO" > concern is readily answered (and you actually gave one answer to > approximately the same concern from me when we discussed lightning > fees): If the user's balance inside the protocol is not sufficient to > pay exit fees then they aren't going to try to exit; so their > in-protocol balance can be used to pay fees. With ephemeral anchors > throughout the tree, an exiting user would spend their leaf UTXO, and > the ephemeral anchors along the path to their leaf to create a package > of the necessary fee rate to facilitate their timely exit. > > Alternatively, users entering into a channel tree protocol (e.g. Timeout > Trees) can have their leaf include a second UTXO commitment which would > create a fee-paying output exactly when they need it; without causing a > scaling problem. You are assuming a specific type of CTV use-case. Not all CTV use-cases have this property, which is why I called this a footgun: attractive, but likely to lead to protocol designs with unexpected flaws. Secondly, anchor outputs/CPFP is significantly less efficient than RBF, due to the extra bytes required for the CPFP transaction. As I explained in the email you are replying to, this is a danger to mining decentralization because it requires less bytes to pay fees with out-of-band fee payments. It is much better to deal with fees now, before CTV is standardized as-is, in a way that allows for efficient fee payment via RBF rather than locking in inefficient CPFP designs that invite out-of-band fees. -- 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
Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
On Sat, Jan 27, 2024 at 05:50:27PM +, 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 > 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
Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Hi Peter, On 2024-01-24 (Wed) at 19:31:07 +, Peter Todd via bitcoin-dev wrote: > 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. I understand your reservations with regard to CTV-based protocols for scaling bitcoin and lightning. Fortunately, the "user gotta have a UTXO" concern is readily answered (and you actually gave one answer to approximately the same concern from me when we discussed lightning fees): If the user's balance inside the protocol is not sufficient to pay exit fees then they aren't going to try to exit; so their in-protocol balance can be used to pay fees. With ephemeral anchors throughout the tree, an exiting user would spend their leaf UTXO, and the ephemeral anchors along the path to their leaf to create a package of the necessary fee rate to facilitate their timely exit. Alternatively, users entering into a channel tree protocol (e.g. Timeout Trees) can have their leaf include a second UTXO commitment which would create a fee-paying output exactly when they need it; without causing a scaling problem. Finally, the reality of these protocol proposals is that they are intended to enable users who may never have sufficient funds to pay the full cost to exit the protocol in on chain fees to use bitcoin in a trust-minimized way. To facilitate this, such a protocol could employ fee insurance which would accept claims for fees to pull a specific exit series on chain via any of the mechanisms you describe. This, by the way, would bring more than one user out of the protocol, so even in the worst case it does scale bitcoin by requiring only 1 fee paying UTXO for log_r(n)*(r-1) users to exit. Hope this helps, --Brandon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Hi Peter, If feerate-dependent timelocks (FDTs) (1) are supported, it would be possible to use CTV to define a transaction with a fixed fee and no anchor outputs, as long as it's racing against a transaction with an FDT. Regards, John (1) https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004254.html Sent with Proton Mail secure email. On Wednesday, January 24th, 2024 at 11:31 AM, Peter Todd via bitcoin-dev 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
Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
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 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
