path: root/8e/d342f65f805a3e3a7909b8125f65e285f0e4ec

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1AB64258
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  5 Jan 2017 16:23:02 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu
	[18.9.25.12])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 959041E5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  5 Jan 2017 16:23:00 +0000 (UTC)
X-AuditID: 1209190c-49fff70000000dc2-85-586e72e24fde
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])
	(using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by  (Symantec Messaging Gateway) with SMTP id 8F.A1.03522.2E27E685;
	Thu,  5 Jan 2017 11:22:59 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
	by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v05GMwOA005545
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 5 Jan 2017 11:22:58 -0500
Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43])
	(authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v05GMuwd026287
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 5 Jan 2017 11:22:57 -0500
Received: by mail-wm0-f43.google.com with SMTP id a197so437886963wmd.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 05 Jan 2017 08:22:57 -0800 (PST)
X-Gm-Message-State: AIkVDXL3osiQmGUb72+5fvFBiqUu3u+KFqeJ7HZt0ZJD7nf+u+QQihxIFCKJBaJiXuHk4d19DRy6ZAYRIHyDSA==
X-Received: by 10.28.139.74 with SMTP id n71mr643103wmd.139.1483633375588;
	Thu, 05 Jan 2017 08:22:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.23.8 with HTTP; Thu, 5 Jan 2017 08:22:34 -0800 (PST)
In-Reply-To: <CABm2gDr-8h6EszsKRpJq6OCNnTUjmPvN_K3pYzyeNT3z2Lu94w@mail.gmail.com>
References: <mailman.11263.1483391161.31141.bitcoin-dev@lists.linuxfoundation.org>
	<400152B9-1838-432A-829E-13E4FC54320C@gmail.com>
	<CAD5xwhjHFzFzKws10TG-XioZoRVZ_oZbMF_xDOy5xNWtzFTsEw@mail.gmail.com>
	<6A91D4E4-750D-42C0-B593-3D5014B8A3F7@xbt.hk>
	<CAD5xwhg3QeHZF1Oepo3dnCAth0EO3wCqyeT4a21gQ2uxZ5dTfQ@mail.gmail.com>
	<CAMZUoK=-3dGapPQTfKdd4oMQukiTyN1v123Yjo4ihO6YOHuBZQ@mail.gmail.com>
	<CABm2gDr-8h6EszsKRpJq6OCNnTUjmPvN_K3pYzyeNT3z2Lu94w@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Thu, 5 Jan 2017 11:22:34 -0500
X-Gmail-Original-Message-ID: <CAD5xwhh0RKqS0odeN1inoNFBUaVDmO_gt7rCV88kGn6VQrNBuQ@mail.gmail.com>
Message-ID: <CAD5xwhh0RKqS0odeN1inoNFBUaVDmO_gt7rCV88kGn6VQrNBuQ@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a114447ca543eea05455b500a
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFKsWRmVeSWpSXmKPExsUixG6novu4KC/CoOMet0XTa1sHRo/fPyYz
	BjBGcdmkpOZklqUW6dslcGWc2LSLueDuQsaKrXP+MTYwru5n7GLk5JAQMJGYc+MfcxcjF4eQ
	QBuTxKvJB1ggnDuMEm/e/GeEcN4zSSxevADKWcQo8ej0BaAyDqD+HIlji/wgRhVJXLu5lwXE
	5hUQlDg58wmYLSTgIfH0fh8zSDmnQKDEw3slEOHTzBIHpxWDhNkE5CQ+/DIFMVkEVCS2nIiH
	GJgosf7AcXaQMK9AgMT9W6EgYWEBI4ktfy8ygdgiAsYS78//Ywe5i1lgP6PE5Ms7wZYyC3hJ
	3H/1j2kCo/AsJPfMQpKaBTSWWUBdYv08IYiwtsSyha+ZIWw1idvbrrIjiy9gZFvFKJuSW6Wb
	m5iZU5yarFucnJiXl1qka6iXm1mil5pSuokRFCGckjw7GM+88TrEKMDBqMTDG+GVFyHEmlhW
	XJl7iFGSg0lJlHd/OlCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO+2fKAcb0piZVVqUT5MSpqD
	RUmc91Kme4SQQHpiSWp2ampBahFMVoaDQ0mC17cQqFGwKDU9tSItM6cEIc3EwQkynAdouCRI
	DW9xQWJucWY6RP4UozHHtHcLnzJx7Ohc85RJiCUvPy9VSpz3YAFQqQBIaUZpHtw0UJLzqg3S
	fsUoDvScMO9VkIE8wAQJN+8V0ComoFXbA7JBVpUkIqSkGhidt7mGuCyVObdNYD/7Tc+S44Hs
	v3yKXtrNnqh/VN9pefL7ftcLEtfSExsETx29lspTwXbzw8Qea35xJ3EGufOecx0yrnJKcuzb
	zJyjdzBo02299Fv2SxcIBzpGXTWKZmG4emSD2o1yVdZ7gv/S1CuN5H5WGjfOm/f3sdOsuHAG
	RaPoFM+9b5VYijMSDbWYi4oTAdEQ0kZNAwAA
X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Steve Davis <steven.charles.davis@gmail.com>
Subject: Re: [bitcoin-dev] Script Abuse Potential?
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: Thu, 05 Jan 2017 16:23:02 -0000

--001a114447ca543eea05455b500a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

@Russell: Appreciate the historical note, but as that op code was
simultaneously disabled in that patch I don't think we can look back to how
it was non-functionally changed (that number means nothing... maybe Satoshi
was trying it out with 520 bytes but then just decided to all-out disable
it and accidentally included that code change? Hard to say what the intent
was.).

@Jorge:
That's one part of it that is worth hesitation and consideration. I'm not a
fan of the 520 byte limit as well. My gut feeling is that the "right"
answer is to compute the memory weight of the entire stack before/after
each operation and reasonably bound it.

Below text is from the chain core documentation:

"""
Most instructions use only the data stack by removing some items and then
placing some items back on the stack. For these operations, we define the
standard memory cost applied as follows:

Instruction=E2=80=99s memory cost value is set to zero.
For each item removed from the data stack, instruction=E2=80=99s memory cos=
t is
decreased by 8+L where L is the length of the item in bytes.
For each item added to the data stack the cost is increased by 8+L where L
is the length of the item in bytes.
=E2=80=8B----=E2=80=8B
Every instruction has a cost that affects VM run limit. Total instruction
cost consists of execution costand memory cost. Execution cost always
reduces remaining run limit, while memory usage cost can be refunded
(increasing the run limit) when previously used memory is released during
VM execution.
"""

=E2=80=8BIs there a reason to favor one approach over the other? I think on=
e reason
to favor a direct limit on op_cat is it favors what=E2=80=8B
=E2=80=8B
=E2=80=8B I'll dub "context free" analysis, where the performance doesn't d=
epend on
what else is on the stack (perhaps by passing very large arguments to a
script you can cause bad behavior with a general memory limit?).=E2=80=8B O=
n the
other hand, the reason I prefer the general memory limit is it solves the
problem for all future memory-risky opcodes (or present day memory risks!).
Further, OP_CAT is also a bit leaky, in that you could be catting onto a
passed in large string.  The chief argument I'm aware of against a general
memory limit argument is that it is tricky to make a non-implementation
dependent memory limit (e.g., can't just call DynamicMemoryUsage on the
stack), but I don't think this is a strong argument for several
(semi-obvious? I can go into them if need be) reasons.


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

On Wed, Jan 4, 2017 at 9:45 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:

> I would assume that the controversial part of op_cat comes from the fact
> that it enables covenants. Are there more concerns than that?
>
> On 4 Jan 2017 04:14, "Russell O'Connor via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> For the record, the OP_CAT limit of 520 bytes was added by Satoshi
>> <https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337f=
babe8464c82#diff-8458adcedc17d046942185cb709ff5c3R425>
>> on the famous August 15, 2010 "misc" commit, at the same time that OP_CA=
T
>> was disabled.
>> The previous limit was 5000 bytes.
>>
>> On Tue, Jan 3, 2017 at 7:13 PM, Jeremy via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Sure, was just upper bounding it anyways. Even less of a problem!
>>>
>>>
>>> RE: OP_CAT, not as OP_CAT was specified, which is why it was disabled.
>>> As far as I know, the elements alpha proposal to reenable a limited op_=
cat
>>> to 520 bytes is somewhat controversial...
>>>
>>>
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>
>>> <https://twitter.com/JeremyRubin>
>>>
>>> On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau <jl2012@xbt.hk> wrote:
>>>
>>>> No, there could only have not more than 201 opcodes in a script. So yo=
u
>>>> may have 198 OP_2DUP at most, i.e. 198 * 520 * 2 =3D 206kB
>>>>
>>>> For OP_CAT, just check if the returned item is within the 520 bytes
>>>> limit.
>>>>
>>>> On 3 Jan 2017, at 11:27, Jeremy via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>> It is an unfortunate script, but can't actually
>>>> =E2=80=8Bdo
>>>>  that much
>>>> =E2=80=8B it seems=E2=80=8B
>>>> . The MAX_SCRIPT_ELEMENT_SIZE =3D 520 Bytes.
>>>> =E2=80=8B Thus, it would seem the worst you could do with this would b=
e to (10000-520*2)*520*2
>>>> bytes  ~=3D~ 10 MB.
>>>>
>>>> =E2=80=8BMuch more concerning would be the op_dup/op_cat style bug, wh=
ich under
>>>> a similar script =E2=80=8Bwould certainly cause out of memory errors :=
)
>>>>
>>>>
>>>>
>>>> --
>>>> @JeremyRubin <https://twitter.com/JeremyRubin>
>>>> <https://twitter.com/JeremyRubin>
>>>>
>>>> On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Suppose someone were to use the following pk_script:
>>>>>
>>>>> [op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)...,
>>>>> op_2dup, op_hash160, <addr_hash>, op_equalverify, op_checksig]
>>>>>
>>>>> This still seems to be valid AFAICS, and may be a potential attack
>>>>> vector?
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>

