From: Brandon Black <freedom@reardencode•com>
To: Peter Todd <pete@petertodd•org>,
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: Fri, 26 Jan 2024 22:28:54 -0800 [thread overview]
Message-ID: <ZbSipq2QQx904Ofo@console> (raw)
In-Reply-To: <ZbFle6n0Zu3yUV8o@petertodd.org>
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.
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
next prev parent reply other threads:[~2024-01-27 6:39 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 [this message]
2024-01-30 4:46 ` Peter Todd
[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=ZbSipq2QQx904Ofo@console \
--to=freedom@reardencode$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)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