path: root/53/7e48b425455dc6c2362f7f1f85bf10805d0876

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4DBE6C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Jul 2021 20:51:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 1FEEC40420
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Jul 2021 20:51:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 vmxVN46ueSz3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Jul 2021 20:51:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [IPv6:2a00:1450:4864:20::62f])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 9C27540416
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Jul 2021 20:51:02 +0000 (UTC)
Received: by mail-ej1-x62f.google.com with SMTP id b2so25823448ejg.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 04 Jul 2021 13:51:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=7bqUX17Ew5WIIlk1pjcRirr/qoqWJZRpIG4Yx6gyNO0=;
 b=nuyfwegbDHqj0ASlOXFO7+4tLmE3GIiLbMpuUs8Rdtg/vIPVapHlLvugytpEAqtBI9
 bWGv8W6cs5jiFMGXq9Ym4tK5FmRWUmcKwOa2HJbpvPuUlDV+eBspQfuiVsxYJlblvyt3
 QwRRLKrSBTi3jbwDw80ni4IcDeirZCkk7+8/T5mkijyD51+STRsW52D8l78xXU0C8ss2
 9cr23ueuZjVU1DL0AKn2V3nd3hN/JZK+86krxN3+MK2Iv65KCfOf8jhm5dbRUzVDnvie
 OuUql6XgI9xOQBCgDHAuLqf6Q3BaPwT6Toea8wOpw3/QnssxBfwaMFs0/VN6mB+CnvfT
 YvGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=7bqUX17Ew5WIIlk1pjcRirr/qoqWJZRpIG4Yx6gyNO0=;
 b=piC5emdpZwZDahNoCKjE6Oik2zc/G/TZco2Qzl6gxXiAlZxq9Nx3K3tuKDB3rYK/1I
 ki+UIiYvLSMnji4408txSEY3UETlqbMwEl2cVIisyCOzDXHnt+pxvEUKXysilD4SFmZb
 OAoDbZew6bBiLRdHmBtRoPTrfQEikVFaiEJPsAwCcxtzYJ8kLyPhBLBelq/OLqIfOpCJ
 ELtl5hAlKjKd+3QsMlY3EARVANowt88AennkYCAyOfC6HHc02UbNYTpmQoktoj3nvbqd
 h6joLtbvWn7GPqcdweB0ryjxLGajOK3mVhdgaCa2mspquvemQ1o9o5VGmxsDUttC9Ptu
 PT4g==
X-Gm-Message-State: AOAM533s1/lgnYc5iLw+CKWNFTNXD9ag5glLtGGkvwCQZ7PsszX8IGyh
 KY/4xw/+tpAxPa1TYO2gbJ8hcQHtYGr0fnvz0SYYvb5UnGLpHg==
X-Google-Smtp-Source: ABdhPJxmXEcoyimBAy6Cuqa8EynWPiF8qwamZKmPOgI0ffVgQS6SaE0Swfpy+rliN3IPGmZd39YPH+WNVtsLDqRxYn8=
X-Received: by 2002:a17:906:2b85:: with SMTP id
 m5mr10121011ejg.141.1625431860761; 
 Sun, 04 Jul 2021 13:51:00 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjmu-Eee47Ho5eA6E6+aAdnchLU0OVZo=RTHaXnN17x8A@mail.gmail.com>
 <20210704011341.ddbiruuomqovrjn6@ganymede>
 <CAD5xwhimPBEV_tLpSPxs9B+XGUhvPx_dnhok=8=hyksyi4=B6g@mail.gmail.com>
 <20210704203230.37hlpdyzr4aijiet@ganymede>
In-Reply-To: <20210704203230.37hlpdyzr4aijiet@ganymede>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 4 Jul 2021 13:50:43 -0700
Message-ID: <CAGpPWDbUs01-Q=5F5Tw3biGwPRnH5kwNd6v=bdRGLG0HihqtXA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000aadbad05c652586c"
X-Mailman-Approved-At: Sun, 04 Jul 2021 21:17:52 +0000
Subject: Re: [bitcoin-dev] Unlimited covenants,
 was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
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: Sun, 04 Jul 2021 20:51:06 -0000

--000000000000aadbad05c652586c
Content-Type: text/plain; charset="UTF-8"

I agree with you David. I think rather unconstrained covenants are
incredibly useful and important. Yes you can burn coins with them, you can
also permanently limit the usability of certain coins (which is less
destructive than burning them). But as Jeremy said, people are free to burn
their coins. People would also be free (in general) to reject coins
encumbered by weird government provisions or unknown provisions in hidden
scripts. A person/wallet shouldn't accept coins encumbered by scripts it
doesn't recognize.

Even if 99% of bitcoins became permanently encumbered by weird covenants,
the other 1% could still be plenty of bitcoins to run the economy, because
of its potentially infinite divisibility. Losing these coins, or someone
basically turning them into altcoin-like bitcoins shouldn't be a concern
really. What's the risk exactly? That people will be forced to take these
encumbered coins? A government can already force people to take whatever
altcoin they want to force on people - covenants don't make this worse.

Shinobi asks: "What if you extorted users with your 51% attack to move into
those?"

Well, you could do this anyway even without covenants existing already. The
51% attack could simply extort people to use whatever rules they want just
as easily (which isn't to say that easily - most users would probably
refuse to be extorted in either case). So I don't really think this is very
valid.

