From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 32115C000E for ; 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 ; 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 ; 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 ; Mon, 5 Jul 2021 01:02:37 +0000 (UTC) Received: by mail-qk1-x72a.google.com with SMTP id f6so15566698qka.0 for ; 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: <20210704011341.ddbiruuomqovrjn6@ganymede> <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" Date: Sun, 4 Jul 2021 21:02:25 -0400 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Bear in mind that when people are talking about enabl= ing covenants, we are talking about whether OP_CAT should be allowed or not= .

That said, recursive covenants, the type that ar= e most worrying, seems to require some kind of OP_TWEAK operation, and I ha= ven'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.

On Sun, Jul 4, 2021 at 8:51 PM ZmnSCPxj via bitcoin-dev <bitco= in-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-generaliz= ed-covenants-5eff33affbb6
> > as a recent example. Therefore as a critical part of building con= sensus on
> > various techniques I've worked to emphasize that specific add= itions do not
> > entail risk of accidentally introducing more than was bargained f= or to
> > respect the concerns of others.
>
> Respecting the concerns of others doesn't require lobotomizing use= ful
> 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<= br> > more effort to satisfy additional engineering constraints (and prove t= o
> reviewers that you've done so!) than it does to simply discuss tho= se
> concerns with reasonable stakeholders. As a demonstration, let's l= ook
> at the concerns from Shinobi's post linked above:
>
> They seem to be worried that some Bitcoin users will choose to accept<= br> > coins that can't subsequently be fungibily mixed with other bitcoi= ns.
> But that's already been the case for a decade: users can accept al= tcoins
> 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, b= ut
> that's just a variation on the classic not-your-keys-not-your-bitc= oins
> problem. For all you know, your local exchange is keeping most of its<= br> > 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 th= ose
> problems worse, and so I don't see any point in limiting Bitcoin&#= 39;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 var= ious 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 cogni= tion, 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 computa= tion 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 sam= e 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 thi= nk 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 machi= nes for the functionality.

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).
Basically, data structures are unbounded storage, while codata structures a= re unbounded processing.
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.

(if the above paragraph makes no sense to you, hopefully this Wikipedia art= icle will help: https://en.wikipedia.org/w= iki/Total_functional_programming )
(basically my argument here is based on academic programming stuff, and mig= ht not actually matter in real life)

Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000072054605c655dc7c--