Feedback-ID: i525146e8:Fastmail
Date: Tue, 30 Jan 2024 04:41:30 +0000
From: Peter Todd <pete@petertodd.org>
To: alicexbt <alicexbt@protonmail.com>
Message-ID: <Zbh9+oNDuPEapFwQ@petertodd.org>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
 <Plx5nCQxEjS8u-XLGEza0bBGgztkCh7wMTckN95VNqqM6HZfbXxywAqMxiwhO-VIIJq9vioSr7jPwWTIksLkgdTM9aBn6mkmlfHGm-1LhbM=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="cwOF0YeeQMytmQkG"
Content-Disposition: inline
In-Reply-To: <Plx5nCQxEjS8u-XLGEza0bBGgztkCh7wMTckN95VNqqM6HZfbXxywAqMxiwhO-VIIJq9vioSr7jPwWTIksLkgdTM9aBn6mkmlfHGm-1LhbM=@protonmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's
 Required For Fee Payment
Precedence: list


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

On Sat, Jan 27, 2024 at 05:50:27PM +0000, alicexbt wrote:
> Hi Peter,
>=20
> In addition to the various methods shared by Brandon, users also have the=
 option of using multiple templates, each with different fee rates. While t=
his introduces some trade-offs, it remains a possibility that some users mi=
ght prefer.

I mentioned this possibility in the email that you are replying to. It is
difficult to impossible to implement in many (but not all!) CTV-using
constructions because you get an exponential "blow-up" of possible fee
variants.

> OP_IF
>     //Template-A
>    OP_PUSHBYTES_32 HASH1 OP_CHECKTEMPLATEVERIFY
> OP_ELSE
>     //Template-B
>    OP_PUSHBYTES_32 HASH2 OP_CHECKTEMPLATEVERIFY
> OP_ENDIF

Note that with taproot, it is more efficient to do this via taproot leafs t=
han
with IF statements.

> /dev/fd0
> floppy disk guy
>=20
> Sent with Proton Mail secure email.
>=20
> On Wednesday, January 24th, 2024 at 7:31 PM, Peter Todd via bitcoin-dev <=
bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> > CheckTemplateVerify(1) is a proposed covenant opcode that commits to the
> > transaction that can spend an output. Namely, # of inputs, # of outputs,
> > outputs hash, etc. In practice, in many if not most CTV use-cases inten=
ded to
> > allow multiple parties to share a single UTXO, it is difficult to impos=
sible to
> > allow for sufficient CTV variants to cover all possible fee-rates. 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
> > This requirement for all users to have a UTXO to pay fees negates the
> > efficiency of CTV-using UTXO sharing schemes, as in an effort to share =
a UTXO,
> > CTV requires each user to have an extra UTXO. The only realistic altern=
ative is
> > to use a third party to pay for the UTXO, eg via a LN payment, but at t=
hat
> > point it would be more efficient to pay an out-of-band mining fee. That=
 of
> > course is highly undesirable from a mining centralization perspective.(=
2)
> >=20
> > Recommendations: CTV in its current form be abandoned as design foot-gu=
n. Other
> > convenant schemes should be designed to work well with replace-by-fee, =
to avoid
> > requirements for extra UTXOs, and to maximize on-chain efficiency.
> >=20
> > 1) https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355b=
f6d7e7605/bip-0119.mediawiki
> > 2) https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are=
-a-danger-to-mining-decentralization
> >=20
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmW4ffgACgkQLly11TVR
LzcX7RAAt51NswgmsMfO87EG9Mqtui1FJ+Hc01U7KAr0RsE0NOQH9zn8o0i0aJ8Z
X78FqlnXaXGb44/GOIVgZAjbSKLF9k9xR8fCFsj4Z/biwLh0rpFaWkw5Aa15wH2H
CdvQRbnnsoby2cdwOPzWLoGcckRQpbMrfJQyQRV5Kv8CL5a5n7Y3oGND9pD+ancr
eq7h7gJjzd9A9p1j21MwCZAWwnSVP3FxNuorPyT5Oq7XY5Z3i4lovwwKVU1ZHYwI
7xvOcW4EaCMGwtAGaSHxgn4xMMH9s63GZsGtdbUkMBSpbmyGZY6zAFY5ShT9Af0z
ZFpD69DKXMIl/h9esyjZAHqpCLcoHyGgzCryrD9pJRSKsDtq1e1YRx3tXfGErzRw
VCujFoxqbVz794ghMhXJJQnQdx8DiJi8JWOj18POUK/xFj+xclNy9OVn5b9iHOG4
+aUU/xBq3LdqCfJqanAUq8PfRRBn0l3XZVe2wMPbhqxOLJ1IBkw29KpP/xu5SqJb
WpPGT+1VXlToq6kk6ifdVFnKbjt//E2PsNW7APH+QsyTyKBDYkHEdupCHhHrRm3i
OhUW+ekBP35dA24TMOgV4ENaLrydptE7/NeeP5+TLXTY3Nmp6bMzlH6bWssMLVx7
yj6pcFXEEnJ1rV2ff/gCopZFUtqDtkygMZuUmw5yw5Ys3xCR0yc=
=r6ec
-----END PGP SIGNATURE-----

--cwOF0YeeQMytmQkG--