1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id A0FA8C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Jul 2021 00:51:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 808D9400E5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Jul 2021 00:51:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 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,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H4=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id KQnVxhaxt98O
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Jul 2021 00:51:00 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
by smtp2.osuosl.org (Postfix) with ESMTPS id D7191400B5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Jul 2021 00:50:59 +0000 (UTC)
Date: Mon, 05 Jul 2021 00:50:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1625446256;
bh=YFRmz8b9yLgSbq45sjwYYfP90i3g7uBbPDh+nV84G3c=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=gHv33TdqoZ3y6LayeJBUWYm4WUsAMUczwTBb4K+hcLArf610dUcFf0atQtqI0KKLp
zfgmFinjKb49tTtPahpiGrZ5PP5nonQ6Rwaexx/KgkFSty1LUEkoar9s7t3vUdIqc3
JMJgJtvGvpn/Tppmos6LHgSlpnezJqiGlMgBwq8s=
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <5keA_aPvmCO5yBh_mBQ6Z5SwnnvEW0T-3vahesaDh57f-qv4FbG1SFAzDvT3rFhre6kFl282VsxV_pynwn_CdvF7fzH2q9NW1ZQHPH1pmdo=@protonmail.com>
In-Reply-To: <20210704203230.37hlpdyzr4aijiet@ganymede>
References: <CAD5xwhjmu-Eee47Ho5eA6E6+aAdnchLU0OVZo=RTHaXnN17x8A@mail.gmail.com>
<20210704011341.ddbiruuomqovrjn6@ganymede>
<CAD5xwhimPBEV_tLpSPxs9B+XGUhvPx_dnhok=8=hyksyi4=B6g@mail.gmail.com>
<20210704203230.37hlpdyzr4aijiet@ganymede>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 00:51:01 -0000
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 benef=
it
> > of arbitrary covenants. See
> > https://medium.com/block-digest-mempool/my-worries-about-too-generalize=
d-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 B=
itcoin 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 equivalen=
t 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/wiki/Total_functional_programming =
)
(basically my argument here is based on academic programming stuff, and mig=
ht not actually matter in real life)
Regards,
ZmnSCPxj
|