--001a114447ca543eea05455b500a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">@Russell: Appreciate t=
he historical note, but as that op code was simultaneously disabled in that=
 patch I don&#39;t think we can look back to how it was non-functionally ch=
anged (that number means nothing... maybe Satoshi was trying it out with 52=
0 bytes but then just decided to all-out disable it and accidentally includ=
ed that code change? Hard to say what the intent was.).=C2=A0</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">@=
Jorge:</div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)">That&#39;s one part of it t=
hat is worth hesitation and consideration. I&#39;m not a fan of the 520 byt=
e limit as well. My gut feeling is that the &quot;right&quot; answer is to =
compute the memory weight of the entire stack before/after each operation a=
nd reasonably bound it.</div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)">Below text is from the chain core docum=
entation:</div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)">&quot;&quot;&quot;</div>Most instructions use only th=
e data stack by removing some items and then placing some items back on the=
 stack. For these operations, we define the standard memory cost applied as=
 follows:<br><br>Instruction=E2=80=99s memory cost value is set to zero.<br=
>For each item removed from the data stack, instruction=E2=80=99s memory co=
st is decreased by 8+L where L is the length of the item in bytes.<br>For e=
ach item added to the data stack the cost is increased by 8+L where L is th=
e length of the item in bytes.<br><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">=E2=
=80=8B----=E2=80=8B</div>Every instruction has a cost that affects VM run l=
imit. Total instruction cost consists of execution costand memory cost. Exe=
cution cost always reduces remaining run limit, while memory usage cost can=
 be refunded (increasing the run limit) when previously used memory is rele=
