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 9EE0A899 for ; Wed, 6 Jun 2018 00:49:07 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148113.authsmtp.com (outmail148113.authsmtp.com [62.13.148.113]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 14FC36DC for ; Wed, 6 Jun 2018 00:49:06 +0000 (UTC) Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt20.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w560n5IB075558; Wed, 6 Jun 2018 01:49:05 +0100 (BST) (envelope-from user@petertodd.org) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id w560n2q3009136 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Jun 2018 01:49:04 +0100 (BST) (envelope-from user@petertodd.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 9403D400D0; Wed, 6 Jun 2018 00:49:02 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 2E9C122043; Tue, 5 Jun 2018 20:49:01 -0400 (EDT) Date: Tue, 5 Jun 2018 20:49:01 -0400 From: Peter Todd To: Johnson Lau , Bitcoin Protocol Discussion Message-ID: <20180606004901.zqkpro2by7xj4jpc@petertodd.org> References: <9FC9FA73-9572-48AF-9590-68F0D298D6A0@xbt.hk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vg2ioecb5bvrkrzd" Content-Disposition: inline In-Reply-To: <9FC9FA73-9572-48AF-9590-68F0D298D6A0@xbt.hk> User-Agent: NeoMutt/20170113 (1.7.2) X-Server-Quench: 6917c3a7-6923-11e8-a283-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZIVwkA IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgQUEkAaAgsB Am4bW1VeVFR7WWc7 bghPaBtcak9QXgdq T0pMXVMcUwBuAUID Rx0eUhBzdAMIfXZ1 bQhkV3FcD0crclt7 S0xXCGwHMG99OWIX U11RJFFSdQcYLB1A alQxNiYHcQ5VPz4z GA41ejw8IwAXBCVO SwUJKk1aQEAQEzUh XR1KAC4iVUoLDx4S ADwPEX4rJ2c3HWEf WQAA X-Authentic-SMTP: 61633532353630.1039:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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:49:07 -0000 --vg2ioecb5bvrkrzd Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 01, 2018 at 02:53:01AM +0800, Johnson Lau via bitcoin-dev wrote: > I=E2=80=99ve made a PR to add a new policy to disallow using SIGHASH_SING= LE without matched output: >=20 > https://github.com/bitcoin/bitcoin/pull/13360 >=20 > 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, wh= ich is effectively SIGHASH_NOINPUT|SIGHASH_NONE, so any UTXO of the same ke= y could be stolen. (It=E2=80=99s restricted to only one UTXO in segwit, but= it=E2=80=99s still like a SIGHASH_NONE.) >=20 > This is one of the earliest unintended consensus behavior. Since these si= gnatures are inherently unsafe, I think it does no harm to disable this uni= ntended =E2=80=9Cfeature=E2=80=9D with a softfork. But since these signatur= es are currently allowed, the first step is to make them non-standard. I don't see why we should bother to soft fork this out on the basis of security, given that there are many other ways to insecurely use private ke= ys (e.g. reused nonces). Maybe soft-fork it out on the basis of code complexit= y, but this sounds like a lot of work. Also, I have to wonder if it's just as likely the devs might think the non-standardness means it is secure. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --vg2ioecb5bvrkrzd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAlsXL3gACgkQJIFAPaXw kfsq8wf/eQgqEW2kyiOPj6qtMatonFsY8ob1uCaS7cJNIed4xW79nuHR88qWj6wr unCxTFtCWrafSi595VHBqBss8ow19IplNAkcIPDAjmDA2uj2TNupYWtbakMJttWj uNdPdOiPAjFnsYNwt0/3CR07bQeG6HKAyc/MP9/rqsdGNcxHxxBsq+cOamtwdAu6 dgrfFb1IgmViBtVD8xUXpFMjaNLMigZZWJ+GzKXcDTMcmb7SdDd+1PpLAKv/Pg6K tcS40pCQEg6e+2Cf3Lu+Yf4XT/nriiRMCtsZDBWEvauhH4H7FDhfiUeXyu5dy1cn QxeAXtS5dWOwcpvekNnBYclTJwk4hw== =0gft -----END PGP SIGNATURE----- --vg2ioecb5bvrkrzd--