path: root/54/9588935b4e1fbb38bd7e6303cccd26507c241c

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9137FC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 06:26:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 72F34607AB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 06:26:09 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id zyUiaq99DJn0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 06:26:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [IPv6:2a00:1450:4864:20::534])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 03CF960768
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  6 Jul 2021 06:26:06 +0000 (UTC)
Received: by mail-ed1-x534.google.com with SMTP id m1so26447669edq.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 05 Jul 2021 23:26:06 -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=zPLDdT9PRXNvgAtZsbJgXlNd3YswMqn/wgJ9xdcmG+I=;
 b=Qny7cnDZnYhgoCqr4dW6OaRYvnrdWopGguPriXoX6EIMrx9tVOb2rVwyXtBWvfj6o+
 MHITHFXGQaIvG5M+GX0iNMAwk1ASylKpFhlLKpyfSDbyzd+LXbG8QH9QkUt3/o8q9Wta
 LqXUJi+8tHIjXFyLiS2bmBuRqZ06HcGv/d5Oxrg3Sq3rGTSumAaRqX5K8sQGL95aP+yM
 fuGnzmMowxJdcVQGpPEw6aNS8VE4X6L4jn1iOTULF3DlRiJw8l6XQJ5bIoJoRIbr6UaR
 q3k6DyJasB7b6CRRnhj8hsnbf44D6lNDtONnjyhZqd38LnKRlbhiT49ViDmjjoxPzgjx
 Li5g==
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=zPLDdT9PRXNvgAtZsbJgXlNd3YswMqn/wgJ9xdcmG+I=;
 b=VWKQnXREzMkPUhZ7j1GpQ8+qWAxPXZJVckvAO1uz7cAfK9QGtaXEtgROUXchXJYt36
 3vBLy3iOKyT/KA8DtLq4TRf/IFNPb5Xnqbko7WKRmQ4kPlMwfKUu641E1QrtlbGDZG+o
 HJR8GX2LJjZNjHWf/zP91qOBACiS+t0Q7GSBDXxqRspoQ+3tKAHY5hKe023o8kACUeBn
 uZbzRmWQtk07SdkchFXoYfv/lRIYNduathARG0bxRNpaBLsTeCLqbKOdhmUQ+oduav6P
 aE4GmPHYh/Kue2IKFlzQlEoQRpt7D+glqpkvbRpJhNXtKanwPuCdorqqXP4OmwnHqFnI
 Fj4Q==
X-Gm-Message-State: AOAM531/H4DZ17vISmoiFDPrnzgBkk1oHSjm6un9sYBuBHBi7aKCen9H
 RGe1LO/8b0yCR8nEzyzaiCZSNBZ/2LFd0jeVSoI=
X-Google-Smtp-Source: ABdhPJwsNj/pzfKMq+LZG8raT10LideNfKIYYLwQX0r1lMbjRvjMfLillWvNVFUu5s1z1sb8n2GGexwRkbbGGeEYv1Y=
X-Received: by 2002:a05:6402:4388:: with SMTP id
 o8mr3370643edc.338.1625552765140; 
 Mon, 05 Jul 2021 23:26:05 -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>
 <CAMZUoKnuRXNG1pyupHrL+Wo80TXTbADVrexoB=+BKC633v-qMw@mail.gmail.com>
In-Reply-To: <CAMZUoKnuRXNG1pyupHrL+Wo80TXTbADVrexoB=+BKC633v-qMw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 5 Jul 2021 23:25:48 -0700
Message-ID: <CAGpPWDZ6FhAn+dBf-_yf7YVzRB7NWV7zaKqKYewgZecBxWUx5A@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000021451105c66e7f32"
X-Mailman-Approved-At: Tue, 06 Jul 2021 08:35:55 +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: Tue, 06 Jul 2021 06:26:09 -0000

--00000000000021451105c66e7f32
Content-Type: text/plain; charset="UTF-8"

>  when people are talking about enabling covenants, we are talking about
whether OP_CAT should be allowed or not

Are they? Are you implying that anything that enables covenants is
equivalent to enabling OP_CAT? Generally when I think about enabling
covenants, I'm thinking more about OP_CTV (or some similarly specific opcode
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bip-constraindestination.md>
).

> OP_TWEAK

I wasn't able to find anything about what that is. Would you mind
clarifying what that concept is?

