summaryrefslogtreecommitdiff
path: root/da/0c0756001d024c14cc5ea767b4c5fe15cce954
blob: 777250201958f03311d3901445cb346548359db1 (plain)
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
Return-Path: <ethan.scruples@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A1B83A5E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 18:24:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com
	[209.85.167.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB6E82D5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 18:24:21 +0000 (UTC)
Received: by mail-oi1-f178.google.com with SMTP id i8so1912950oib.10
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 11:24:21 -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; 
	bh=xXplJlzebi8UC96L/0TprEjjFRveGLbqEg03j63EtJc=;
	b=IyfnxkTVF+qZQvM8YvHk4XCZc2w22BTdtZXDzPnCcGwT/Y+sVIbsqcH7cfl7CPebSc
	nQYVESBklHod0Mk1jPOs2AsNVmdPVqfKAeI1hrKFXfGqf5/3OV6Ekx/Rl0B4CDFsiGCE
	dE24hJ9zr/qIXlZbFYlZzQmRiEmQJ37PwmWYC6ZrUtkuHQXuiFMAhQe9i0ZsQfkb3ogR
	S4GjeJJ2RRlOFvrCRs0MiHoRanAaMHyfx3bYbrqiI9fTxKR13gOS5DlhgLjJItpZtonE
	PpQ5+MlwOIiBd0yFRlDOBQKCxRzzf5oObbCuE6sqPtE8Y6Lgp0MzxPBgS5RBXkueuFEZ
	SzhA==
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;
	bh=xXplJlzebi8UC96L/0TprEjjFRveGLbqEg03j63EtJc=;
	b=fBzrjQhesWIIbw9pAMLNIvFIbR5tldeiCy9xKduWuzB+fpD5sQ1belmT9ChM4VRMuL
	phVhuGvpymBGuwmzNuLZFx98jrz28L407pU60y0Jh752b3wz9U5F3IT+LMEeoetBtCVt
	BoTZTP909htyrLQP+j/dxr9H/C7s0ixszb7ZuaSrRhVTuwSlSx5qQnGI7Q7CsovNN08x
	f0K52r2ZuZk0kn1FSFkXoZ2MV3hbI7ACJeYn7wkg7kgIP4xvtBv3Vb2y2stmVRMcYwhP
	VI3w3SLmei0E/MBdAejBhvA7xrlHZPkPhF+13v/aohKW7Z805MnhrD/Nx9BnI8L4MbAD
	AAxw==
X-Gm-Message-State: APjAAAWIFSERkpn+J+qNLrQXRYu1XVHcasqK4Qs5WCxpAt0m6Y3Nyhfu
	WcKtgYtqYTd/OjfxPOaOtzbb7rooqC5mufMgX58=
X-Google-Smtp-Source: APXvYqzk4oXrk+arF/+BV0iRAvtsGFYv+aZ0n9kQhZT48s+OKsM4kUidCTEzDa6L4KzuQ7CfQb4ca0iEDkOLzRg8vMg=
X-Received: by 2002:aca:4b51:: with SMTP id y78mr14809933oia.88.1552242260924; 
	Sun, 10 Mar 2019 11:24:20 -0700 (PDT)
MIME-Version: 1.0
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
	<CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>
	<6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
	<D2014BB7-1EFC-4604-ACF6-3C5AC74B6FC0@sprovoost.nl>
	<D631175F-0704-4820-BE3C-110E63F9E3FF@mattcorallo.com>
	<PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
In-Reply-To: <PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
From: Moral Agent <ethan.scruples@gmail.com>
Date: Sun, 10 Mar 2019 14:24:10 -0400
Message-ID: <CACiOHGyJ9WZhp2HG1GJdfmkD-nUTFaeVevDJFVRB_j7yBSt6Ew@mail.gmail.com>
To: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000915ba00583c190cd"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 11 Mar 2019 16:43:23 +0000
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
 Consensus Cleanup
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 10 Mar 2019 18:24:22 -0000

--000000000000915ba00583c190cd
Content-Type: text/plain; charset="UTF-8"

>Lock in a blockheight to get rid of it 10 years in the future.

And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to
the soft fork activation standard, with weight penalties as appropriate, so
there would be no difficulty spending them before the cutoff?

On Sun, Mar 10, 2019 at 10:55 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as press that Bitcoin is going to lose $1,000,000 if some mystery
> person does not put their transaction through by then, try for global
> presses. Use the opportunity to get rid of it while you are able. Once
> gazetted anything is public knowledge.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
> ------------------------------
> *From:* bitcoin-dev-bounces@lists.linuxfoundation.org <
> bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Matt Corallo
> via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 7:14 AM
> *To:* Sjors Provoost
> *Cc:* Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
> Aside from the complexity issues here, note that for a user to be
> adversely affect, they probably have to have pre-signed lock-timed
> transactions. Otherwise, in the crazy case that such a user exists, they
> should have no problem claiming the funds before activation of a soft-fork
> (and just switching to the swgwit equivalent, or some other equivalent
> scheme). Thus, adding additional restrictions like tx size limits will
> equally break txn.
>
> > On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost.nl> wrote:
> >
> >
> >> (1) It has been well documented again and again that there is desire to
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
> non-segwit scripts represents a rather significant vulnerability in Bitcoin
> today, and (3) lots of effort has gone into attempting to find practical
> use-cases for OP_CODESEPARATOR's specific construction, with no successes
> as of yet. I strongly, strongly disagree that the highly-unlikely remote
> possibility that someone created something before which could be rendered
> unspendable is sufficient reason to not fix a vulnerability in Bitcoin
> today.
> >>
> >>> I suggest an alternative whereby the execution of OP_CODESEPARATOR
> increases the transactions weight suitably as to temper the vulnerability
> caused by it.  Alternatively there could be some sort of limit (maybe 1) on
> the maximum number of OP_CODESEPARATORs allowed to be executed per script,
> but that would require an argument as to why exceeding that limit isn't
> reasonable.
> >>
> >> You could equally argue, however, that any such limit could render some
> moderately-large transaction unspendable, so I'm somewhat skeptical of this
> argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined
> is rather difficult in any case.
> >
> > Although I'm not a fan of extra complicity, just to explore these two
> ideas a bit further.
> >
> > What if such a transaction:
> >
> > 1. must have one input; and
> > 2. must be smaller than 400 vbytes; and
> > 3. must spend from a UTXO older than fork activation
> >
> > Adding such a contextual check seems rather painful, perhaps comparable
> to nLockTime. Anything more specific than the above, e.g. counting the
> number of OP_CODESEPARATOR calls, seems like guess work.
> >
> > Transaction weight currently doesn't consider OP codes, it only
> considers if bytes are part of the witness. Changing that to something more
> akin to Ethereums gas pricing sounds too complicated to even consider.
> >
> >
> > I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
> >
> > Sjors
> >
>
> _______________________________________________
> 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
>

--000000000000915ba00583c190cd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"color:rgb(0,0,0);font-family:Calibri,Helvet=
ica,sans-serif,serif,EmojiFont;font-size:16px">&gt;Lock in a blockheight to=
 get rid of it 10 years in the future.</span><br><div><br></div><div>And th=
en make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to the sof=
t fork activation standard, with weight penalties as appropriate, so there =
would be no difficulty spending them before the cutoff?</div></div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 10=
, 2019 at 10:55 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev &lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linux=
foundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">




<div dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
<br>
</div>
<div id=3D"gmail-m_7060861672063576034signature">
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
<div>
<div>
<div>
<div dir=3D"ltr">
<div style=3D"color:black;font-size:12pt;font-family:Calibri,Helvetica,sans=
-serif,serif,EmojiFont">
<div style=3D"font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont">Opi=
nion: Lock in a blockheight to get rid of it 10 years in the future. Use it=
 as press that Bitcoin is going to lose $1,000,000 if some mystery person d=
oes not put their transaction through
 by then, try for global presses. Use the opportunity to get rid of it whil=
e you are able. Once gazetted anything is public knowledge.<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont"><br=
>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont">Reg=
ards,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont">LOR=
D HIS EXCELLENCY JAMES HRMH</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<div id=3D"gmail-m_7060861672063576034appendonsend"></div>
<hr style=3D"display:inline-block;width:98%">
<div id=3D"gmail-m_7060861672063576034divRplyFwdMsg" dir=3D"ltr"><font styl=
e=3D"font-size:11pt" face=3D"Calibri, sans-serif" color=3D"#000000"><b>From=
:</b> <a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev-bounces@lists.linuxfoundation.org</a> &lt;<a href=
=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev-bounces@lists.linuxfoundation.org</a>&gt; on behalf of Matt Co=
rallo via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
<b>Sent:</b> Saturday, 9 March 2019 7:14 AM<br>
<b>To:</b> Sjors Provoost<br>
<b>Cc:</b> Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Gr=
eat Consensus Cleanup</font>
<div>=C2=A0</div>
</div>
<div class=3D"gmail-m_7060861672063576034BodyFragment"><font size=3D"2"><sp=
an style=3D"font-size:11pt">
<div class=3D"gmail-m_7060861672063576034PlainText">Aside from the complexi=
ty issues here, note that for a user to be adversely affect, they probably =
have to have pre-signed lock-timed transactions. Otherwise, in the crazy ca=
se that such a user exists, they should have no problem claiming
 the funds before activation of a soft-fork (and just switching to the swgw=
it equivalent, or some other equivalent scheme). Thus, adding additional re=
strictions like tx size limits will equally break txn.<br>
<br>
&gt; On Mar 8, 2019, at 14:12, Sjors Provoost &lt;<a href=3D"mailto:sjors@s=
provoost.nl" target=3D"_blank">sjors@sprovoost.nl</a>&gt; wrote:<br>
&gt; <br>
&gt; <br>
&gt;&gt; (1) It has been well documented again and again that there is desi=
re to remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR i=
n non-segwit scripts represents a rather significant vulnerability in Bitco=
in today, and (3) lots of effort has gone
 into attempting to find practical use-cases for OP_CODESEPARATOR&#39;s spe=
cific construction, with no successes as of yet. I strongly, strongly disag=
ree that the highly-unlikely remote possibility that someone created someth=
ing before which could be rendered unspendable
 is sufficient reason to not fix a vulnerability in Bitcoin today.<br>
&gt;&gt; <br>
&gt;&gt;&gt; I suggest an alternative whereby the execution of OP_CODESEPAR=
ATOR increases the transactions weight suitably as to temper the vulnerabil=
ity caused by it.=C2=A0 Alternatively there could be some sort of limit (ma=
ybe 1) on the maximum number of OP_CODESEPARATORs
 allowed to be executed per script, but that would require an argument as t=
o why exceeding that limit isn&#39;t reasonable.<br>
&gt;&gt; <br>
&gt;&gt; You could equally argue, however, that any such limit could render=
 some moderately-large transaction unspendable, so I&#39;m somewhat skeptic=
al of this argument. Note that OP_CODESEPARATOR is non-standard, so getting=
 them mined is rather difficult in any case.<br>
&gt; <br>
&gt; Although I&#39;m not a fan of extra complicity, just to explore these =
two ideas a bit further.<br>
&gt; <br>
&gt; What if such a transaction:<br>
&gt; <br>
&gt; 1. must have one input; and<br>
&gt; 2. must be smaller than 400 vbytes; and<br>
&gt; 3. must spend from a UTXO older than fork activation<br>
&gt; <br>
&gt; Adding such a contextual check seems rather painful, perhaps comparabl=
e to nLockTime. Anything more specific than the above, e.g. counting the nu=
mber of OP_CODESEPARATOR calls, seems like guess work.<br>
&gt; <br>
&gt; Transaction weight currently doesn&#39;t consider OP codes, it only co=
nsiders if bytes are part of the witness. Changing that to something more a=
kin to Ethereums gas pricing sounds too complicated to even consider.<br>
&gt; <br>
&gt; <br>
&gt; I would also like to believe that whoever went through the trouble of =
using OP_CODESEPARATOR reads this list.<br>
&gt; <br>
&gt; Sjors<br>
&gt; <br>
<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" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev</a><br>
</div>
</span></font></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>

--000000000000915ba00583c190cd--