Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YHsuu-000098-Sp for bitcoin-development@lists.sourceforge.net; Sun, 01 Feb 2015 11:42:16 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YHsut-0007We-4N for bitcoin-development@lists.sourceforge.net; Sun, 01 Feb 2015 11:42:16 +0000 Received: from [37.143.74.116] (helo=[192.168.0.100]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1YHsum-000463-Fm; Sun, 01 Feb 2015 12:42:08 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_EE60C463-12DC-4352-B47E-E8A1FD965FF1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tamas Blummer In-Reply-To: Date: Sun, 1 Feb 2015 12:42:05 +0100 Message-Id: References: To: Wladimir X-Mailer: Apple Mail (2.1878.6) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1422790935; c2886a59; X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.237.132.66 listed in list.dnswl.org] 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YHsut-0007We-4N Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] var_int ambiguous serialization consequences X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 11:42:16 -0000 --Apple-Mail=_EE60C463-12DC-4352-B47E-E8A1FD965FF1 Content-Type: multipart/alternative; boundary="Apple-Mail=_07784863-C922-4F18-9704-FD10DFB8BE5D" --Apple-Mail=_07784863-C922-4F18-9704-FD10DFB8BE5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the clarification. Yes, I referred to CompactSize using the = lingo of https://en.bitcoin.it/wiki/Protocol_documentation I am not sure if it is current concern. Apparently an exception is = thrown if non-canonical CompactSize in a transaction s parsed. Is it ensured that transactions are always parsed before computing their = hash? Tamas Blummer On Feb 1, 2015, at 11:44 AM, Wladimir wrote: >=20 > On Sun, 1 Feb 2015, Tamas Blummer wrote: >=20 >> I wonder of consequences if var_int is used in its longer than = necessary forms (e.g encoding 1 as 0xfd0100 instead of 0x01) >=20 > In serialize.h lingo you are talking about CompactSize, not VarInt. >=20 > CompactSizes indeed have redundancy in their representation, i.e. the = same number can be represented as up to four different byte sequences. >=20 > VARINTs have a different format that (AFAIK) isn't used anywhere in = the block chain. See WriteVarInt / ReadVarInt. These were designed to = not have any redundancy in their representation. >=20 >> 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. >=20 > Are you sure that this is a current concern? Non-canonical = CompactSizes are forbidden - in serialize.h this is flagged in = ReadCompactSize. >=20 > Wladimir >=20 >=20 --Apple-Mail=_07784863-C922-4F18-9704-FD10DFB8BE5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Thanks for the clarification. Yes, I referred = to CompactSize using the lingo of https://en.bitc= oin.it/wiki/Protocol_documentation

I am not = sure if it is current concern. Apparently an exception is thrown if = non-canonical CompactSize in a transaction s parsed.
Is it = ensured that transactions are always parsed before computing their = hash?

Tamas = Blummer

On Feb 1, 2015, at 11:44 AM, Wladimir = <laanwj@gmail.com> = wrote:


On Sun, 1 Feb 2015, Tamas Blummer = wrote:

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

In serialize.h lingo you = are talking about CompactSize, not VarInt.

CompactSizes indeed = have redundancy in their representation, i.e. the same number can be = represented as up to four different byte sequences.

VARINTs have = a different format that (AFAIK) isn't used anywhere in the block chain. = See WriteVarInt / ReadVarInt. These were designed to not have any = redundancy in their representation.

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.

Are you sure that this is a = current concern? Non-canonical CompactSizes are forbidden - in = serialize.h this is flagged in = ReadCompactSize.

Wladimir



= = --Apple-Mail=_07784863-C922-4F18-9704-FD10DFB8BE5D-- --Apple-Mail=_EE60C463-12DC-4352-B47E-E8A1FD965FF1 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 iQEcBAEBCgAGBQJUzhENAAoJEPZykcUXcTkcfE8H/2Kc/beKqA4o+Kh3huYz27nt MA9fQCCVSycc1c/3Ph7/SwRQDndG/o/ws9r/Gn+jrh675SiFjOkbOG3So8Gob/Qz wjS4mkSgZIRYGWzoYsAElZW2xzM5SvqaO7CqGspZympJL8y/QuBvZgF9Mla1fYLf CTZ6xgQupVgUwNecRNG7mhBc3X+D6zAWNWQFM4Q4Kb1GQXacDw/Agon5Ib4baWZ+ 8SjyDjMKAZ9W8R7+hiAxj1cV0CmhK1Gz3f82fmFgym72nzyEULJqFswyrdIV8yZv Cc3ODN6g76Ly2/FdbuRRtH1W3+HWQsud6eBp9S+X9OCz+816s11vMqZ4NCTlz+8= =SU3B -----END PGP SIGNATURE----- --Apple-Mail=_EE60C463-12DC-4352-B47E-E8A1FD965FF1--