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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
|
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">>=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'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>> OP_TWEAK=C2=A0</div><div><br></d=
iv><div>I wasn'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'Connor via bitcoin-dev <<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'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'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 <=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>> 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>
> On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote:<br>
><br>
> > However, I think the broader community is unconvinced by the cost=
benefit<br>
> > of arbitrary covenants. See<br>
> > <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>
> > as a recent example. Therefore as a critical part of building con=
sensus on<br>
> > various techniques I've worked to emphasize that specific add=
itions do not<br>
> > entail risk of accidentally introducing more than was bargained f=
or to<br>
> > respect the concerns of others.<br>
><br>
> Respecting the concerns of others doesn't require lobotomizing use=
ful<br>
> tools. Being respectful can also be accomplished by politely showing<b=
r>
> that their concerns are unfounded (or at least less severe than they<b=
r>
> thought). This is almost always the better course IMO---it takes much<=
br>
> more effort to satisfy additional engineering constraints (and prove t=
o<br>
> reviewers that you've done so!) than it does to simply discuss tho=
se<br>
> concerns with reasonable stakeholders. As a demonstration, let's l=
ook<br>
> at the concerns from Shinobi's post linked above:<br>
><br>
> 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.<br>
> But that's already been the case for a decade: users can accept al=
tcoins<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's CBDC trial.<br>
><br>
> They talk about exchanges depositing users' BTC into a covenant, b=
ut<br>
> that's just a variation on the classic not-your-keys-not-your-bitc=
oins<br>
> problem. 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. I don't see how recursive covenants could make any of th=
ose<br>
> problems worse, and so I don'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>
The "altcoins are even worse" argument does seem quite convincing=
, and if Bitcoin can survive altcoins, surely it can survive covenants too?=
<br>
<br>
In before "turns out covenants are the next ICO".<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 "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.<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, "=
;just" `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--
|