From: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Wed, 29 Jun 2016 00:22:45 +0800
Message-Id: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of
	Segwit by Peter Todd
Precedence: list


--Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks for Peter Todd=E2=80=99s detailed report:
https://petertodd.org/2016/segwit-consensus-critical-code-review

I have the following response.

>Since the reserve value is only a single, 32-byte value, we=E2=80=99re =
setting ourselves up for the same problem again7.

Please note that unlimited space has been reserved after the witness =
commitment:

  block.vtx[0].vout[o].scriptPubKey.size() >=3D 38

 Which means anything after 38 bytes has no consensus meaning. Any new =
consensus critical commitments/metadata could be put there. Anyway, =
there is no efficient way to add a new commitment with softfork.


> the fact that we do this has a rather odd result: a transaction =
spending a witness output with an unknown version is valid even if the =
transaction doesn=E2=80=99t have any witnesses!

I don=E2=80=99t see any reason to have such check. We simply leave =
unknown witness program as any-one-can-spend without looking at the =
witness, as described in BIP141.


> 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

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 =
level of security as P2PKH, and smaller scriptPubKey.

>give users the option instead to choose to accept the less secure =
160-bit commitment if their use-case doesn=E2=80=99t need the full =
256-bit security level

This is actually discussed on the mailing list. P2WSH with multi-sig is =
subject 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.


>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: <version> <serialized witness script>

Something wrong here? In P2WPKH, the witness is <sig> <pubkey>


>The only downside is the serialized witness script is constrained to =
520 bytes max

520 is the original limit. BIP141 tries to mimic the existing behaviour =
as much as possible. Anyway, normally nothing in the current scripts =
should use a push with more than 75 bytes


>we haven=E2=80=99t explicitly ensured that signatures for the new =
signature hash can=E2=80=99t be reused for the old signature hash

How could that be? That=E2=80=99d be a hash collision.


--Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQGcBAEBCgAGBQJXcqSVAAoJEO6eVSA0viTS998L/jOkRYqUfR7WmSuoj3y3JQ+o
+uLlAegQQVA1gLBloXh8c2PdGF9frn/FCAaiJec/rbXh2/9Pvwpq9QW2TLjGFAjT
5Ht+lTVZGdZHg9fU0jCZs53BRBO8v0v8xnUVpXovXxLiga8OHu5RxhtsGTGZLaq6
N1oNVbO9Z2yCihW+Tc8qTtHn1mjLZ0zc6IIRNbR9aCrH84euXu058HcvAHKcixGK
wCZFVS3U+K2EeHSzHyNWaG2pK9egCswAUBcnq6WPUOcknlO7Y1jT8DSI5Xr76h+W
baJ7XKlQ2FV6hdeP6S2XiRk3amJ+SG0HX3a/ZJYa4rNeaoC9yzIa7soXvWdC+D2P
+Q3XjLKWkc8X06OwownqUDg9Yst4jNQYeDplzySKtf6pWPNHyjKKvxThtw64s3Ve
Gv6bpJKRhUrolo4yIlMO1kdxGgOIkNtKQN4/0NdxWhzf9vyFI3ybqIbPGkVx7n7N
B2ndc1zWjZ+5xGNu7wRbWbRMEK9dCUaXgov7+bGcnQ==
=etKP
-----END PGP SIGNATURE-----

--Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893--