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
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 86A20C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Mar 2022 15:59:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 756AA611ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Mar 2022 15:59:20 +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 uvPxZohaK7uL
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Mar 2022 15:59:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
[IPv6:2a00:1450:4864:20::62b])
by smtp3.osuosl.org (Postfix) with ESMTPS id 7E73C611E5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Mar 2022 15:59:19 +0000 (UTC)
Received: by mail-ej1-x62b.google.com with SMTP id qt6so5107133ejb.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Mar 2022 08:59:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=DokksuRk8WVvzpZxZt0n5+qaqzEMK2NbdrCrCpJm2Yo=;
b=G8v905iv7+ZN0zXpDQrO9Mx4LVma5YYw3U8yv0vL3L3LcA1ErqNFHAYBlSYbyFQAAS
tTZAbtIOyt6FZB+c/gYChln5uGewOomzVyNPIDvG2niZqOfyyJ9gygEx5Tw7elQvH0LB
3zMg++C+0JauAcJ6JdsKjpl+3E2Kx0xPEB39nvXJXy1VgL0Avo57CKkbwEv3W/wjQ+fl
xWNlKIO6ksw82s81+wk9DXpFaHVPT+LNhHcpe2ClDyBCNY+CrR1XEd2D99FcpoIrzq5u
FtkNqkXMWydK5W/5rTYr5MdCSllPhv/1A4Vk373413joGaeKKR9Uxh8KbVjzFuEqCD/V
HObA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=DokksuRk8WVvzpZxZt0n5+qaqzEMK2NbdrCrCpJm2Yo=;
b=oUU8lS/N5Mp1r3vh5YJ+eeF27eg8+sLDMAFLTPwm3QzopSr0o7zKwFDAlZlLXLsT+4
zf2MLyCBMf7CV2ZHUUrufberEbvlJCe1McEl+zXeZGIIR3QhVCu28nPhKw2w4SaJjgKe
FWjSlYiC+VmqBfYG5lDBbBDVVncHxg5vTTBwTwvimPfyL4j4g3iW5AKPCk8uS6FYBkdO
esrIP3onfeMyfp21+2c+UZgHK1XB3aYpF7vx9x3tbdoTE6sg3b5wWFhahczfE3gkTTIz
Wa3iTw3BtS55GSPRnkTomS2rnvit49x1gVJdcOqccMu3gMLkh3cVLIAReL0uGxrU/Sz3
1ltA==
X-Gm-Message-State: AOAM53187EroLmCZWXgOcj4Q3S0+AJRkeVl9t5mdpqmR1IKbgXFrlTxk
GZ1m3LuTk3OykHMDWcqurlnkNmk0Wt4wwK6K0vHVZOofMig=
X-Google-Smtp-Source: ABdhPJwfn6bgHlHF7i4XXHJ2IwGUY1sX0u2M599kYuRQB7wvQpK2zPASV/IQQqwClPWtQHpj+ztpZhyN+NlzxO0AJvQ=
X-Received: by 2002:a17:906:4fc7:b0:6da:92b2:f572 with SMTP id
i7-20020a1709064fc700b006da92b2f572mr581175ejw.184.1647446357353; Wed, 16 Mar
2022 08:59:17 -0700 (PDT)
MIME-Version: 1.0
References: <EIwjydT0d68Z7Jv8_JlrCbQW6NHSSnIU5sWwE8eX2rm9K3djfzU3nQqUrmt44U8-L9sObegelHCV6Sk7h2nwq_HS1d26FophzjNU7xC_6SE=@protonmail.com>
<CAGpPWDafWGcZJOUs4wSEt0DzFP8OXB4nrbx+9sUtTe5JfdwE_w@mail.gmail.com>
<8R8D_XAaz7xYHmgWXR-pc3_GVFRzBCNdRT6s3PdKblrnnZPirB0orzLpEUvynBZHNBTiqOM_EteDdUjdqXQ5ZmrGbdlgnnfjIihgFZIXpUM=@protonmail.com>
<CAGpPWDZwYE__YifZ0h7Bkftas6zN6Q7yOhB4rUAAwT0dcgYk7w@mail.gmail.com>
<S_vdV5XIthqwwp_9BxZH3ofQGNR7zJbUe7CZtNrRBni0qNzGqwr9sprOT9UoQSy0Ouepr7Hxwck-DsMilyjVHnPYN7YE2NzHrS4mD8p5W9c=@protonmail.com>
In-Reply-To: <S_vdV5XIthqwwp_9BxZH3ofQGNR7zJbUe7CZtNrRBni0qNzGqwr9sprOT9UoQSy0Ouepr7Hxwck-DsMilyjVHnPYN7YE2NzHrS4mD8p5W9c=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 16 Mar 2022 10:59:00 -0500
Message-ID: <CAGpPWDapC1KfD9m=peHCsmD0evnhiREfE667xYXeo0KFwBKuDw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000eaaba805da57fe38"
X-Mailman-Approved-At: Wed, 16 Mar 2022 16:04:24 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Jets (Was: `OP_FOLD`: A Looping Construct For
Bitcoin SCRIPT)
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: Wed, 16 Mar 2022 15:59:20 -0000
--000000000000eaaba805da57fe38
Content-Type: text/plain; charset="UTF-8"
> The constants table would be part of the SCRIPT puzzle
Ah I see what you're saying now. You're not talking about referencing
inputs from the spender, but rather constants for the script writer to
parameterize a jet with. TBH I think both would be useful, and both could
potentially be done in the same way (ie reference their position in the
script before any evaluation starts). I think your idea is a good one.
Cheers
On Wed, Mar 16, 2022 at 10:39 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning Billy,
>
> > > I think we would want to have a cleanstack rule at some point
> >
> > Ah is this a rule where a script shouldn't validate if more than just a
> true is left on the stack? I can see how that would prevent the
> non-soft-fork version of what I'm proposing.
>
> Yes.
> There was also an even stronger cleanstack rule where the stack and alt
> stack are totally empty.
> This is because a SCRIPT really just returns "valid" or "invalid", and
> `OP_VERIFY` can be trivially appended to a SCRIPT that leaves a single
> stack item to convert to a SCRIPT that leaves no stack items and retains
> the same behavior.
>
> >
> > > How large is the critical mass needed?
> >
> > Well it seems we've agreed that were we going to do this, we would want
> to at least do a soft-fork to make known jet scripts lighter weight (and
> unknown jet scripts not-heavier) than their non-jet counterparts. So given
> a situation where this soft fork happens, and someone wants to implement a
> new jet, how much critical mass would be needed for the network to get some
> benefit from the jet? Well, the absolute minimum for some benefit to happen
> is that two nodes that support that jet are connected. In such a case, one
> node can send that jet scripted transaction along without sending the data
> of what the jet stands for. The jet itself is pretty small, like 2 or so
> bytes. So that does impose a small additional cost on nodes that don't
> support a jet. For 100,000 nodes, that means 200,000 bytes of transmission
> would need to be saved for a jet to break even. So if the jet stands for a
> 22 byte script, it would break even when 10% of the network supported it.
> If the jet stood for a 102 byte script, it would break even when 2% of the
> network supported it. So how much critical mass is necessary for it to be
> worth it depends on what the script is.
>
> The math seems reasonable.
>
>
> > The question I have is: where would the constants table come from? Would
> it reference the original positions of items on the witness stack?
>
> The constants table would be part of the SCRIPT puzzle, and thus not in
> the witness solution.
> I imagine the SCRIPT would be divided into two parts: (1) a table of
> constants and (2) the actual opcodes to execute.
>
>
> Regards,
> ZmnSCPxj
>
--000000000000eaaba805da57fe38
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0
The constants table would be part of the SCRIPT puzzle<div><br></div><div>A=
h I see what you're saying now. You're not talking about referencin=
g inputs from the spender, but rather constants for the script writer to pa=
rameterize a jet with. TBH I think both would be useful, and both could pot=
entially be done in the same way (ie reference=C2=A0their position in the s=
cript before any evaluation starts). I think your idea is a good one.=C2=A0=
</div><div><br></div><div>Cheers</div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 16, 2022 at 10:39 AM ZmnS=
CPxj <<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
Good morning Billy,<br>
<br>
> > I think we would want to have a cleanstack rule at some point<br>
><br>
> Ah is this a rule where a script shouldn't validate if more than j=
ust a true is left on the stack? I can see how that would prevent the non-s=
oft-fork version of what I'm proposing.=C2=A0<br>
<br>
Yes.<br>
There was also an even stronger cleanstack rule where the stack and alt sta=
ck are totally empty.<br>
This is because a SCRIPT really just returns "valid" or "inv=
alid", and `OP_VERIFY` can be trivially appended to a SCRIPT that leav=
es a single stack item to convert to a SCRIPT that leaves no stack items an=
d retains the same behavior.<br>
<br>
><br>
> > How large is the critical mass needed?<br>
><br>
> Well it seems we've agreed that were we going to do this, we would=
want to at least do a soft-fork to make known jet scripts lighter weight (=
and unknown jet scripts not-heavier) than their=C2=A0non-jet counterparts. =
So given a situation where this soft fork happens, and someone wants to imp=
lement a new jet, how much critical mass would be needed for the network to=
get some benefit from the jet? Well, the absolute minimum for some benefit=
to happen is that two nodes that support that jet are connected. In such a=
case, one node can send that jet scripted transaction along without sendin=
g the data of what the jet stands for. The jet itself is pretty small, like=
2 or so bytes. So that does impose a small additional cost on nodes that d=
on't support a jet. For 100,000 nodes, that means 200,000 bytes of tran=
smission would need to be saved for a jet to break even. So if the jet stan=
ds for a 22 byte script, it would break even when 10% of the network suppor=
ted it. If the jet stood for a 102 byte script, it would break even when 2%=
of the network supported it. So how much critical mass is necessary for it=
to be worth it depends on what the script is.=C2=A0<br>
<br>
The math seems reasonable.<br>
<br>
<br>
> The question I have is: where would the constants table come from? Wou=
ld it reference the original positions of items on the witness stack?=C2=A0=
<br>
<br>
The constants table would be part of the SCRIPT puzzle, and thus not in the=
witness solution.<br>
I imagine the SCRIPT would be divided into two parts: (1) a table of consta=
nts and (2) the actual opcodes to execute.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
--000000000000eaaba805da57fe38--
|
