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 102C41BB for ; Mon, 4 Jul 2016 23:27:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148098.authsmtp.com (outmail148098.authsmtp.com [62.13.148.98]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id E8486A1 for ; Mon, 4 Jul 2016 23:27:19 +0000 (UTC) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u64NRIr6087894; Tue, 5 Jul 2016 00:27:18 +0100 (BST) 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.14.2/8.14.2/) with ESMTP id u64NRG7g003221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jul 2016 00:27:17 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id A654D40087; Mon, 4 Jul 2016 23:24:59 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 82D3B2032A; Mon, 4 Jul 2016 19:27:15 -0400 (EDT) Date: Mon, 4 Jul 2016 19:27:15 -0400 From: Peter Todd To: Johnson Lau Message-ID: <20160704232715.GA21569@fedora-21-dvm> References: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk> <20160702184350.GA16656@fedora-21-dvm> <9E7B8E07-4F98-42DD-8A35-C55DAF78271F@xbt.hk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <9E7B8E07-4F98-42DD-8A35-C55DAF78271F@xbt.hk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: d8f5fe7d-423e-11e6-bcde-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgcUEkAYAgsB AmAbW1ReUlp7WGQ7 bghPaBtcak9QXgdq T0pMXVMcUQNsf352 AUkeUhpwdQQIeX93 ZkAsCngNWRIvchJg RkxXQHAHZDJmdTJM BBVFdwNVdQJNeEwU a1l3GhFYa3VsNCMk FAgyOXU9MCtqYA9S TgxFF18MQEsUTHYA Rx1KNjIpBkADXDgo Zzc8K0IdF08Ven07 K0c6EVUWUVcpBwJB Hl0FCj4RH1QdSjBj MQRWUSYA X-Authentic-SMTP: 61633532353630.1038: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 Cc: bitcoin-dev Subject: Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of Segwit by Peter Todd 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: Mon, 04 Jul 2016 23:27:21 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 03, 2016 at 03:20:42AM +0800, Johnson Lau wrote: > >>> the fact that we do this has a rather odd result: a transaction spend= ing a witness output with an unknown version is valid even if the transacti= on doesn=E2=80=99t have any witnesses! > >>=20 > >> I don=E2=80=99t see any reason to have such check. We simply leave unk= nown witness program as any-one-can-spend without looking at the witness, a= s described in BIP141. > >=20 > > It will lead to a special case in code that does things with witness > > transactions, as we can spend a witness output without a witness. >=20 > It is trivial to softfork a new rule to require the witness must not be e= mpty for a witness output. However, does it really make the code simpler? The Bitcoin Core codebase, no, but it does reduce the number of special cas= es other codebases have to contend with. Probably not worth changing now, but it was I think a weird design choice to make. > > Thus you could summarize the argument for the P2PKH special case as "We= don't > > want to make it possible to use 160-bit commitments for multisig, which= _might_ > > need 256-bit security. But we do want to special-case pubkeys to save a= few > > bytes.=E2=80=9D >=20 > Actually I would like to see even shorter hash and pubkey to be used. Sto= ring 1 BTC for a few months does not really require the security level of P= 2PKH. How short? 128 bits? 80 bits? 64 bits? It's hard to know what's the point where you're going to risk massive losses due to theft... and as we've seen with the DAO, those kinds of losses can l= ead to very undesirable pressure for devs to act as a central authority and intervene. > >>> we haven=E2=80=99t explicitly ensured that signatures for the new sig= nature hash can=E2=80=99t be reused for the old signature hash > >>=20 > >> How could that be? That=E2=80=99d be a hash collision. > >=20 > > Nope. The problem is it might not be a hash collission, if the actual b= ytes > > signed can be interpreted in two different ways, by different types of > > signature hashes. > >=20 > > This is the same reason the signmessage functionality prepends the mess= age > > being signed with the "Bitcoin Signed Message:\n" magic string. > >=20 >=20 > In BIP143 sig, first 4 bytes is nVersion, and the next 32 bytes (hashPrev= outs) is a hash of all prevouts. (in the case of ANYONECANPAY, the bytes fo= llowing would be zero, as you proposed) >=20 > In the original sig, first 4 bytes in nVersion, next 4 bytes is number of= inputs, and the next 32 bytes is a txid. >=20 > For a signature to be valid for both schemes, the last 28 bytes of the ha= shPrevouts must also be the first 28 bytes of a valid txid. This is already= impossible. And this is just one of the many collisions required. In such = case SHA256 would be insecure and adding a zero after the nVersion as you s= uggest would not be helpful at all. Why isn't this carefully documented in the BIPs then? Again, as I said in my summary: In a number of places we either have a belt, or suspenders, when given = the importance of this code we=E2=80=99d rather have both a belt and suspen= ders. Tagged hashing is an excellent way to absolutely sure that signatures can't= be reused in different contexts; if it happens to be overkill in a specific context, the overhead of hashing another few bytes is trivial; the gain of being absolutely sure you haven't missed a vulnerability can't be easily dismissed. Equally, I think in most cases simply XORing the digest obtained by hashing with a magic tag prior to using it (e.g. by signing it) should be sufficient for signature applications, and the overhead of doing that is ~zero. Essentially you can think of the magic tag that's XORed with the raw digest= as making clear the intent of the signature: "this is why I think I'm signing = this digest" However, the XOR option does have one potentially big downside in other contexts, like general use in committed data structures: it's incompatible = with timestamping schemes like OpenTimestamps that rely on all operations being cryptographically secure. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXevDQAAoJEGOZARBE6K+yTbMH/jR3n+36qcYSD1knvABYJjIp gr+9O2u0E82MFH5PMAuaD+ycuFPbgYleeh7gajrdMRdL2pgUzjERCVj29miaAHZw BnRTUJmjazZiDa82Upsra8KWDkKvRuHyzpBP6ceUkGJSgkwlnwvwVFJDvm21Gi0B aOe0e6wRdV/YH4Ix/pdZOUgQ1lojIw+4EPGjXtnbTdH9fhB5TyTC6QbltgmNPCUl 1MXYZOX3lI98Gip7L/l4SA22o62/kh8rqE9pASfwZVL9zI7zOmb5VLV4SvvMfzgO kOL0mZiWKHUO055s0/wShUDtXguZSafcAxkuWYjBLZ+mxukz80Jh31Dp4GF32bE= =1cb+ -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9--