From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 49F85483 for ; Wed, 6 Jun 2018 00:22:57 +0000 (UTC) X-Greylist: delayed 00:05:01 by SQLgrey-1.7.6 Received: from so254-16.mailgun.net (so254-16.mailgun.net [198.61.254.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9AA59787 for ; Wed, 6 Jun 2018 00:22:56 +0000 (UTC) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com; q=dns/txt; s=mailo; t=1528244576; h=Content-Type: To: Subject: Message-ID: Date: From: References: In-Reply-To: MIME-Version: Sender; bh=PUgx0j/lZEGS15CQgkNqdjOvulTmnPpydTjpEUltlVQ=; b=odOjdUoRsIFV7ULWIuMGt0EVT3MNI6Xlhb9dwKJDFGxZmo2eWy1OzmzS9Tg+fQI270bnQRVx XSrR666yml22/wyb+Eqis01aHgTSFp9anGBgbbsRVsxdC2NDsmDiionFAs1XdVN2ORGnRP5Z eHT2yVQhfoaFKe4bkhX1Cfvuk3U= X-Mailgun-Sending-Ip: 198.61.254.16 X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0= Sender: chris@suredbits.com Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by mxa.mailgun.org with ESMTP id 5b172831.7f316a8572f0-smtp-out-n02; Wed, 06 Jun 2018 00:17:53 -0000 (UTC) Received: by mail-io0-f182.google.com with SMTP id s26-v6so5588221ioj.4 for ; Tue, 05 Jun 2018 17:17:53 -0700 (PDT) X-Gm-Message-State: APt69E3PDf9i6+XbEYw+4DWVFb0UU/5oSmhi3h+5P9f4X1kFErNbCX2S Q83fSJhxF6ptwxiUFnEtpiJn2l4oX58xCtEpShc= X-Google-Smtp-Source: ADUXVKJbKblXPUjBygVMa2P3PLc9mfbhLzLyeTXLmZrr1gmepqfyDN6BPwV6QFReF/4Poc29jfNTOwtYhZ5okCK8fNo= X-Received: by 2002:a6b:960d:: with SMTP id y13-v6mr854757iod.161.1528244273141; Tue, 05 Jun 2018 17:17:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:9cc9:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 17:17:52 -0700 (PDT) In-Reply-To: <9FC9FA73-9572-48AF-9590-68F0D298D6A0@xbt.hk> References: <9FC9FA73-9572-48AF-9590-68F0D298D6A0@xbt.hk> From: Chris Stewart Date: Tue, 5 Jun 2018 19:17:52 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Johnson Lau , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000007e473056dee19b4" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, 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: Wed, 06 Jun 2018 00:24:03 +0000 Subject: Re: [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE 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, 06 Jun 2018 00:22:57 -0000 --00000000000007e473056dee19b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Do you have any thoughts on expanding this to SIGHASH_NONE? Perhaps someone else on the dev list can enlighten me, but is there a current use case for SIGHASH_NONE that would suffer from it being non standard? -Chris On Thu, May 31, 2018 at 1:53 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I=E2=80=99ve made a PR to add a new policy to disallow using SIGHASH_SING= LE > without matched output: > > https://github.com/bitcoin/bitcoin/pull/13360 > > Signature of this form is insecure, as it commits to no output while user= s > might think it commits to one. It is even worse in non-segwit scripts, > which is effectively SIGHASH_NOINPUT|SIGHASH_NONE, so any UTXO of the sam= e > key could be stolen. (It=E2=80=99s restricted to only one UTXO in segwit,= but it=E2=80=99s > still like a SIGHASH_NONE.) > > This is one of the earliest unintended consensus behavior. Since these > signatures are inherently unsafe, I think it does no harm to disable this > unintended =E2=80=9Cfeature=E2=80=9D with a softfork. But since these sig= natures are > currently allowed, the first step is to make them non-standard. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000007e473056dee19b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do you have any thoughts on expanding this to SIGHASH= _NONE? Perhaps someone else on the dev list can enlighten me, but is there = a current use case for SIGHASH_NONE that would suffer from it being non sta= ndard?

-Chris


On Thu, May 31, 2018 at 1:53 PM, J= ohnson Lau via bitcoin-dev <bitcoin-dev@lists.linuxfou= ndation.org> wrote:
I=E2=80= =99ve made a PR to add a new policy to disallow using SIGHASH_SINGLE withou= t matched output:

https://github.com/bitcoin/bitcoin/pull/13360<= br>
Signature of this form is insecure, as it commits to no output while users = might think it commits to one. It is even worse in non-segwit scripts, whic= h is effectively SIGHASH_NOINPUT|SIGHASH_NONE, so any UTXO of the same key = could be stolen. (It=E2=80=99s restricted to only one UTXO in segwit, but i= t=E2=80=99s still like a SIGHASH_NONE.)

This is one of the earliest unintended consensus behavior. Since these sign= atures are inherently unsafe, I think it does no harm to disable this unint= ended =E2=80=9Cfeature=E2=80=9D with a softfork. But since these signatures= are currently allowed, the first step is to make them non-standard.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--00000000000007e473056dee19b4--