path: root/77/8756c1d51181b568f4d66534cdc6418c2473ed

Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3F950C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220719044458.GA26986@erisian.com.au>
References: <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@protonmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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