From: Peter Todd <pete@petertodd•org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Date: Tue, 30 Jan 2024 04:46:27 +0000 [thread overview]
Message-ID: <Zbh/I+7NIoAmlEt8@petertodd.org> (raw)
In-Reply-To: <ZbSipq2QQx904Ofo@console>
[-- Attachment #1: Type: text/plain, Size: 2564 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-30 4:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 19:31 Peter Todd
2024-01-25 12:57 ` Michael Folkson
2024-01-30 4:12 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2024-01-30 4:38 ` Peter Todd
2024-01-30 5:07 ` ZmnSCPxj
2024-01-30 5:17 ` ZmnSCPxj
2024-01-30 5:55 ` Anthony Towns
2024-01-30 8:40 ` Peter Todd
2024-01-25 17:49 ` [bitcoin-dev] " jlspc
2024-01-30 4:49 ` Peter Todd
2024-02-20 23:13 ` [bitcoindev] " 'jlspc' via Bitcoin Development Mailing List
2024-01-27 6:28 ` Brandon Black
2024-01-30 4:46 ` Peter Todd [this message]
[not found] ` <Plx5nCQxEjS8u-XLGEza0bBGgztkCh7wMTckN95VNqqM6HZfbXxywAqMxiwhO-VIIJq9vioSr7jPwWTIksLkgdTM9aBn6mkmlfHGm-1LhbM=@protonmail.com>
2024-01-30 4:41 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zbh/I+7NIoAmlEt8@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox