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 286771069 for ; Thu, 31 May 2018 18:53:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 987236E8 for ; Thu, 31 May 2018 18:53:08 +0000 (UTC) Received: from [10.8.0.110] (n218103136198.netvigator.com [218.103.136.198]) by mx.zohomail.com with SMTPS id 1527792784839133.90783089412503; Thu, 31 May 2018 11:53:04 -0700 (PDT) From: Johnson Lau Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <9FC9FA73-9572-48AF-9590-68F0D298D6A0@xbt.hk> Date: Fri, 1 Jun 2018 02:53:01 +0800 To: bitcoin-dev X-Mailer: Apple Mail (2.3445.5.20) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 Subject: [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: Thu, 31 May 2018 18:53:09 -0000 I=E2=80=99ve made a PR to add a new policy to disallow using = SIGHASH_SINGLE without matched output: https://github.com/bitcoin/bitcoin/pull/13360 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, which 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 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 signatures are currently allowed, the first step is to make them = non-standard.=