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 68B5EC001E for ; Mon, 10 Jan 2022 18:30:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 43EFF40991 for ; Mon, 10 Jan 2022 18:30:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_24_48=1.34, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=petertodd.org header.b="PB+UK6Ax"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="QNhTQaBb" 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 JSbH6_JhvWt3 for ; Mon, 10 Jan 2022 18:30:58 +0000 (UTC) X-Greylist: delayed 00:06:53 by SQLgrey-1.8.0 Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) by smtp4.osuosl.org (Postfix) with ESMTPS id 27AE840985 for ; Mon, 10 Jan 2022 18:30:58 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.west.internal (Postfix) with ESMTP id D711C2B001CD; Mon, 10 Jan 2022 13:24:01 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 10 Jan 2022 13:24:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petertodd.org; h=date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=T9EkUpPqopC5ZZ6ooqDzSOnafLY Cu40QWiqc1qKvXHA=; b=PB+UK6AxqQYOzcIb4eltL9qXNLGq25/grvlSHzNoEoI KHv1qSYBnklLE22CnKvVV0BE6HtjDsy4tet1/aLHKpLgiU5ov2vqlF53PCvfDjVn EyThN1fDSH+pVKaDXgwWeL9HeU/7Li/dwqwW7WZuyE2cX2nd55f27tUw6z224QBx qSlOU74AsPfwQhjGoSubfaBjwpDf9ocbljM7/D/D9GCGOe17D+pin7ZukJMK1pML TAlbrChN4nM5MR9SzqchbOno5mmtx0mWT7aK9nZtXdbmHXeIKQNTC3bSrSMMYS2Z dYGNPOaXArt+OQG786zmo2+k1h9qkRpasukh5173jBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=T9EkUp PqopC5ZZ6ooqDzSOnafLYCu40QWiqc1qKvXHA=; b=QNhTQaBb7SEcedAOwjgCKY Ly0J7epQ9BC7yHR+yH9JshzQVc8CwXeXno7g/sWPTAD3QHPYByC7MWIpW8m0vOOD zhop0p6Fzoy3fTbl5AfecCYJ5XG7gKIs+/wI5V0DpmdOJeX+3A90Nd/8uxGqeNtu IowfWOQGBATgHCppPQKQAuDh5lEpx9unx49IoDnLn7M42Th7Gtk4F9ptNSSkUkum dDypa0bY4jRwuF/ti1YIO+oNzmAT4wOVEqxa7lSXpLthlpEIEHEhEGByekaaj/Os XuEeRefizYoyaUaq/XnY/fRzxpoFPdvrJSerYhb5r34Ry0vtCjBcUDWzRAQbww3A == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehuddgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpefrvghtvghr ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg hrnhephefgvdevtefhveelieejheekudehjeefheefhfefhfefieejtdevleevjeeutddu necuffhomhgrihhnpehgihhthhhusgdrtghomhdpphgvthgvrhhtohguugdrohhrghenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehushgvrhes phgvthgvrhhtohguugdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 10 Jan 2022 13:24:00 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id A11EA5FB59; Sun, 9 Jan 2022 06:38:15 -0500 (EST) Date: Sun, 9 Jan 2022 06:38:15 -0500 From: Peter Todd To: Michael Folkson , Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kZHE2y8BvTu2Atxo" Content-Disposition: inline In-Reply-To: Subject: Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt 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: Mon, 10 Jan 2022 18:30:59 -0000 --kZHE2y8BvTu2Atxo Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 03, 2022 at 02:05:20AM +0000, Michael Folkson via bitcoin-dev w= rote: > There have been a number of =E2=80=9Csoft signals=E2=80=9D, many expressi= ng enthusiasm for the speculated use cases of OP_CTV. Personally I share th= at enthusiasm like I do with the prospect of curing cancer. But these soft = signals seem as if they are going to be used to attempt to justify an immin= ent contentious soft fork attempt. The devil is in the details both with re= gards to wording like =E2=80=9Creasonable parameters=E2=80=9D and the utili= ty and safety of a new opcode. Indeed if you share my concerns that there h= as not been sufficient scrutiny and research on the long implications of th= is proposal I encourage you to register a soft signal of =E2=80=9CNo=E2=80= =9D on the site like I have. You can always change it to =E2=80=9CYes=E2=80= =9D if and when you support an imminent soft fork activation attempt contai= ning exclusively OP_CTV. Enabling covenants on Bitcoin is a big step change= with barely any existing research on the topic and attempting to rush it t= hrough by the back door so soon after Taproot activation should be resisted= =2E To look at the ~200 lines of code for the opcode exclusively (of course= this should be done too) in a vacuum without considering the broader impli= cations is also incredibly shortsighted. The only thing stopping a descent = into Ethereum style seat of our pants consensus changes is community vigila= nce. If we ever lose that we lose the foundation of this industry. I have to second your objections. I spent a bit of time over the past week looking at the current state of OP_CTV/BIP-0119, and I too think it's a premature idea with an insufficient= BIP and reference implementation, that current lacks compelling use-cases clear= ly beneficial to all users. Remember that Bitcoin is a nearly $1 trillion network with tens of millions= of users that has gotten to that point with careful, conservative engineering. Every change to the protocol poses risks to those users. Previous feature upgrades to the Bitcoin protocol have always been done with the intent of improving the protocol for everyone: CSV/segwit benefit all users via Lightning, because we can reasonably all users to directly take advantage of those features. We expect _everyone_ to benefit from Taproot via improved privacy. I don't think CTV in its current form makes that case sufficiently, and the technical details are lacking. As for some more detailed thoughts, for clarify, I'm referring to: https://github.com/bitcoin/bips/blob/3693cdfd192dacdac89cd742f68cd1bb96bf7f= 7e/bip-0119.mediawiki https://github.com/JeremyRubin/bitcoin/tree/8f313d292e426a74d9ce28e5130bbf0= cd48f867e By no means is this a complete list of issues: # DoS Attacks Note how above I cited the git hashes to make it clear what exactly I'm referring too: the fact that the reference implementation is listed as https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify in the BIP = is an immediate problem, as it's not clear what exactly is the specification. This in turn matters quite a lot, because the BIP itself glosses over the q= uite serious DoS attack issues involved in adding more ways that opcodes can hash txs. Strong resistance to DoS attacks is a _mandatory_ aspect of all Bitcoin script proposals, so leaving those details to a mostly uncommented reference implementation without a clear discussion of those trade-offs is insufficie= nt. # Use Cases As Folkson notes, these are barely fleshed out: ## Congestion Controlled Transactions While this section appears somewhat fleshed out, with even a simulation, it completely ignores the numerous practical issues like the need for communication channels between wallets to inform them of the existence of t= hese batches. It also raises an important question: who needs this? On-chain transactions are clearly not the future of Bitcoin and this use-case will likely impact a small % of users. ## Wallet Vaults This use-case can be easily tested, even in production, right now with additional "oracle" signers that simply verify the CTV rules have been followed. ## Payment Channels These use-cases sound promising. But they all need to be clearly fleshed ou= t as actually taking advantage of them is quite complex. ## CoinJoin > because participants agree on a single output which pays all participants, > which will be lower fee than before It is not clear how the fee will be lower, given that taking advantage of C= TV means there are more transactions, not less. # Covenant Design Trade-Offs and Risks > Covenants have historically been controversial given their potential for > fungibility risks -- coins could be minted which have a permanent restric= tion > on how they may or may not be spent or required to propagate metadata. Indeed, this is a significant risk with the potential to harm all Bitcoin users. > In the CHECKTEMPLATEVERIFY approach, the covenants are severely restricte= d to > simple templates. The structure of CHECKTEMPLATEVERIFY template is such t= hat > the outputs must be known exactly at the time of construction. Based on a > destructuring argument, it is only possible to create templates which exp= and > in a finite number of steps. Thus templated transactions are in theory as > safe as transactions which create all the inputs directly in this regard. The "finite" number of steps could be millions of transactions - "infinitely long" for any practical purpose. # Test Vectors Currently the testing is poorly documented, without clear goals as to what = edge cases are actually being tested: https://github.com/JeremyRubin/bitcoin/commit/e026bae28a774d91effc32862d024= 6286c114c24 Also, we really need test _vectors_ rather than a Python test: for consenus, you want to write down explicitly the *data* in the form of serialized transactions that is being fed into the consensus engine, to avoid mistakes= in test coverage due to broken test harnesses. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --kZHE2y8BvTu2Atxo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmHcebUACgkQLly11TVR LzcrOQ/+NaEtcjA/MekvLsOGfXkrtn8DjCUeiibHfeNDfCNHANaecB2ztWjqiKZl iYcyXt3JvG164wqjOBOm0KtETsMeDYl2jnBXrZxDVRLAd4dXNR3NCfq/V0eF3SeC UA4znuLuo9lsf/F+FgsXeLLOB/hDHgo+5CR7c+2v5ZD+F+erealKXT2/nGq/2E44 6i1ObA94fM5IJrXQW+TweYUwfAIFsgN2aZ5LppAqTOuyLt3GmX0HnUM5f1vEkBtu NZSccyKPshyL/7wgPFDlOkmkvlbKez4hwNde19fYPbK8rvmwcq7BxsVvHtcmM4Qy 9mu0E1G4j/yjvVy6Pom3SJecUwhmGmWcvX55mWe60+/BenPZzZgXeyCJFK2YzmKd /Ce9AEQRnEWymRLDZ6hp+QE9e2Ppz9oyimYoioQA9YOW4YsS0T5ou+iA2ZgRIX0j bM+6pjGVAiY+0xv+FKjfRMsLjvWyrHutzDZi4HjCvXjgLK9GAQZSHbMg417YaDKj VpJ/65cJ+BK7rUgf8UD3lw/mil1TYJ2ePHQWJJJSOinLR4ubWWRBSWLEhF+uyX9U cnGzitd6wqkO1CO/rt9bIBE8OnEVv1H/DlB7XCuPZ8GJozUQamiU5KB+jCBu+c82 V1acqQo5Zy35sn2aAHPdlRtrMSBslD8mTBI1XK0EKcJ8dWQM+Qo= =3nZQ -----END PGP SIGNATURE----- --kZHE2y8BvTu2Atxo--