ased during VM execution.<br>&quot;&quot;&quot;<div><span style=3D"color:rg=
b(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><spa=
n style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0);display:inline">=E2=80=8BIs there a reason to f=
avor one approach over the other? I think one reason to favor a direct limi=
t on op_cat is it favors what=E2=80=8B</div>=E2=80=8B<div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0);display:inline">=E2=80=8B I&#39;ll dub &quot;context free&quot=
; analysis, where the performance doesn&#39;t depend on what else is on the=
 stack (perhaps by passing very large arguments to a script you can cause b=
ad behavior with a general memory limit?).=E2=80=8B On the other hand, the =
reason I prefer the general memory limit is it solves the problem for all f=
uture memory-risky opcodes (or present day memory risks!). Further, OP_CAT =
is also a bit leaky, in that you could be catting onto a passed in large st=
ring.=C2=A0 The chief argument I&#39;m aware of against a general memory li=
mit argument is that it is tricky to make a non-implementation dependent me=
mory limit (e.g., can&#39;t just call DynamicMemoryUsage on the stack), but=
 I don&#39;t think this is a strong argument for several (semi-obvious? I c=
an go into them if need be) reasons.</div></span><div><br></div></div><div =
class=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"m_81594294228644=
40324gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">-=
-<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyR=
ubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a><=
/div></div></div>
<br><div class=3D"gmail_quote">On Wed, Jan 4, 2017 at 9:45 AM, Jorge Tim=C3=
=B3n <span dir=3D"ltr">&lt;<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_b=
lank">jtimon@jtimon.cc</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"auto">I would assume that the controversial part of op_cat =
comes from the fact that it enables covenants. Are there more concerns than=
 that?</div><div class=3D"m_8159429422864440324HOEnZb"><div class=3D"m_8159=
429422864440324h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On 4 Jan 2017 04:14, &quot;Russell O&#39;Connor via bitcoin-dev&quot; &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br type=3D"attri=
bution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>For the record=
, the OP_CAT limit of 520 bytes was <a href=3D"https://github.com/bitcoin/b=
itcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-8458adcedc17d04=
6942185cb709ff5c3R425" target=3D"_blank">added by Satoshi</a> on the famous=
 August 15, 2010 &quot;misc&quot; commit, at the same time that OP_CAT was =
disabled.<br></div>The previous limit was 5000 bytes.<br><div><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jan 3, 2017 at 7:13 PM=
, Jeremy via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
a<wbr>tion.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-size=
:small;color:#000000">Sure, was just upper bounding it anyways. Even less o=
f a problem!</div><div style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000"><br></div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000"><br></div><div style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:#000000">RE: OP_CAT=
, not as OP_CAT was specified, which is why it was disabled. As far as I kn=
ow, the elements alpha proposal to reenable a limited op_cat to 520 bytes i=
s somewhat controversial...</div><div style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"><br></div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div=
 class=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"m_8159429422864=
440324m_-8000223808657756393m_7822325097514973326m_6723432281491834920m_-62=
03106839964574959gmail_signature" data-smartmail=3D"gmail_signature"><div d=
ir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_bla=
nk">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_=
blank"></a></div></div></div><div><div class=3D"m_8159429422864440324m_-800=
0223808657756393m_7822325097514973326h5">
<br><div class=3D"gmail_quote">On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:jl2012@xbt.hk" target=3D"_blank">j=
l2012@xbt.hk</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div s=
tyle=3D"word-wrap:break-word"><div>No, there could only have not more than =
201 opcodes in a script. So you may have 198 OP_2DUP at most, i.e. 198 * 52=
0 * 2 =3D 206kB</div><div><br></div><div>For OP_CAT, just check if the retu=
rned item is within the 520 bytes limit.</div><div><div class=3D"m_81594294=
22864440324m_-8000223808657756393m_7822325097514973326m_6723432281491834920=
m_-6203106839964574959h5"><br><div><blockquote type=3D"cite"><div>On 3 Jan =
2017, at 11:27, Jeremy via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wb=
r>tion.org</a>&gt; wrote:</div><br class=3D"m_8159429422864440324m_-8000223=
808657756393m_7822325097514973326m_6723432281491834920m_-620310683996457495=
9m_659871600986875938Apple-interchange-newline"><div><div dir=3D"ltr"><div =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small"><span styl=
e=3D"font-family:arial,sans-serif;color:rgb(34,34,34);font-size:12.80000019=
0734863px">It is an unfortunate script, but can&#39;t actually=C2=A0</span>=
<div style=3D"display:inline">=E2=80=8Bdo</div><span style=3D"font-family:a=
rial,sans-serif;color:rgb(34,34,34);font-size:12.800000190734863px">=C2=A0t=
hat much</span><div style=3D"display:inline">=E2=80=8B it seems=E2=80=8B</d=
iv><span style=3D"font-family:arial,sans-serif;color:rgb(34,34,34);font-siz=
e:12.800000190734863px">. The MAX_SCRIPT_ELEMENT_SIZE =3D 520 Bytes.</span>=
<div style=3D"font-family:arial,sans-serif;color:rgb(34,34,34);font-size:12=
.800000190734863px;display:inline"><font face=3D"arial, helvetica, sans-ser=
if">=E2=80=8B Thus, it would seem the worst you could do with this would be=
 to=C2=A0</font>(10000-520*2)*520*2 bytes =C2=A0~=3D~ 10 MB.</div></div><di=
