Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E5F6B2C for ; Wed, 4 Jan 2017 03:14:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com [209.85.216.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7434E110 for ; Wed, 4 Jan 2017 03:14:15 +0000 (UTC) Received: by mail-qt0-f175.google.com with SMTP id k15so241475586qtg.3 for ; Tue, 03 Jan 2017 19:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i8YLaAdhU3c42VM/sfkBB5MzRaJcjOb5G8fcWD4N/jc=; b=Kk3E1jI6BxVU2Ult2MrhdUg5bTJ0Y+efT/zt/CCGQDSHIWPZF1DkR2T1uKd2+x3+68 Wkb6JjSugfm27w31uK7jVxPCVr5LVWpYhBiYMu43Mv/zAJEfdSI4bErhRHvI5VtGOgnL TmgFXhyuWF2XKCAKrEq1u32sI8AAr9EpMeqOEaI58C/8BF+cbMuolPRVVbHGFvqXql3Y cERf9FtB0xDhUWBZ+3wh4rtw2BpmKVkhNFJ3LBizAr21JBomcmpK96r4KkE5skdQ3rSa rJRJ97qTKl7jJuGJEloCwqe9b/+3MZ76s1dHbPOoSX7ExY1caxhLJwWFN55Lo2I40htx uXTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i8YLaAdhU3c42VM/sfkBB5MzRaJcjOb5G8fcWD4N/jc=; b=DiWpH9l1eX1TiNREalN+vLDGTHtyIasTXDDu2NHaK3dGzzDb3s6sftHiMOsb/s3CF2 zTCbnRS16RSZCjpJELTcWgasIeC2uyJONs/CXMuJv63QbV70AL70b/nsjikwqrxP15FR RusDywf/I27/hh2HyBi+rQMcAem7xRgxOQtJpXJyo58+WLj9YdoftRckEBUeIcxKyE/k FnUCgdgMqa15DMXt4edLUW+X/TrbUcadwdAvvr+u7S5zGZQmp9JqQAcGAejOceN6XMpH 1FscyihMWD9XRhzcbADK+UBsw7LRai1EtroohYJfMfJ7HQivV1/eUcfMjmSVYK3c99D/ ofcA== X-Gm-Message-State: AIkVDXLymzA9khU1je4a6eI7fGSee4CIbsV2MWU65yxtprZxwynUM1J8tsxqAQQJsbVBVN93OgIPMDr7azS1ydcM X-Received: by 10.237.34.116 with SMTP id o49mr59857537qtc.37.1483499654669; Tue, 03 Jan 2017 19:14:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.130.133 with HTTP; Tue, 3 Jan 2017 19:13:54 -0800 (PST) In-Reply-To: References: <400152B9-1838-432A-829E-13E4FC54320C@gmail.com> <6A91D4E4-750D-42C0-B593-3D5014B8A3F7@xbt.hk> From: "Russell O'Connor" Date: Tue, 3 Jan 2017 22:13:54 -0500 Message-ID: To: Jeremy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a113e7bf6f1076205453c2dee X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Steve Davis 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 03:14:17 -0000 --001a113e7bf6f1076205453c2dee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For the record, the OP_CAT limit of 520 bytes was added by Satoshi on the famous August 15, 2010 "misc" commit, at the same time that OP_CAT 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 t= o > 520 bytes is somewhat controversial... > > > > -- > @JeremyRubin > > > On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau wrote: > >> 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 * 520 * 2 =3D 206kB >> >> For OP_CAT, just check if the returned item is within the 520 bytes limi= t. >> >> 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 be = to (10000-520*2)*520*2 >> bytes ~=3D~ 10 MB. >> >> =E2=80=8BMuch more concerning would be the op_dup/op_cat style bug, whic= h under a >> similar script =E2=80=8Bwould certainly cause out of memory errors :) >> >> >> >> -- >> @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, , 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 > > --001a113e7bf6f1076205453c2dee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For the record, the OP_CAT limit of 520 bytes was added by Satoshi= on the famous August 15, 2010 "misc" commit, at the same tim= e that OP_CAT was disabled.
The previous limit was 5000 bytes.
=

On Tue, Jan = 3, 2017 at 7:13 PM, Jeremy via bitcoin-dev <bitcoin-de= v@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. A= s far as I know, the elements alpha proposal to reenable a limited op_cat t= o 520 bytes is somewhat controversial...

<= br>


On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau= <j= l2012@xbt.hk> wrote:
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

For OP_CAT, just check if the retu= rned item is within the 520 bytes limit.

On 3 Jan 2017, at 11:27, Jeremy via bitcoin-dev <bitcoin-dev@lists.lin= uxfoundation.org> wrote:

=
It is an unfortunate script, but can't= actually=C2=A0
=E2=80=8Bdo
=C2=A0that much
=E2=80= =8B it seems=E2=80=8B
. The MAX_SCRIPT_ELEMENT_SI= ZE =3D 520 Bytes.
=E2=80=8B Thus, it would seem the worst you cou= ld do with this would be to=C2=A0(10000-520*2)*520*2 bytes =C2=A0~= =3D~ 10 MB.

=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>

On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis = via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:
Hi all,

Suppose someone were to use the followi= ng pk_script:

[op_2du= p, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)..., op_2dup,=C2=A0op_h= ash160, <addr_hash>, op_equalverify, op_checksig]

This still seems to be valid AFAICS, and may be a potenti= al 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<= /a>


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a113e7bf6f1076205453c2dee--