From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 40A07C002D for ; Tue, 19 Jul 2022 14:46:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 14561410A9 for ; Tue, 19 Jul 2022 14:46:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 14561410A9 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=Rg7wT081 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-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 rMn2Putbq3SI for ; Tue, 19 Jul 2022 14:46:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org F208C401D3 Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25]) by smtp4.osuosl.org (Postfix) with ESMTPS id F208C401D3 for ; Tue, 19 Jul 2022 14:46:55 +0000 (UTC) Date: Tue, 19 Jul 2022 14:46:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1658242013; x=1658501213; bh=e9PzBsQcILc2dWSRclUl0RmHLCZOLXWa55xMpp1Muf0=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=Rg7wT081yPuq7DXrYWPljtlJfS0+8JmE3xIvUW2ByRwgqpxcuvheKQ3RjFyRRbglv BiPOhq9jSGuFeMcJHARXydafpQKH7GSe/JkCNonz19GOjV4RL85ZVOl0UymU1FWnw4 oS3rQ9VhujtH1Zdu1c0aysZGMCI8rlmwXoJuG+mKiGt0VZSpX11TCmPRGkCjukpJy6 8Y0Ck2QzLH/o8wgxra+etuxFNPaiEogqrNYBG5k381KzvglmDFJHbOHPmhCrJvxXGH vf/wr4sWwWp2ikmKugd/1CacZQVuFoE2LXBiomOpVtZpdQ9j2xXL0xhiFybX6KiM8R 8JQybUKdPDIbQ== To: Anthony Towns From: alicexbt Reply-To: alicexbt Message-ID: In-Reply-To: <20220719044458.GA26986@erisian.com.au> References: <20220719044458.GA26986@erisian.com.au> Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 19 Jul 2022 16:05:45 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable 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, 19 Jul 2022 14:46:58 -0000 Hi Anthony, > The issue is whether we should allow such > soft forks, or if the danger of losing coins to covenants and thus > losing fungibility and the freedom to transact is too much of a risk, > compared to whatever benefits the soft fork would bring. There are so many ways to lose coins and [fungibility][1] of bitcoin is deb= atable. Most UTXOs are already distinguishable from another. > that. Presumably we at least don't need to worry about somehow introducin= g > racist opcodes in bitcoin, but if you're wondering why covenants are > controversial, their historical use is relevant. Could rebranding the term 'covenants' help in sharing the benefits of relat= ed proposals for bitcoin? According to Greg Maxwell's [comment][2] on reddi= t, he came up with the term as applied in bitcoin. > But that isn't what anyone's trying to do here. What we're trying to > do is add temporary conditions that allow us to do smarter things than > we currently can while the coin remains in our ownership -- for example > protecting our own money by putting it in a "vault", or pooling funds > with people we don't entirely trust. Agree. > In particular, when purchasing real estate, you > may have to do numerous legal searches to be sure that there isn't a > covenant, easement or other encumbrance on your property; in bitcoin, > you decide the exact set of encumbrances that will be placed on your > coins when you create the receiving address that you use, and once the > address is chosen, those conditions are fixed. Agree and users should be free to add conditions to the coins they own. > I think I'm going to go with talking about these features as enabling > "transaction introspection" [4] [5] [6] (or "output introspection") > instead -- that is, the ability for a script or witness from the input of > a transaction to specify that the validator needs to examine components > of the transaction itself (particularly its own outputs -- the value > or the scriptPubKey or both), and ensure that some set of requirements > imposed by the script/witness is fulfilled. Interesting perspective and maybe this is the rebranding I was thinking abo= ut. [1]: https://en.wikipedia.org/wiki/Fungibility [2]: https://www.reddit.com/r/Bitcoin/comments/uim560/comment/i7dhfpb/ /dev/fd0 Sent with Proton Mail secure email. ------- Original Message ------- On Tuesday, July 19th, 2022 at 10:14 AM, Anthony Towns via bitcoin-dev wrote: > On Fri, Jun 03, 2022 at 06:39:34PM +0000, alicexbt via bitcoin-dev wrote: > > > Covenants on bitcoin will eventually be implemented with a soft fork. > > > That's begging the question. The issue is whether we should allow such > soft forks, or if the danger of losing coins to covenants and thus > losing fungibility and the freedom to transact is too much of a risk, > compared to whatever benefits the soft fork would bring. > > > Why covenants are not contentious? > > > I think this actually misses the point: covenants are "contentious" > because that term is usually used to describe a concept that's utterly > counter to the point of bitcoin as a monetary instrument. We've taken > the term and applied it for something that's different in key ways, > which just ends up confusing and misleading. > > Using a traditional meaning, a "covenant" is an "agreement" but with > an implication of permanency: whether that's because you're making a > covenant with God that will bind your children and their children, or > you're putting a covenant on your property that "runs with the land", eg: > > """A covenant is said to run with the land in the event that the covenant > is annexed to the estate and cannot be separated from the land or the lan= d > transferred without it. Such a covenant exists if the original owner as > well as each successive owner of the property is either subject to its > burden or entitled to its benefit.""" [0] > > [0] https://legal-dictionary.thefreedictionary.com/covenant > > Sometimes people talk about "recursive covenants" in bitcoin, which > I think is intended to imply something similar to the "runs with the > land" concept above. But recursion in programming generally terminates > (calculating "Fib(n) :=3D if (n <=3D 1) then 1 else Fib(n-1) + Fib(n-2)" > eg), while covenants that run with the land are often unable to be > removed. I think a better programming analogy would be "non-terminating"; > so for example, CTV is "recursive" in the sense that you can nest one > CTV commitment inside another, but it does terminate, because you can > only nest a finite number of CTV commitments inside another, due to > computational limits. > > Covenants even have a racist history in the US (because of course they > do), apparently, with covenants along the lines of "None of said land > may be conveyed to, used, owned, or occupied by negroes as owners or > tenants" [1] having been in use. Such covenants have apparently been > ruled uneforcable by the Supreme Court, but apparently are nevertheless > often difficult or impossible to remove from the property despite > that. Presumably we at least don't need to worry about somehow introducin= g > racist opcodes in bitcoin, but if you're wondering why covenants are > controversial, their historical use is relevant. > > [1] https://www.npr.org/2021/11/17/1049052531/racial-covenants-housing-di= scrimination > > Covenants are specifically undesirable if applied to bitcoin because they > break fungibility -- if you have some covenant that "runs with the coin", > then it's no longer true to say "1 BTC =3D 1 BTC" if such a covenant mean= s > the one of the left can't be used for a lightning channel or the one on > the right can't be used to back an asset on eth or liquid. > > But that isn't what anyone's trying to do here. What we're trying to > do is add temporary conditions that allow us to do smarter things than > we currently can while the coin remains in our ownership -- for example > protecting our own money by putting it in a "vault", or pooling funds > with people we don't entirely trust. > > That often requires recursion in the first place (so that the vault or > the pool doesn't disappear after the first transaction). And from there, > it can be easy to prevent the recursion from terminating and turn what > would otherwise be a temporary condition into a permanent one. That > was theoretically interesting in 2013 [2], and remains so today [3], > but it isn't something that's desirable to apply to bitcoin. > > [2] https://bitcointalk.org/index.php?topic=3D278122.0 > [3] https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html > > That is: even if it becomes possible to create permanent non-terminating > covenants that run with a coin on bitcoin, that isn't something you > should do, and if you do, people should not (and almost certainly will > not) accept those coins from you, unless you first find a way to remove > that covenant. > > One significant difference between real estate covenants and anything > we might have on bitcoin is the ability to be sure that once you receive > ownership of bitcoin, that that ownership does not come with encumbrances > you're unaware of. In particular, when purchasing real estate, you > may have to do numerous legal searches to be sure that there isn't a > covenant, easement or other encumbrance on your property; in bitcoin, > you decide the exact set of encumbrances that will be placed on your > coins when you create the receiving address that you use, and once the > address is chosen, those conditions are fixed. (Though to be fair, they > could reference external things, such as an oracle, which could change) > > So, all in all, I think we should stop describing these features we're > thinking about adding with the word that's mainly used for the single > most inappropriate and undesirable use case for them. > > I think I'm going to go with talking about these features as enabling > "transaction introspection" [4] [5] [6] (or "output introspection") > instead -- that is, the ability for a script or witness from the input of > a transaction to specify that the validator needs to examine components > of the transaction itself (particularly its own outputs -- the value > or the scriptPubKey or both), and ensure that some set of requirements > imposed by the script/witness is fulfilled. > > [4] eg https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/= 020735.html > [5] compare with https://en.wikipedia.org/wiki/Type_introspection > [6] see also https://github.com/ElementsProject/elements/blob/master/doc/= tapscript_opcodes.md > > Note that signatures already involve transaction/output introspection: > SIGHASH_ALL and SIGHASH_SINGLE impose the requirement that one or all > outputs hash to some particular value, and validators obviously must > check that requirement when validating signatures. That we already have > this feature is why seemingly unrealted opcodes like CAT (or SUBSTR or > SHA256STREAM) could also enable covenants in bitcoin. > > The CLTV and CSV opcodes also do transaction introspection, though not > output introspection as they only examine the tx header (nlocktime) > and the current input (nsequence). > > Cheers, > aj > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev