Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8";
	protocol="application/pgp-signature"; micalg=pgp-sha512
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <20160702184350.GA16656@fedora-21-dvm>
Date: Sun, 3 Jul 2016 03:20:42 +0800
Message-Id: <9E7B8E07-4F98-42DD-8A35-C55DAF78271F@xbt.hk>
References: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk>
	<20160702184350.GA16656@fedora-21-dvm>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of
	Segwit by Peter Todd
Precedence: list


--Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


>=20
>>> 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!
>>=20
>> 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.
>=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.

It is trivial to softfork a new rule to require the witness must not be =
empty for a witness output. However, does it really make the code =
simpler?
>=20
> 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

Actually I would like to see even shorter hash and pubkey to be used. =
Storing 1 BTC for a few months does not really require the security =
level of P2PKH.

>=20
>>> 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
>>=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 =
bytes
> 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 =
message
> being signed with the "Bitcoin Signed Message:\n" magic string.
>=20

In BIP143 sig, first 4 bytes is nVersion, and the next 32 bytes =
(hashPrevouts) is a hash of all prevouts. (in the case of ANYONECANPAY, =
the bytes following would be zero, as you proposed)

In the original sig, first 4 bytes in nVersion, next 4 bytes is number =
of inputs, and the next 32 bytes is a txid.

For a signature to be valid for both schemes, the last 28 bytes of the =
hashPrevouts 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 suggest would not be helpful at all.

--Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8
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

iQGcBAEBCgAGBQJXeBW6AAoJEO6eVSA0viTSoeoL/1xRq3zPc4Q9HMKwNNH/apAw
zdxIgmNTCMrX30DYg2Bs0xjBYRmuRegj6vGMHHXHNW1n5PLhR5ejY0jbUJOUAXww
M9zu6f7Hm3PTBkIL6U4kPk1090Y0ce6rGDY9DzSfmXwfyl90bbNDyCfHAVPZc2b5
oQM9qPiyj/X86od6EAa3fKp2/yWwpt553MoOlhxKi+m05zkMCUeyya7QYOsApz84
nZWerSXrZokqzOppOknVp8MVbDCHrVAyr++iQIAA02tHRTF01CFM3JvzdUFOUqmL
kZdG65UiauUhJo6/O/Njv2/D9Le2nrGlPULY2lesuO4a0JkvvgijgJkTUyUKnLmS
5VCWhYDNX0kmdL5lTIg1mLdZZQIVZ0GLzN3J0J9ua+K63BPafAeJap7SAUPty1+F
PTDXQphkRYCY1hve0iz5lMRnkFXvBVhPdwMLpDE489Nb/TYp5dm7Qls+SKcy6ils
+o4x3b9ps2f5isF4iJy9sWsyQQCRlDaGK6tJ9e2qZA==
=gGIw
-----END PGP SIGNATURE-----

--Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8--