Date: Sat, 2 Jul 2016 14:43:50 -0400
From: Peter Todd <pete@petertodd.org>
To: Johnson Lau <jl2012@xbt.hk>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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)
Subject: Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of
 Segwit by Peter Todd
Precedence: list


--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: <version> <serialized witness script>
>=20
> Something wrong here? In P2WPKH, the witness is <sig> <pubkey>

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:

    <sig> <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:

    <sig>

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--