On Fri, Jan 26, 2024 at 10:28:54PM -0800, Brandon Black wrote: > Hi Peter, > > On 2024-01-24 (Wed) at 19:31:07 +0000, 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
