path: root/e9/2395a4b098c154510f8a0a5f256378d324db6e

Return-Path: <roconnor@blockstream.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 32115C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jul 2021 01:02:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 0D1A840405
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jul 2021 01:02:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 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=blockstream-com.20150623.gappssmtp.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 CHUlDBpVXpOy
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jul 2021 01:02:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com
 [IPv6:2607:f8b0:4864:20::72a])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 0DEAE40403
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jul 2021 01:02:37 +0000 (UTC)
Received: by mail-qk1-x72a.google.com with SMTP id f6so15566698qka.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 04 Jul 2021 18:02:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=JlysbPEX3B6X6QIWnRkeaHCpijzq10FidR3e5yHE3s4=;
 b=lVCoUz6NaLtgt7QlocaBRQObsTDYkvHjlaLrvt0HYIDbTJJ7rUcLmy/8aMgm6rAWW/
 ghzTW0yXHI+aIlRjjzRk0+Aj1WuAY5Zd3G18QTmbqaD2yhSfd7RRERG29JiwqRx9KB0l
 JD8WFZdAbqUUJg6k4vUWovg7Ajea0P35V8DUynj3m9ML+3M0JTObborFMTRz8duECNP2
 B/uYqu30uMm1GRTVzxrlhMLKJ8ERvyjOu7ocbeKetH8/n/w9RBCFc9OyiZqBX2d6hq8u
 SSuIxl7C/YOXvLH97DSxve1LLxTwLT9P3jIHc3yHaowOQAcAudbfn0PtJwUwTD9OcQRR
 4S5w==
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=JlysbPEX3B6X6QIWnRkeaHCpijzq10FidR3e5yHE3s4=;
 b=W3K6iQpMUTh0liiM90g8D+blr49J9IWvELJg5cc+K3bPCHu3RI7XVJax0vw/3mbsKX
 Bm2G9+seBPUameEeGLrFVHYkbwajXmFzKHaupE32KDYO4uoVbBPJZjxUHBrRmtK8MJez
 bGImy3DUogIDJUEcp8Lqxmbl0yzy2z7icNs8j6Wm1QIvJQIOycITukYWDKsahiD0JPOB
 a+9vTelGhKTShg1JRTwEN0NYkTBTZ6v1/ei4IVIpmdH4i01TM6QJYp6GMLrZzZ5PdeH/
 q8TcevMYLlTl1MpnLFzhMFDBiZ74hBl9ITD3SULbU51i+xyE8UUqKzv//W5n5oeHLUc9
 RRdg==
X-Gm-Message-State: AOAM53204t+NvNykzZ88itKGxyNIWK9BX4Kpk2gWy3IzIGt/4Adgfhy5
 6EWpNIMdkA3tHcrwVWCFH6sXHuPuaFB0duS9EpCuhA==
X-Google-Smtp-Source: ABdhPJzn95abhP9OJCAI9qUqH9szoVFp/SMJwddY46dLp+I+GXNT3kIXl74OeL5WlOGoWmiNrm+LLYiBvtumzL1axfQ=
X-Received: by 2002:a05:620a:19a2:: with SMTP id
 bm34mr10312690qkb.330.1625446956527; 
 Sun, 04 Jul 2021 18:02:36 -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>
 <5keA_aPvmCO5yBh_mBQ6Z5SwnnvEW0T-3vahesaDh57f-qv4FbG1SFAzDvT3rFhre6kFl282VsxV_pynwn_CdvF7fzH2q9NW1ZQHPH1pmdo=@protonmail.com>
In-Reply-To: <5keA_aPvmCO5yBh_mBQ6Z5SwnnvEW0T-3vahesaDh57f-qv4FbG1SFAzDvT3rFhre6kFl282VsxV_pynwn_CdvF7fzH2q9NW1ZQHPH1pmdo=@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Sun, 4 Jul 2021 21:02:25 -0400
Message-ID: <CAMZUoKnVLRLgL1rcq8DYHRjM--8VEUC5kjUbzbY5S860QSbk5w@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000072054605c655dc7c"
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: Mon, 05 Jul 2021 01:02:40 -0000

--00000000000072054605c655dc7c
Content-Type: text/plain; charset="UTF-8"

Bear in mind that when people are talking about enabling covenants, we are
talking about whether OP_CAT should be allowed or not.

