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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 043C2C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Feb 2022 07:35:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id E0CEE8276B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Feb 2022 07:35:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 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_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id aExN6-dhUXeI
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Feb 2022 07:35:02 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch
[185.70.40.137])
by smtp1.osuosl.org (Postfix) with ESMTPS id D438082733
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Feb 2022 07:35:01 +0000 (UTC)
Date: Fri, 18 Feb 2022 07:34:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1645169698;
bh=xNw459TeTvsFHP1uPWdBLEGOjj6RMvw07H84DV9ULo4=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=sD8mQ0nJ6WQpCkxHlItn1Q+oFPaK+S2Jvrl2vVqQd+InaIiMtM/gHiKxJYgj9J35W
tl3hKdpa5AtLqfiy9IOe0Yajb9dh0DqheD/j3TYci0X4eAbzJ1pIBEPuVRnhvo1cHL
OIclWDq6jGsNN+4LReDSoxf/aUeNmmQ5cNWGUEOOrlpEi2MqcopxavahiXD8z/NGvQ
WHXD2UGPMAB3S/ESCDPRTLFh20BtBWDi2xvFGUfOWbtZK7DNV1iYGH6vyaV605Ps7b
EqZZULzmPfC4usexN94T2gpB7xBvQ0hXDa/aXn+simdgMRVoF1uoxYyfU+ZgaKDJg/
6+a92ebaYVJQg==
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: <8RVJuPI1U7Iw74uWuGwQyJIvJYBWzJM9RJZKNy_KXAMaFJP9uHmAaq8UOCJ2jxiM6n1CvyYrUXZ0TUWOPoZ5Ja6oCtLsf62qhS7aN_vkZMw=@protonmail.com>
In-Reply-To: <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
<87leymuiu8.fsf@rustcorp.com.au>
<CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@mail.gmail.com>
<0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Recursive covenant opposition,
or the absence thereof,
was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and
ANYPREVOUT
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: Fri, 18 Feb 2022 07:35:04 -0000
Good morning Dave,
> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wr=
ote:
>
> > Whether [recursive covenants] is an issue or not precluding this sort
> > of design or not, I defer to others.
>
> For reference, I believe the last time the merits of allowing recursive
> covenants was discussed at length on this list[1], not a single person
> replied to say that they were opposed to the idea.
>
> I would like to suggest that anyone opposed to recursive covenants speak
> for themselves (if any intelligent such people exist). Citing the risk
> of recursive covenants without presenting a credible argument for the
> source of that risk feels to me like (at best) stop energy[2] and (at
> worst) FUD.
Let me try to give that a shot.
(Just to be clear, I am not an artificial intelligence, thus, I am not an "=
intelligent such people".)
The objection here is that recursion can admit partial (i.e. Turing-complet=
e) computation.
Turing-completeness implies that the halting problem cannot be solved for a=
rbitrary programs in the language.
Now, a counter-argument to that is that rather than using arbitrary program=
s, we should just construct programs from provably-terminating components.
Thus, even though the language may admit arbitrary programs that cannot pro=
vably terminate, "wise" people will just focus on using that subset of the =
language, and programming styles within the language, which have proofs of =
termination.
Or in other words: people can just avoid accepting coin that is encumbered =
with a SCRIPT that is not trivially shown to be non-recursive.
The counter-counter-argument is that it leaves such validation to the user,=
and we should really create automation (i.e. lower-level non-sentient prog=
rams) to perform that validation on behalf of the user.
***OR*** we could just design our language so that such things are outright=
rejected by the language as a semantic error, of the same type as `for (in=
t x =3D 0; x =3D y; x++);` is a semantic error that most modern C compilers=
will reject if given `-Wall -Werror`.
Yes, we want users to have freedom to shoot themselves in the feet, but we =
also want, when it is our turn to be the users, to keep walking with two fe=
et as long as we can.
And yes, you could instead build a *separate* tool that checks if your SCRI=
PT can be proven to be non-recursive, and let the recursive construct remai=
n in the interpreter and just require users who don't want their feet shot =
to use the separate tool.
That is certainly a valid alternate approach.
It is certainly valid to argue as well, that if a possibly-recursive constr=
uct is used, and you cannot find a proof-of-non-recursion, you should avoid=
coins encumbered with that SCRIPT (which is just a heuristic that approxim=
ate a tool for proof-of-non-recursion).
On the other hand, if we have the ability to identify SCRIPTs that have som=
e proof-of-non-recursion, why is such a tool not built into the interpreter=
itself (in the form of operations that are provably non-recursive), why ha=
ve a separate tool that people might be too lazy to actually use?
Regards,
ZmnSCPxj
|
