path: root/33/e1d334ef63baef1476694a37e5ddea4c382acd

Return-Path: <alicexbt@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 40A07C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <aj@erisian.com.au>
From: alicexbt <alicexbt@protonmail.com>
Reply-To: alicexbt <alicexbt@protonmail.com>
Message-ID: <qWMGp9hI6axlYCNSP9tCj3IYbFQfATUQFciviuz94saFXaeFH0t7fNSnieTCmNEhC9gyz3zjvLrb-DdnoQ6XzzxPcrt4gX9meCN_1mHtvvs=@protonmail.com>
In-Reply-To: <20220719044458.GA26986@erisian.com.au>
References: <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@protonmail.com>
 <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 <bitcoin-dev@lists.linuxfoundation.org>
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 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 <bit=
coin-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 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