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 87BF771 for ; Sat, 2 Jul 2016 18:44:28 +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 91F9D122 for ; Sat, 2 Jul 2016 18:44:27 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u62IiPPh009672; Sat, 2 Jul 2016 19:44:25 +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 u62IiOib071123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jul 2016 19:44:25 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id EAA3040122; Sat, 2 Jul 2016 18:42:08 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id DA1FF20341; Sat, 2 Jul 2016 14:43:50 -0400 (EDT) Date: Sat, 2 Jul 2016 14:43:50 -0400 From: Peter Todd To: Johnson Lau , Bitcoin Protocol Discussion Message-ID: <20160702184350.GA16656@fedora-21-dvm> References: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: ffdfb195-4084-11e6-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgAUEkAYAgsB AmAbWl1eVFl7W2Y7 bghPaBtcak9QXgdq T0pMXVMcUQNqeEV+ X0weVRhzdQYIeX13 bUYsCCYPChZ7fENg Rk5cEXAHZDJmdWgd WRVFdwNVdQJNdxoR b1V5GhFYa3VsNCMk FAgyOXU9MCtqYA9S TgxFF18MQEsUTHYA Rx1KNjIpBkADXDgo Zzc8K0IdF08Ven07 K0c6EVUWUVcpBwJB Hl0FCj4RH1QdSjBj MQRWUSYA X-Authentic-SMTP: 61633532353630.1037: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] 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: Sat, 02 Jul 2016 18:44:28 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 29, 2016 at 12:22:45AM +0800, Johnson Lau via bitcoin-dev wrote: > Thanks for Peter Todd=E2=80=99s detailed report: > https://petertodd.org/2016/segwit-consensus-critical-code-review >=20 > I have the following response. >=20 > >Since the reserve value is only a single, 32-byte value, we=E2=80=99re s= etting ourselves up for the same problem again7. >=20 > Please note that unlimited space has been reserved after the witness comm= itment: >=20 > block.vtx[0].vout[o].scriptPubKey.size() >=3D 38 >=20 > Which means anything after 38 bytes has no consensus meaning. Any new co= nsensus critical commitments/metadata could be put there. Anyway, there is = no efficient way to add a new commitment with softfork. Sure - equally you could say you could add additional commitments as other coinbase txouts. My point is that the extensible commitment - specifically the thing describ= ed in the BIP - can't be easily used for the purpose of extending segwit due t= o a design flaw. > > the fact that we do this has a rather odd result: a transaction spendin= g a witness output with an unknown version is valid even if the transaction= doesn=E2=80=99t have any witnesses! >=20 > I don=E2=80=99t see any reason to have such check. We simply leave unknow= n witness program as any-one-can-spend without looking at the witness, as d= escribed in BIP141. 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. > > Bizzarely segwit has an additonal pay-to-witness-pubkey-hashP2WPKH that= lets you use a 160-bit (20 byte) commitment=E2=80=A6=E2=80=A6 >=20 > Since ~90% of current transactions are P2PKH, we expect many people will = keep using this type of transaction in the future. P2WPKH gives the same le= vel of security as P2PKH, and smaller scriptPubKey. >=20 > >give users the option instead to choose to accept the less secure 160-bi= t commitment if their use-case doesn=E2=80=99t need the full 256-bit securi= ty level >=20 > This is actually discussed on the mailing list. P2WSH with multi-sig is s= ubject to birthday attack, and therefore 256-bit is used to provide 128-bit= security. P2WPKH is used as single sig and therefore 160-bit is enough. I'm aware of that - there are many P2SH scripts where birthday attacks are = not an issue. In fact, _most_ usage of P2SH right now - multifactor wallets - doesn't have a birthday attack problem. > >Secondly, if you are going to give a 160-bit commitment option, you don= =E2=80=99t need the extra level of indirection in the P2SH case: just make = the segwit redeemScript be: >=20 > Something wrong here? In P2WPKH, the witness is Huh? That still another level of indirection. Anyway, the right argument against my proposal for pay-to-pubkey-hash functionality, is that taking into account the witness discount, my proposa= l is slightly less efficient. In P2WPKH in P2SH the witness program in the redeemScript is 22 bytes: <1-byte version> <1-byte length> <20 byte pubkey hash> And the witness len(sig) + 34 bytes: <1 byte length> <33 bytes pubkey> Taking into account the discount, that results in 22*4 + 34 + len(sig) =3D = 122 bytes + len(sig) My proposal would have a 37 byte redeemScript: <1-byte version> <1-byte witness script length> {<1-byte pubkey length>= <33 byte pubkey> OP_CHECKSIG} and a len(sig) length witness: Taking into account the discount, that results in 37*4 + len(sig) =3D 148 b= ytes + len(sig) Meanwhile for any more complex script, you'd certainly want to use the 256-= bit hash instead, due to the witness discount. This suggests an obvious alternative: let users choose to use 160-bit secur= ity, and make 256-bit and 160-bit witness programm commitments just be different hash functions. P2PKH functionality implemented this way would be a single extra byte vs. special-casing it. 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 _mi= ght_ need 256-bit security. But we do want to special-case pubkeys to save a few bytes." > >The only downside is the serialized witness script is constrained to 520= bytes max >=20 > 520 is the original limit. BIP141 tries to mimic the existing behaviour a= s much as possible. Anyway, normally nothing in the current scripts should = use a push with more than 75 bytes No, you're quite confused at my point: the witness script is otherwise constrained to 10,000 bytes, as the first item in the witness is special-ca= sed for version 0 to be not be subject to the 520 byte rule. > >we haven=E2=80=99t explicitly ensured that signatures for the new signat= ure 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. Nope. The problem is it might not be a hash collission, if the actual bytes signed can be interpreted in two different ways, by different types of signature hashes. This is the same reason the signmessage functionality prepends the message being signed with the "Bitcoin Signed Message:\n" magic string. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXeAtjAAoJEGOZARBE6K+yDSIH/3FOj9uRwgav5+rGc8KkX82t Gtkr5O6iQvf4pkd3GruUiwR5fKCGoTy6NU//NizlAW8uvNoQT3k9b3dm/CpPHMA/ mblXxEloYUxTdA/34E9fscBmWXRXv+ecWnnt+6aWFtrb681ccyf5PRqe60kIpc0r wk7dw1wq/2Q/fM97CZTfUdP4qfMaZ9pu9DFDzv4s9SojrBdu/wh4EpNLXm6eWGMI 5kdxJe79RObvKHmRLni7XkDGpGJ+i5+DX7biaMefQcvZF8/2F5blpAAnerIvp95/ i+BSqI4Xgpxyn0bw5ttpezJB5SDOtlVZdxOpmrzxOhE4GahIzu1XwemF41zwZ8g= =1H3Q -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF--