Feedback-ID: i525146e8:Fastmail
Date: Tue, 30 Jan 2024 04:46:27 +0000
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Zbh/I+7NIoAmlEt8@petertodd.org>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
 <ZbSipq2QQx904Ofo@console>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="EnEimIduxQH1a9K8"
Content-Disposition: inline
In-Reply-To: <ZbSipq2QQx904Ofo@console>
Subject: Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's
 Required For Fee Payment
Precedence: list


--EnEimIduxQH1a9K8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 26, 2024 at 10:28:54PM -0800, Brandon Black wrote:
> Hi Peter,
>=20
> 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 inc=
luding
> > it in the CTV-committed transaction; or possibly, via a transaction spo=
nsor
> > soft-fork.
> >=20
> > This poses a scalability problem: to be genuinely self-sovereign in a p=
rotocol
> > with reactive security, such as Lightning, you must be able to get tran=
sactions
> > mined within certain deadlines. To do that, you must pay fees. All of t=
he
> > intended exogenous fee-payment mechanisms for CTV require users to have=
 at
> > least one UTXO of suitable size to pay for those fees.
>=20
> 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.
>=20
> 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 em=
ail
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.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--EnEimIduxQH1a9K8
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmW4fyEACgkQLly11TVR
LzehBg//eJ/iBuFMJEqhe1KAwN6s8Lzn6qKJNujbZijVpFg9rCdWzNSJYRjuCfQH
zVGeuQiD7j+9Kz74GulpTLcsonAn0yLUvF3DWRrBkzbT2ElNfzjY5QIisDlfEsLm
YicY/fEy/9shwuLGcqmCo7g67jJmfQ7QYTH6kgf8wi01vmMSjexujtis8Buf3ngi
QYlqExG498KX1xygS1epnd3eTnhGpcrDV+X8yiy/ld82Qac5UdLmEeh3X5toic+H
ctum0l9q1F2QV1igiFMhJqC8UEzbs8+3rWJg0T/GjQkuH+qbguzs7AgdlAb+x3SV
DXZBLBFPxcA8FoUJB3GjoeOyFRXucw/8bswJGfVH8yN7ptp0gMGMCY/Go+HTbAoc
P6+SAqRMKiCHUX0R707voh4uIwt9IPNUljY/fDvWCTC4u7lo23vs95J7brU9ypRd
FZo/CJWiGn9amdzQjICVUcJqudO2XcBVO6Y84aXVusACbuGpFdZydESydAlOB9+k
1EKWHVZtdt1R4991j+F0lhEh14luaPwpAnQfA6LACDW2Mw0RQhuTrZS7ogJkh0eF
8HYTeqtiZcUUH9z9iQgrZYfaqY5VENDzqMJ9Ud9P2OaH0OoZipbcPn3kE/s2v76J
PT7byu1PP1wA7CiIzV7YFyrK4U/ygAAX+ILUsdCm7o8eFd39BgY=
=imfH
-----END PGP SIGNATURE-----

--EnEimIduxQH1a9K8--