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
|
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 42245C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Mar 2022 20:38:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 36F8040436
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Mar 2022 20:38:28 +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: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-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 3fzvSk32cMbM
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Mar 2022 20:38:26 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by smtp2.osuosl.org (Postfix) with ESMTPS id 7751D40377
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Mar 2022 20:38:26 +0000 (UTC)
Date: Sun, 06 Mar 2022 20:38:17 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1646599103;
bh=YW3+AtI7ZUpAvwAIy4cEqvLiroRtykkU8PYumUIqFO0=;
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=Q/c51rmR2YPptKb6JPeHxZ3D6wZYj1jogHPsrSivjAd0IefprYPt0Zfr+l5W3EAIe
Oq1hbyJd1PG4nV7ICnNoOqJjeKyCwq1EzSPrZkkXVP/XY/mWZf2npIyGn72eFcMoJg
m5PcO52V58mX/6lVvdFZZROAtQpljw/74BRse1joyaeF5X2KSzyMZaQ1S9ytRbBfN8
iL6avQkJw6J0b4Kj0phjPhGY+EXHm0dYP3CkWpalJABtwVCuMwokVnciahii1NE8o6
hgpoM9JG63JyXzGBmf1rp+XAyA9ji0CjckZHCNUC7hAnzz0u/gHuBuQ0a04xU4MoBG
C/vhaChniHG7A==
To: Billy Tetrud <billy.tetrud@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-3inEV9Skl4K8wQefM7I0EbYzQc-zWV4QPgJSXKNxx0X_2EbwyTRmVjwooU1a8wFRNU41Cr41hb-Ajno_nV39U9rOge1oaUg9MvKmQ7-v30=@protonmail.com>
In-Reply-To: <CAGpPWDYCPgLxO4rDRVhK+ye50EBinKKXdiJTG+4CoW8SDtvJAA@mail.gmail.com>
References: <rcWu5FJZQGCdQeFZSUKV2AylHwmlTYPWAnxvN-FP8lER3qFBLIYLPVH4-r0js0k6_Xy_TwxA3jWXZC15jFbAafNb_vnr3a54ZMrgAeTz6vM=@protonmail.com>
<CAGpPWDawAQShRU4OYcVnOE+qmHQv79ahwhMeyALF8iwjkZ_sOg@mail.gmail.com>
<1zAD-_yaVAjRfYOQmNn_lh1cIQ9yxtR_TpLpHfl3A8TbtTpHEpduMloN72b-zI8U4HjrXRCHBBee16Ly89OAZJohfJuewWNCCHuacBN5TE8=@protonmail.com>
<CAGpPWDYCPgLxO4rDRVhK+ye50EBinKKXdiJTG+4CoW8SDtvJAA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] `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: Sun, 06 Mar 2022 20:38:28 -0000
Good morning Billy,
> Even changing the weight of a transaction using jets (ie making a script =
weigh less if it uses a jet) could be done in a similar=C2=A0way to how seg=
wit separated=C2=A0the witness out.
The way we did this in SegWit was to *hide* the witness from unupgraded nod=
es, who are then unable to validate using the upgraded rules (because you a=
re hiding the data from them!), which is why I bring up:
> > If a new jet is released but nobody else has upgraded, how bad is my se=
curity if I use the new jet?
>
> Security wouldn't be directly affected, only (potentially) cost. If your =
security depends on cost (eg if it depends on pre-signed transactions and i=
s for some reason not easily CPFPable or RBFable), then security might be a=
ffected if the unjetted=C2=A0scripts costs substantially more to mine.=
=C2=A0
So if we make a script weigh less if it uses a jet, we have to do that by t=
elling unupgraded nodes "this script will always succeed and has weight 0",=
just like `scriptPubKey`s with `<0> <P2WKH hash>` are, to pre-SegWit nodes=
, spendable with an empty `scriptSig`.
At least, that is how I always thought SegWit worked.
Otherwise, a jet would never allow SCRIPT weights to decrease, as unupgrade=
d nodes who do not recognize the jet will have to be fed the entire code of=
the jet and would consider the weight to be the expanded, uncompressed cod=
e.
And weight is a consensus parameter, blocks are restricted to 4Mweight.
So if a jet would allow SCRIPT weights to decrease, upgraded nodes need to =
hide them from unupgraded nodes (else the weight calculations of unupgraded=
nodes will hit consensus checks), then if everybody else has not upgraded,=
a user of a new jet has no security.
Not even the `softfork` form of chialisp that AJ is proposing in the other =
thread would help --- unupgraded nodes will simply skip over validation of =
the `softfork` form.
If the script does not weigh less if it uses a jet, then there is no incent=
ive for end-users to use a jet, as they would still pay the same price anyw=
ay.
Now you might say "okay even if no end-users use a jet, we could have fulln=
odes recognize jettable code and insert them automatically on transport".
But the lookup table for that could potentially be large once we have a few=
hundred jets (and I think Simplicity already *has* a few hundred jets, so =
additional common jets would just add to that?), jettable code could start =
at arbitrary offsets of the original SCRIPT, and jettable code would likely=
have varying size, that makes for a difficult lookup table.
In particular that lookup table has to be robust against me feeding it some=
section of code that is *almost* jettable but suddenly has a different opc=
ode at the last byte, *and* handle jettable code of varying sizes (because =
of course some jets are going to e more compressible than others).
Consider an attack where I feed you a SCRIPT that validates trivially but i=
s filled with almost-but-not-quite-jettable code (and again, note that expa=
nded forms of jets are varying sizes), your node has to look up all those j=
ets but then fails the last byte of the almost-but-not-quite-jettable code,=
so it ends up not doing any jetting.
And since the SCRIPT validated your node feels obligated to propagate it to=
o, so now you are helping my DDoS.
> >=C2=A0 I suppose the point would be --- how often *can* we add new jets?
>
> A simple jet would be something that's just added to bitcoin software and=
used by nodes that recognize it. This would of course require some debate =
and review to add it to bitcoin core or whichever bitcoin software you want=
to add it to. However, the idea I proposed in my last email would allow an=
yone to add a new jet. Then each node can have their own policy to determin=
e which jets of the ones registered it wants to keep an index of and use. O=
n its own, it wouldn't give any processing power optimization, but it would=
be able to do the same kind of script compression you're talking about op_=
fold allowing. And a list of registered jets could inform what jets would b=
e worth building an optimized function for.=C2=A0This would require a conse=
nsus change to implement this mechanism, but thereafter any jet could be re=
gistered in userspace.
Certainly a neat idea.
Again, lookup table tho.
Regards,
ZmnSCPxj
|