On Sun, Jul 4, 2021 at 1:33 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote:
> > However, I think the broader community is unconvinced by the cost benefit
> > of arbitrary covenants. See
> >
> https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6
> > as a recent example. Therefore as a critical part of building consensus
> on
> > various techniques I've worked to emphasize that specific additions do
> not
> > entail risk of accidentally introducing more than was bargained for to
> > respect the concerns of others.
>
> Respecting the concerns of others doesn't require lobotomizing useful
> tools.  Being respectful can also be accomplished by politely showing
> that their concerns are unfounded (or at least less severe than they
> thought).  This is almost always the better course IMO---it takes much
> more effort to satisfy additional engineering constraints (and prove to
> reviewers that you've done so!) than it does to simply discuss those
> concerns with reasonable stakeholders.  As a demonstration, let's look
> at the concerns from Shinobi's post linked above:
>
> They seem to be worried that some Bitcoin users will choose to accept
> coins that can't subsequently be fungibily mixed with other bitcoins.
> But that's already been the case for a decade: users can accept altcoins
> that are non-fungible with bitcoins.
>
> They talk about covenants where spending is controlled by governments,
> but that seems to me exactly like China's CBDC trial.
>
> They talk about exchanges depositing users' BTC into a covenant, but
> that's just a variation on the classic not-your-keys-not-your-bitcoins
> problem.  For all you know, your local exchange is keeping most of its
> BTC balance commitments in ETH or USDT.
>
> To me, it seems like the worst-case problems Shinobi describes with
> covenants are some of the same problems that already exist with
> altcoins.  I don't see how recursive covenants could make any of those
> problems worse, and so I don't see any point in limiting Bitcoin's
> flexibility to avoid those problems when there are so many interesting
> and useful things that unlimited covenants could do.
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000aadbad05c652586c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree with you David. I think rather unconstrained coven=
ants are incredibly useful and important. Yes you can burn coins with them,=
 you can also permanently=C2=A0limit the usability of certain coins (which =
is less destructive than burning them). But as Jeremy said, people are free=
 to burn their coins. People would also be free (in general) to reject coin=
s encumbered by weird government provisions or unknown provisions in hidden=
 scripts. A person/wallet shouldn&#39;t accept coins encumbered by scripts =
it doesn&#39;t recognize.<div><br></div><div>Even if 99% of bitcoins became=
 permanently encumbered by weird covenants, the other 1% could still be ple=
nty of bitcoins to run the economy, because of its potentially infinite div=
isibility. Losing these coins, or someone basically turning them into altco=
in-like bitcoins shouldn&#39;t be a concern really. What&#39;s the risk exa=
ctly? That people will be forced to take these encumbered coins? A governme=
nt can already force people to take whatever altcoin they want to force on =
people - covenants don&#39;t make this worse.</div><div><br></div><div>Shin=
obi asks: &quot;What if you extorted users with your 51% attack to move int=
o those?&quot;</div><div><br></div><div>Well, you could do this anyway even=
 without covenants existing already. The 51% attack could simply extort peo=
ple to use whatever rules they want just as easily (which isn&#39;t to say =
that easily - most users would probably refuse to be extorted in either cas=
e). So I don&#39;t really think this is very valid.=C2=A0</div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jul =
4, 2021 at 1:33 PM David A. Harding via bitcoin-dev &lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote:<br>
&gt; However, I think the broader community is unconvinced by the cost bene=
fit<br>
&gt; of arbitrary covenants. See<br>
&gt; <a href=3D"https://medium.com/block-digest-mempool/my-worries-about-to=
o-generalized-covenants-5eff33affbb6" rel=3D"noreferrer" target=3D"_blank">=
https://medium.com/block-digest-mempool/my-worries-about-too-generalized-co=
venants-5eff33affbb6</a><br>
&gt; as a recent example. Therefore as a critical part of building consensu=
s on<br>
&gt; various techniques I&#39;ve worked to emphasize that specific addition=
s do not<br>
&gt; entail risk of accidentally introducing more than was bargained for to=
<br>
&gt; respect the concerns of others.<br>
<br>
Respecting the concerns of others doesn&#39;t require lobotomizing useful<b=
r>
tools.=C2=A0 Being respectful can also be accomplished by politely showing<=
br>
that their concerns are unfounded (or at least less severe than they<br>
thought).=C2=A0 This is almost always the better course IMO---it takes much=
<br>
more effort to satisfy additional engineering constraints (and prove to<br>
reviewers that you&#39;ve done so!) than it does to simply discuss those<br=
>
concerns with reasonable stakeholders.=C2=A0 As a demonstration, let&#39;s =
look<br>
at the concerns from Shinobi&#39;s post linked above:<br>
<br>
They seem to be worried that some Bitcoin users will choose to accept<br>
coins that can&#39;t subsequently be fungibily mixed with other bitcoins.<b=
r>
But that&#39;s already been the case for a decade: users can accept altcoin=
s<br>
that are non-fungible with bitcoins.<br>
<br>
They talk about covenants where spending is controlled by governments,<br>
but that seems to me exactly like China&#39;s CBDC trial.<br>
<br>
They talk about exchanges depositing users&#39; BTC into a covenant, but <b=
r>
that&#39;s just a variation on the classic not-your-keys-not-your-bitcoins<=
br>
problem.=C2=A0 For all you know, your local exchange is keeping most of its=
<br>
BTC balance commitments in ETH or USDT.<br>
<br>
To me, it seems like the worst-case problems Shinobi describes with<br>
covenants are some of the same problems that already exist with<br>
altcoins.=C2=A0 I don&#39;t see how recursive covenants could make any of t=
hose<br>
problems worse, and so I don&#39;t see any point in limiting Bitcoin&#39;s<=
br>
flexibility to avoid those problems when there are so many interesting<br>
and useful things that unlimited covenants could do.<br>
<br>
-Dave<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000aadbad05c652586c--