From: Tamas Blummer <tamas@bitsofproof.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_32EFF217-B018-44CF-A0E9-1DC7C742830C";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <D89EBAA3-ED78-4D9C-B693-FBBF27501938@bitsofproof.com>
Date: Sun, 1 Feb 2015 10:33:48 +0100
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: [Bitcoin-development] var_int ambiguous serialization consequences
Precedence: list


--Apple-Mail=_32EFF217-B018-44CF-A0E9-1DC7C742830C
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_EC593710-1FB9-4AAB-92F0-A44D0068DF52"


--Apple-Mail=_EC593710-1FB9-4AAB-92F0-A44D0068DF52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I wonder of consequences if var_int is used in its longer than necessary =
forms (e.g encoding 1 as 0xfd0100 instead of 0x01)

This is already of interest if applying size limit to a block, since =
transaction count is var_int but is not part of the hashed header or the =
merkle tree.

It could also be used to create variants of the same transaction message =
by altered representation of txIn and txout counts, that would remain =
valid provided signatures validate with the shortest form, as that is =
created while re-serializing for signature hashing. An implementation =
that holds mempool by raw message hashes could be tricked to believe =
that a modified encoded version of the same transaction is a real double =
spend. One could also mine a valid block with transactions that have a =
different hash if regularly parsed and re-serialized. An SPV client =
could be confused by such a transaction as it was present in the merkle =
tree proof with a different hash than it gets for the tx with its own =
serialization or from the raw message.

Tamas Blummer
Bits of Proof


--Apple-Mail=_EC593710-1FB9-4AAB-92F0-A44D0068DF52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>I =
wonder of consequences if var_int is used in its longer than necessary =
forms (e.g encoding 1 as 0xfd0100 instead of =
0x01)</div><div><br></div><div>This is already of interest if applying =
size limit to a block, since transaction count is var_int but is not =
part of the hashed header or the merkle =
tree.</div><div><br></div><div>It could also be used to create variants =
of the same transaction message by altered representation of txIn and =
txout counts, that would remain valid provided signatures validate with =
the shortest form, as that is created while re-serializing for signature =
hashing. An implementation that holds mempool by raw message hashes =
could be tricked to believe that a modified encoded version of the same =
transaction is a real double spend. One could also mine a valid block =
with transactions that have a different hash if regularly parsed and =
re-serialized. An SPV client could be confused by such a transaction as =
it was present in the merkle tree proof with a different hash than it =
gets for the tx with its own serialization or from the raw =
message.</div><br><div apple-content-edited=3D"true">
<div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Tamas =
Blummer</div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;">Bits of Proof</div><div style=3D"color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;"><br></div></div></body></html>=

--Apple-Mail=_EC593710-1FB9-4AAB-92F0-A44D0068DF52--

--Apple-Mail=_32EFF217-B018-44CF-A0E9-1DC7C742830C
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

iQEcBAEBCgAGBQJUzfL8AAoJEPZykcUXcTkcwTAH/1ZnaqjpmLGGtEim0vLPb9D8
b9COVLIoEJ7VKiLIQ8+sSTZcuo6W0k9BCoZbWdZi/NN3Yag2QSzD1AD6bvLhHAuL
F600XHuHkFtpl2k2a2zNfYuGM7zn71eChTwiJwld6jEjqsILZi1O7ZMgOWRbEJzm
3HS9tRPmX9pW4CbQZNw38+kKtpDc2WraN66HWz89oW5vRn4EKV6QLbRT4ggDyrvW
mLBXn2TV/JQ0qQfB97Q8hmxl6FgOtNrpjAIqcNt+7Pe8A3wshi3SiJYhTTa25vaq
RZTZpQKhyOxJy9zF1baLZOPywbSj3CyMouNoohtcBhGBjHIBKtote0I8RWrtA6M=
=EoXH
-----END PGP SIGNATURE-----

--Apple-Mail=_32EFF217-B018-44CF-A0E9-1DC7C742830C--