Re: [bitcoin-dev] Bitcoin covenants are inevitable

From: alicexbt <alicexbt@protonmail•com>
To: Anthony Towns <aj@erisian•com.au>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Date: Tue, 19 Jul 2022 14:46:46 +0000	[thread overview]
Message-ID: <qWMGp9hI6axlYCNSP9tCj3IYbFQfATUQFciviuz94saFXaeFH0t7fNSnieTCmNEhC9gyz3zjvLrb-DdnoQ6XzzxPcrt4gX9meCN_1mHtvvs=@protonmail.com> (raw)
In-Reply-To: <20220719044458.GA26986@erisian.com.au>

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 debatable. Most UTXOs are already distinguishable from another.

> 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.

Could rebranding the term 'covenants' help in sharing the benefits of related proposals for bitcoin? According to Greg Maxwell's [comment][2] on reddit, 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 about.

[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 <bitcoin-dev@lists•linuxfoundation.org> 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 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev