path: root/a1/1772c3d853478684af49022d5aef907b37cf47

Return-Path: <pete@petertodd.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 608BCC0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Jan 2024 04:41:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 2AC4A418A3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Jan 2024 04:41:37 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2AC4A418A3
Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm3 header.b=fh92UaLg
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id DLPDP5zM_uIo
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Jan 2024 04:41:36 +0000 (UTC)
Received: from fhigh1-smtp.messagingengine.com
 (fhigh1-smtp.messagingengine.com [103.168.172.152])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 20A50418A2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Jan 2024 04:41:36 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 20A50418A2
Received: from compute7.internal (compute7.nyi.internal [10.202.2.48])
 by mailfhigh.nyi.internal (Postfix) with ESMTP id 63FAB1140084;
 Mon, 29 Jan 2024 23:41:34 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute7.internal (MEProxy); Mon, 29 Jan 2024 23:41:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:content-type:date:date
 :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:subject:subject:to
 :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
 fm3; t=1706589694; x=1706676094; bh=nObrkHwj0kayTZjZZ/6YiEPOVFSQ
 jgEtFc5OSt2/eYM=; b=fh92UaLge4Lkr9ij3VMUTFQmGK+xuWJHYVFHYwNZKM17
 BPwKNrIOcVERsWaXQfHbHz/Wgax1R6PajvWuIhq40bo8A1TnHcIXw4yCoGs5zUF9
 Jeg4XS1/R/ngvvQvdbgjvBtkmTA9V3FohWgEzDqkAQkBaNr6gi0d2oiL6rU4c5Sl
 g8W/r7Jxptgc/sdGYM8mPbANrLYeLZzhrYvAOtJWojapmQskyMZt3l8R13PjVCFs
 488P6qrk6ZmxUGVx2WTTvvG77VdhekPlxE/8/4x+50j3TWFIlkl/VmyRr/d7u5D4
 V7eIcIacGIGJ/poeah1tUHuic+WiVJ+/awsBr0+XjA==
X-ME-Sender: <xms:_X24ZdWgzMfYxYw6S1ZT5J_DCNtE0MElmTh8jLLrz4D1w1nHNbNYDA>
 <xme:_X24Zdn08SzW4ZhifpT2OQpbpdL53PY-esFRCy_Y1TeEU6o0fD2HZyKN6AIWNXsK5
 SXp5OueQxu5nGZIGH0>
X-ME-Received: <xmr:_X24ZZaObGKtp9gk_NuqO4SAAA9yww-wo7FWaVeLxKQL87lfgJ5KyWdG-CSt>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedthedgjedvucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfhfgggtuggjsehgtd
 erredttddvnecuhfhrohhmpefrvghtvghrucfvohguugcuoehpvghtvgesphgvthgvrhht
 ohguugdrohhrgheqnecuggftrfgrthhtvghrnhepvefhgefgudeijeevhfeffefgveelgf
 euhfdvteelhedvtdefudekveeljeelueffnecuffhomhgrihhnpehsthgrthgvmhgvnhht
 shdruggvvhdpghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgpdhlihhnuh
 igfhhouhhnuggrthhiohhnrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr
 rghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:_X24ZQXmfjvBNS96rpcX4xMh57MeVUyZNyVhmS36UF_t7y_24rSzAg>
 <xmx:_X24ZXkykPZPkll4SjizXEw8ZwCy50vZu8oXmZxtv9NEDQldg9TJcw>
 <xmx:_X24ZdfPMH87A9XEPDMJLzzeOYu30aBbdGf7K8-4ZbH4iAN8gzNbkQ>
 <xmx:_n24ZSuI3eCBrB5o6-rmDKaXrYsNaW0ZjiO-TNbNeNmXmtPyLU5tnA>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 29 Jan 2024 23:41:33 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
 id 1A2F35F849; Tue, 30 Jan 2024 04:41:30 +0000 (UTC)
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jan 2024 04:41:37 -0000


--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--