From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id BBC82C0037 for ; Tue, 30 Jan 2024 04:46:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 8E68240445 for ; Tue, 30 Jan 2024 04:46:32 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8E68240445 Authentication-Results: smtp2.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=Dbyak8X/ 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mOb06g6E53Q for ; Tue, 30 Jan 2024 04:46:31 +0000 (UTC) Received: from fhigh1-smtp.messagingengine.com (fhigh1-smtp.messagingengine.com [103.168.172.152]) by smtp2.osuosl.org (Postfix) with ESMTPS id 20B7B400F1 for ; Tue, 30 Jan 2024 04:46:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 20B7B400F1 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 297531140097 for ; Mon, 29 Jan 2024 23:46:30 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Mon, 29 Jan 2024 23:46:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=1706589990; x=1706676390; bh=tm5sfPyhDXJ8qP8Act27W2cOiPRk A/TQMSWx7FiAEh0=; b=Dbyak8X/26SotSUtYgBGiawIBX8Qf9mTDsnTLNwY+zui QRpMfB4qtvrReVU525Ft4n7OqzIBhi5frSDMDcHdjdm/92mMCb0a8ta3aQwUOoaz crg7yhXxVqp8t7Xis/qCbcLBIc4ijcSfw7h7EPDgxvGpLwC9ICnXMwD64WfynPG5 PpUGW+2Bid6t0Wn/vslf66ApkLAb7LDtfjpvEZaRog6cPmI+SMw2PFT7zX+mxyHD 5Ew9nAGe/feNf5JhZxaQ7QRjA/mwWAEqddr6GhKhP6iWwWbQZypOxUiIA5tQ05Lz YAuxiqhIBiPhcFcu/Ey2JvSIiDX86Qu1SOaN5DyPtA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedthedgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho uggurdhorhhgqeenucggtffrrghtthgvrhhnpeeivddvleeikeejueekgfdtleefgeehhe elffeuheetgefhleevjeefleegvefffeenucffohhmrghinhepphgvthgvrhhtohguugdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hpvghtvgesphgvthgvrhhtohguugdrohhrgh X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 29 Jan 2024 23:46:29 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 6F5AB5F849; Tue, 30 Jan 2024 04:46:27 +0000 (UTC) Date: Tue, 30 Jan 2024 04:46:27 +0000 From: Peter Todd To: Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EnEimIduxQH1a9K8" Content-Disposition: inline In-Reply-To: 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:46:32 -0000 --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--