That said, recursive covenants, the type that are most worrying, seems to
require some kind of OP_TWEAK operation, and I haven't yet seen any
evidence that this can be simulated with CHECKSIG(FROMSTACK).  So maybe we
should leave such worries for the OP_TWEAK operation.

On Sun, Jul 4, 2021 at 8:51 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Dave,
>
> > 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.
>
> The "altcoins are even worse" argument does seem quite convincing, and if
> Bitcoin can survive altcoins, surely it can survive covenants too?
>
> In before "turns out covenants are the next ICO".
> i.e. ICOs are just colored coins, which are useful for keeping track of
> various stuff, but have then been used as a vehicle to scam people.
> But I suppose that is a problem that humans will always have: limited
> cognition, so that *good* popular things that are outside your specific
> field of study are indistinguishable from *bad* popular things.
> So perhaps it should not be a concern on a technical level.
> Maybe we should instead make articles about covenants so boring nobody
> will hype about it (^^;)v.
>
> Increased functionality implies increased processing, and hopefully
> computation devices are getting cheap enough that the increased processing
> implied by new features should not be too onerous.
>
>
>
> To my mind, an "inescapable" covenant (i.e. one that requires the output
> to be paid to the same covenant) is basically a Turing machine, and
> equivalent to a `while (true);` loop.
> In a `while (true);` loop, the state of the machine reverts back to the
> same state, and it repeats again.
> In an inescpable covenant, the control of some amount of funds reverts
> back to the same controlling SCRIPT, and it repeats again.
> Yes, you can certainly add more functionality on top of that loop, just
> think of program main loops for games or daemons, which are, in essence,
> "just" `while (true) ...`.
> But basically, such unbounded infinite loops are possible only under
> Turing machines, thus I consider covenants to be Turing-complete.
> Principle of Least Power should make us wonder if we need full Turing
> machines for the functionality.
>
> On the other hand --- codata processing *does* allow for unbounded loops,
> without requiring full Turing-completeness; they just require total
> functionality, not partial (and Turing-completeness is partial, not total).
> Basically, data structures are unbounded storage, while codata structures
> are unbounded processing.
> Perhaps covenants can encode an upper bound on the number of recursions,
> which prevents full Turing-completeness while allowing for a large number
> of use-cases.
>
> (if the above paragraph makes no sense to you, hopefully this Wikipedia
> article will help:
> https://en.wikipedia.org/wiki/Total_functional_programming )
> (basically my argument here is based on academic programming stuff, and
> might not actually matter in real life)
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Bear in mind that when people are talking about enabl=
ing covenants, we are talking about whether OP_CAT should be allowed or not=
.</div><div><br></div><div>That said, recursive covenants, the type that ar=
e most worrying, seems to require some kind of OP_TWEAK operation, and I ha=
ven&#39;t yet seen any evidence that this can be simulated with CHECKSIG(FR=
OMSTACK).=C2=A0 So maybe we should leave such worries for the OP_TWEAK oper=
ation.<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Sun, Jul 4, 2021 at 8:51 PM ZmnSCPxj via bitcoin-dev &lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-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 rg=
b(204,204,204);padding-left:1ex">Good morning Dave,<br>
<br>
&gt; On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote:<br>
&gt;<br>
&gt; &gt; However, I think the broader community is unconvinced by the cost=
 benefit<br>
