From: Anthony Towns <aj@erisian•com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Date: Tue, 19 Jul 2022 14:44:58 +1000 [thread overview]
Message-ID: <20220719044458.GA26986@erisian.com.au> (raw)
In-Reply-To: <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@protonmail.com>
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
next prev parent reply other threads:[~2022-07-19 4:45 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 18:39 alicexbt
2022-06-04 0:29 ` micaroni
2022-06-04 18:43 ` Jorge Timón
2022-06-05 4:18 ` alicexbt
2022-06-08 3:51 ` Billy Tetrud
2022-06-08 9:22 ` Jorge Timón
2022-06-09 4:30 ` Billy Tetrud
2022-06-09 0:03 ` Ryan Grant
2022-07-19 4:44 ` Anthony Towns [this message]
2022-07-19 14:46 ` alicexbt
[not found] <mailman.9.1654344003.14400.bitcoin-dev@lists.linuxfoundation.org>
2022-06-04 12:27 ` John Carvalho
2022-06-04 13:48 ` Keagan McClelland
2022-06-04 16:12 ` alicexbt
2022-06-06 13:02 ` Erik Aronesty
2022-06-12 3:36 ` Peter Todd
2022-06-12 13:02 ` Erik Aronesty
2022-06-12 16:35 ` Corey Haddad
2022-06-12 19:16 ` alicexbt
2022-06-19 10:31 ` Peter Todd
2022-06-19 15:54 ` Manuel Costa
2022-06-19 18:26 ` Kate Salazar
2022-06-19 22:35 ` Erik Aronesty
2022-06-21 19:00 ` Keagan McClelland
2022-06-21 20:10 ` Eric Voskuil
2022-06-23 19:17 ` Peter Todd
2022-06-28 3:55 ` Billy Tetrud
2022-06-28 16:23 ` Alex Lee
2022-06-28 23:22 ` Peter Todd
2022-06-29 5:02 ` Alex Lee
2022-06-28 23:20 ` Peter Todd
2022-06-29 10:44 ` Kate Salazar
2022-06-30 15:25 ` Billy Tetrud
2022-07-03 9:43 ` Peter Todd
2022-07-03 10:30 ` Giuseppe B
2022-07-06 4:28 ` Corey Haddad
2022-07-06 11:10 ` vjudeu
2022-07-07 0:46 ` Billy Tetrud
2022-07-07 12:15 ` vjudeu
2022-07-07 14:05 ` Erik Aronesty
2022-07-07 14:10 ` Giuseppe B
2022-07-08 5:03 ` Billy Tetrud
2022-06-30 17:04 ` Erik Aronesty
[not found] <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org>
2022-07-07 13:24 ` John Carvalho
2022-07-07 14:12 ` Peter Todd
2022-07-07 16:24 ` Eric Voskuil
2022-07-07 17:37 ` Erik Aronesty
2022-07-07 19:57 ` Eric Voskuil
2022-07-07 21:11 ` Erik Aronesty
2022-07-08 0:28 ` Eric Voskuil
2022-07-08 4:59 ` vjudeu
2022-07-08 7:26 ` John Carvalho
2022-07-08 15:14 ` Erik Aronesty
2022-07-14 4:55 ` Billy Tetrud
2022-07-07 22:06 ` Anthony Towns
2022-07-07 22:02 ` Corey Haddad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220719044458.GA26986@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox