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 3F950C002D for ; Tue, 19 Jul 2022 04:45:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 04DCB40B3B for ; Tue, 19 Jul 2022 04:45:10 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 04DCB40B3B X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 4kv9WXmqAd_5 for ; Tue, 19 Jul 2022 04:45:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8983E405F3 Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp2.osuosl.org (Postfix) with ESMTPS id 8983E405F3 for ; Tue, 19 Jul 2022 04:45:08 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1oDf6V-0002ZP-1b for ; Tue, 19 Jul 2022 14:45:05 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Tue, 19 Jul 2022 14:44:58 +1000 Date: Tue, 19 Jul 2022 14:44:58 +1000 From: Anthony Towns To: Bitcoin Protocol Discussion Message-ID: <20220719044458.GA26986@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score-int: -18 X-Spam-Bar: - 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 04:45:10 -0000 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 land 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) := if (n <= 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 introducing 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-discrimination 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 = 1 BTC" if such a covenant means 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=278122.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