&gt; &gt; of arbitrary covenants. See<br>
&gt; &gt; <a href=3D"https://medium.com/block-digest-mempool/my-worries-abo=
ut-too-generalized-covenants-5eff33affbb6" rel=3D"noreferrer" target=3D"_bl=
ank">https://medium.com/block-digest-mempool/my-worries-about-too-generaliz=
ed-covenants-5eff33affbb6</a><br>
&gt; &gt; as a recent example. Therefore as a critical part of building con=
sensus on<br>
&gt; &gt; various techniques I&#39;ve worked to emphasize that specific add=
itions do not<br>
&gt; &gt; entail risk of accidentally introducing more than was bargained f=
or to<br>
&gt; &gt; respect the concerns of others.<br>
&gt;<br>
&gt; Respecting the concerns of others doesn&#39;t require lobotomizing use=
ful<br>
&gt; tools. Being respectful can also be accomplished by politely showing<b=
r>
&gt; that their concerns are unfounded (or at least less severe than they<b=
r>
&gt; thought). This is almost always the better course IMO---it takes much<=
br>
&gt; more effort to satisfy additional engineering constraints (and prove t=
o<br>
&gt; reviewers that you&#39;ve done so!) than it does to simply discuss tho=
se<br>
&gt; concerns with reasonable stakeholders. As a demonstration, let&#39;s l=
ook<br>
&gt; at the concerns from Shinobi&#39;s post linked above:<br>
&gt;<br>
&gt; They seem to be worried that some Bitcoin users will choose to accept<=
br>
&gt; coins that can&#39;t subsequently be fungibily mixed with other bitcoi=
ns.<br>
&gt; But that&#39;s already been the case for a decade: users can accept al=
tcoins<br>
&gt; that are non-fungible with bitcoins.<br>
&gt;<br>
&gt; They talk about covenants where spending is controlled by governments,=
<br>
&gt; but that seems to me exactly like China&#39;s CBDC trial.<br>
&gt;<br>
&gt; They talk about exchanges depositing users&#39; BTC into a covenant, b=
ut<br>
&gt; that&#39;s just a variation on the classic not-your-keys-not-your-bitc=
oins<br>
&gt; problem. For all you know, your local exchange is keeping most of its<=
br>
&gt; BTC balance commitments in ETH or USDT.<br>
&gt;<br>
&gt; To me, it seems like the worst-case problems Shinobi describes with<br=
>
&gt; covenants are some of the same problems that already exist with<br>
&gt; altcoins. I don&#39;t see how recursive covenants could make any of th=
ose<br>
&gt; problems worse, and so I don&#39;t see any point in limiting Bitcoin&#=
39;s<br>
&gt; flexibility to avoid those problems when there are so many interesting=
<br>
&gt; and useful things that unlimited covenants could do.<br>
<br>
The &quot;altcoins are even worse&quot; argument does seem quite convincing=
, and if Bitcoin can survive altcoins, surely it can survive covenants too?=
<br>
<br>
In before &quot;turns out covenants are the next ICO&quot;.<br>
i.e. ICOs are just colored coins, which are useful for keeping track of var=
ious stuff, but have then been used as a vehicle to scam people.<br>
But I suppose that is a problem that humans will always have: limited cogni=
tion, so that *good* popular things that are outside your specific field of=
 study are indistinguishable from *bad* popular things.<br>
So perhaps it should not be a concern on a technical level.<br>
Maybe we should instead make articles about covenants so boring nobody will=
 hype about it (^^;)v.<br>
<br>
Increased functionality implies increased processing, and hopefully computa=
tion devices are getting cheap enough that the increased processing implied=
 by new features should not be too onerous.<br>
<br>
<br>
<br>
To my mind, an &quot;inescapable&quot; covenant (i.e. one that requires the=
 output to be paid to the same covenant) is basically a Turing machine, and=
 equivalent to a `while (true);` loop.<br>
In a `while (true);` loop, the state of the machine reverts back to the sam=
e state, and it repeats again.<br>
In an inescpable covenant, the control of some amount of funds reverts back=
 to the same controlling SCRIPT, and it repeats again.<br>
Yes, you can certainly add more functionality on top of that loop, just thi=
nk of program main loops for games or daemons, which are, in essence, &quot=
;just&quot; `while (true) ...`.<br>
But basically, such unbounded infinite loops are possible only under Turing=
 machines, thus I consider covenants to be Turing-complete.<br>
Principle of Least Power should make us wonder if we need full Turing machi=
nes for the functionality.<br>
<br>
On the other hand --- codata processing *does* allow for unbounded loops, w=
ithout requiring full Turing-completeness; they just require total function=
ality, not partial (and Turing-completeness is partial, not total).<br>
Basically, data structures are unbounded storage, while codata structures a=
re unbounded processing.<br>
Perhaps covenants can encode an upper bound on the number of recursions, wh=
ich prevents full Turing-completeness while allowing for a large number of =
use-cases.<br>
<br>
(if the above paragraph makes no sense to you, hopefully this Wikipedia art=
icle will help: <a href=3D"https://en.wikipedia.org/wiki/Total_functional_p=
rogramming" rel=3D"noreferrer" target=3D"_blank">https://en.wikipedia.org/w=
iki/Total_functional_programming</a> )<br>
(basically my argument here is based on academic programming stuff, and mig=
ht not actually matter in real life)<br>
<br>
Regards,<br>
ZmnSCPxj<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></div>

--00000000000072054605c655dc7c--