Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D596DB3E for ; Wed, 4 Jan 2017 14:45:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DD1D8108 for ; Wed, 4 Jan 2017 14:45:55 +0000 (UTC) Received: by mail-ua0-f181.google.com with SMTP id i68so247384687uad.0 for ; Wed, 04 Jan 2017 06:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EomjKsUL6ta0ZOzOWC4/GcdT8VnodX90+CseSxd3UyY=; b=aUl/Tm3sTc+ZkI7Zjl6bOTF5VdI8CL8fG9jtULi6TwLSshKujO9sIY2mXpnvuM24+v 3SeOdqnCUtX98bERfLMOiv+mL06QHKWbQuQQoGrU4giqTb+DW5A2VPDouRDar020+SgB 6xTVHft6BlX+uc8rq+08C3as05/qlDR8GZLaqYhV9OvRgQexy+dtOiiLIMw8FQ92pxpf TET/TS2QvfKBIIDwdtdUhDkiJR4xapTOpVGsaIzuTgfUPssIfsEOOrTv6clEZ1Y5jZGf eoBUAHFP2Wwr5cSdiFDyGKd5AOWs64kqLKhD/HlxjxwyD4Ar6D2L1PBDLHB12G0QlNP4 LWrg== 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=EomjKsUL6ta0ZOzOWC4/GcdT8VnodX90+CseSxd3UyY=; b=FbnwnbCnXXqzZMMKJ0zI6d5LuOpVuGputr8tgFiPEfGBLck5yZXMVE5GDcUB+GJZwN 5yA0Xuwaa7qeKlynKHDWZCyxSvezNn0e2UXBZPBOcj65zFlKWq3Iiz0qzzOqeUZFvJJ4 SFc5fZXWd/9m9BNHIbMWYSg8yddfMJBaNLmagIwi/nNHJpV+UMyxfRbVpWm8O7TfTKba QdgFTRMFSbFL7xXR9Q4j1bGsD5+i68SD1uoyTikhiLYFa+/xn6RjUozMNkiJqBOUK95B 4aEjCL0rOedstJ4H1DNbRH9ctDEIT7nwOWesVBZtFEkMDKq9DxXqQuZxDRvgpqgv+SWw dG+A== X-Gm-Message-State: AIkVDXIMZa8zDuJhxnY+J9m7hcIuMWC2IlEo9XwHayVFoRQiBLvc9Ys1rV8kS9qksiJ+E4J4lsyc/8hgvhywMw== X-Received: by 10.176.84.8 with SMTP id n8mr49944915uaa.29.1483541154889; Wed, 04 Jan 2017 06:45:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.216.130 with HTTP; Wed, 4 Jan 2017 06:45:54 -0800 (PST) Received: by 10.31.216.130 with HTTP; Wed, 4 Jan 2017 06:45:54 -0800 (PST) In-Reply-To: References: <400152B9-1838-432A-829E-13E4FC54320C@gmail.com> <6A91D4E4-750D-42C0-B593-3D5014B8A3F7@xbt.hk> From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Wed, 4 Jan 2017 15:45:54 +0100 Message-ID: To: "Russell O'Connor" , Bitcoin Dev Content-Type: multipart/alternative; boundary=94eb2c1b2d7e8c6e61054545d70e X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no 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 14:45:57 -0000 --94eb2c1b2d7e8c6e61054545d70e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 > > 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 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 = to >> 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 >>> 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 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, whi= ch 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 >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c1b2d7e8c6e61054545d70e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would assume that the controversial part of op_cat come= s from the fact that it enables covenants. Are there more concerns than tha= t?

On 4 Jan = 2017 04:14, "Russell O'Connor via bitcoin-dev" <bitcoin-dev@lists.linuxfound= ation.org> wrote:
For the record, the OP_CAT limit of 520 bytes wa= s added by Satoshi on the famous August 15, 2010 "misc" = commit, at the same time that OP_CAT was disabled.
The previous li= mit was 5000 bytes.

On Tue, Jan 3, 2017 at 7:13 PM, Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrot= e:
Sure, was ju= st upper bounding it anyways. Even less of a problem!


RE: OP_CAT, not as OP_CAT was specified, whi= ch 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...
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#= 000000">



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.linuxfoundation.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_SIZE =3D 520 Bytes.
=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.

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




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_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)..= ., op_2dup,=C2=A0op_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<= /a>


_______________________________________________
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

--94eb2c1b2d7e8c6e61054545d70e--