On Mon, Jul 5, 2021 at 10:20 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi ZmnSCPxj,
>
> I don't believe we need to ban Turing completeness for the sake of banning
> Turing completeness.  My concerns have always been around ensuring that
> transaction and block validation is not unduly burdensome for nodes.  So
> for Bitcoin Script, we want to bound the amount of resources needed to
> execute it, preferably as a linear function of weight[1], and preferably
> have it clear what the evaluation costs are going to be prior to
> evaluation[2].  We also want to keep Script execution as a pure function of
> the transaction data so that nodes do not need to reevaluate their mempool
> on every new block.  For consensus purposes we prefer to have simple
> primitive operations that have clear and precise semantics that are as
> likely as possible to be reimplemented correctly if they are reimplemented
> (or at least let us not make this problem worse than it already is).  In
> particular, Script needs to be easy to parse to avoid weird parsing
> machines that lead to security vulnerabilities within node software.
>
> While the above design constraints imply a prohibition on Turing complete
> computation within a single Script, they do not imply a prohibition on
> arbitrary, covenant-enabled computations that spans across multiple
> transactions.  Neither would these constraints prohibit some kind of STARK
> or SNARK tapleaf version that was somehow capable of succinctly
> representing arbitrary computations, so long as validation costs remain
> bounded.
>
> And while it is true that covenant-enabled computations could allow users
> to put their funds at risk through weird machines that manipulate their
> money on the blockchain, as longs as that weirdness stays at that level of
> the abstract Bitcoin Script machine, then I suppose it is *caveat emptor*;
> don't send your funds to random unverified Bitcoin Scripts, advice that is
> already the case today.  We can keep that potential weirdness at bay by
> keeping Script simple, and maintaining our understanding that the Script
> programs (like the rest of the blockchain data) are untrusted inputs and
> they need to be validated and scrutinized before interpretation.
>
> [1] In tapscript I believe all operations are linear time with the
> exception of OP_ROLL.  However OP_ROLL is still constrained by global
> limits on stack size, etc.
> [2] In Bitcoin Script, without loops of any kind, every opcode is
> evaluated at most once, so counting opcodes is an easy way to put an upper
> bound on your costs before evaluation.
>
> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">&gt;=C2=A0

when people are talking about enabling covenants, we are talking about whet=
her OP_CAT should be allowed or not<div><br></div><div>Are they? Are you im=
plying that anything that enables covenants is equivalent to enabling OP_CA=
T? Generally when I think about enabling covenants, I&#39;m thinking more a=
bout OP_CTV (or some similarly specific <a href=3D"https://github.com/fresh=
eneesz/bip-efficient-bitcoin-vaults/blob/main/bip-constraindestination.md">=
opcode</a>).</div><div><br></div><div>&gt; OP_TWEAK=C2=A0</div><div><br></d=
iv><div>I wasn&#39;t able to find anything about=C2=A0what that is. Would y=
ou mind clarifying what that concept is?=C2=A0</div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 5, 2021 at =
10:20 AM Russell O&#39;Connor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div>Hi ZmnSCPxj,</div><div><br></div><div>I don&#39;t believe w=
e need to ban Turing completeness for the sake of banning Turing completene=
ss.=C2=A0 My concerns have always been around ensuring that transaction and=
 block validation is not unduly burdensome for nodes.=C2=A0 So for Bitcoin =
Script, we want to bound the amount of resources needed to execute it, pref=
erably as a linear function of weight[1], and preferably have it clear what=
 the evaluation costs are going to be prior to evaluation[2].=C2=A0 We also=
 want to keep Script execution as a pure function of the transaction data s=
o that nodes do not need to reevaluate their mempool on every new block.=C2=
=A0 For consensus purposes we prefer to have simple primitive operations th=
at have clear and precise semantics that are as likely as possible to be re=
implemented correctly if they are reimplemented (or at least let us not mak=
e this problem worse than it already is).=C2=A0 In particular, Script needs=
 to be easy to parse to avoid weird parsing machines that lead to security =
vulnerabilities within node software.<br></div><div><br></div><div>While th=
e above design constraints imply a prohibition on Turing complete computati=
on within a single Script, they do not imply a prohibition on arbitrary, co=
venant-enabled computations that spans across multiple transactions.=C2=A0 =
Neither would these constraints prohibit some kind of STARK or SNARK taplea=
f version that was somehow capable of succinctly representing arbitrary com=
putations, so long as validation costs remain bounded.</div><div><br></div>=
<div>And while it is true that covenant-enabled computations could allow us=
ers to put their funds at risk through weird machines that manipulate their=
 money on the blockchain, as longs as that weirdness stays at that level of=
 the abstract Bitcoin Script machine, then I suppose it is <i>caveat emptor=
</i>; don&#39;t send your funds to random unverified Bitcoin Scripts, advic=
e that is already the case today.=C2=A0 We can keep that potential weirdnes=
s at bay by keeping Script simple, and maintaining our understanding that t=
he Script programs (like the rest of the blockchain data) are untrusted inp=
uts and they need to be validated and scrutinized before interpretation.<br=
></div><div><br></div><div>[1] In tapscript I believe all operations are li=
near time with the exception of OP_ROLL.=C2=A0 However OP_ROLL is still con=
strained by global limits on stack size, etc.</div><div>[2] In Bitcoin Scri=
pt, without loops of any kind, every opcode is evaluated at most once, so c=
ounting opcodes is an easy way to put an upper bound on your costs before e=
valuation.<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Sun, Jul 4, 2021 at 8:51 PM ZmnSCPxj via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>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 sol=
id rgb(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>
_______________________________________________<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>

--00000000000021451105c66e7f32--