From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 608BCC0037 for ; 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 ; 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 ; 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 ; 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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedthedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfhfgggtuggjsehgtd erredttddvnecuhfhrohhmpefrvghtvghrucfvohguugcuoehpvghtvgesphgvthgvrhht ohguugdrohhrgheqnecuggftrfgrthhtvghrnhepvefhgefgudeijeevhfeffefgveelgf euhfdvteelhedvtdefudekveeljeelueffnecuffhomhgrihhnpehsthgrthgvmhgvnhht shdruggvvhdpghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgpdhlihhnuh igfhhouhhnuggrthhiohhnrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdhorhhg X-ME-Proxy: 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 To: alicexbt Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cwOF0YeeQMytmQkG" Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--