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