v style=3D"font-size:12.800000190734863px"><br></div><div style=3D"font-siz=
e:12.800000190734863px"><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small">=E2=80=8BMuch more concerning would be the op_dup/op_cat=
 style bug, which under a similar script =E2=80=8Bwould certainly cause out=
 of memory errors :)</div><div><br></div></div></div><div class=3D"gmail_ex=
tra"><br clear=3D"all"><div><br clear=3D"all"><div><div class=3D"m_81594294=
22864440324m_-8000223808657756393m_7822325097514973326m_6723432281491834920=
m_-6203106839964574959m_659871600986875938gmail_signature" data-smartmail=
=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/=
JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.c=
om/JeremyRubin" target=3D"_blank"></a></div></div></div>
</div>
<br><div class=3D"gmail_quote">On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis =
via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tio=
n.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D=
"word-wrap:break-word"><div><div style=3D"color:rgb(34,34,34);font-family:a=
rial,sans-serif;font-size:12.800000190734863px">Hi all,</div><div style=3D"=
color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8000001907348=
63px"><br></div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-se=
rif;font-size:12.800000190734863px">Suppose someone were to use the followi=
ng pk_script:</div><div style=3D"color:rgb(34,34,34);font-family:arial,sans=
-serif;font-size:12.800000190734863px"><br></div><div class=3D"m_8159429422=
864440324m_-8000223808657756393m_7822325097514973326m_6723432281491834920m_=
-6203106839964574959m_659871600986875938m_-8615729711671762748m_85917479010=
13163489gmail_signature" style=3D"color:rgb(34,34,34);font-family:arial,san=
s-serif;font-size:12.800000190734863px"><div dir=3D"ltr">[op_2dup, op_2dup,=
 op_2dup, op_2dup, op_2dup, ...(to limit)..., op_2dup,=C2=A0op_hash160, &lt=
;addr_hash&gt;, op_equalverify, op_checksig]</div><div dir=3D"ltr"><br></di=
v><div>This still seems to be valid AFAICS, and may be a potential attack v=
ector?</div><div><br></div><div>Thanks.</div></div></div><div><br></div></d=
iv><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div><br></div>
______________________________<wbr>_________________<br>bitcoin-dev mailing=
 list<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br><a href=3D"https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank=
">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev<=
/a><br></div></blockquote></div><br></div></div></div></blockquote></div><b=
r></div></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div></div>
</div></div></blockquote></div><br></div></div>

--001a114447ca543eea05455b500a--