1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
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 <tamas@bitsofproof.com>) 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 <tamas@bitsofproof.com>
In-Reply-To: <alpine.DEB.2.10.1502011133510.21504@nzrgulfg.ivfhpber.pbz>
Date: Sun, 1 Feb 2015 12:42:05 +0100
Message-Id: <B2C9D852-1C58-4F33-B17E-2E6A377E3B70@bitsofproof.com>
References: <D89EBAA3-ED78-4D9C-B693-FBBF27501938@bitsofproof.com>
<alpine.DEB.2.10.1502011133510.21504@nzrgulfg.ivfhpber.pbz>
To: Wladimir <laanwj@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <laanwj@gmail.com> 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
<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>Thanks for the clarification. Yes, I referred =
to CompactSize using the lingo of <a =
href=3D"https://en.bitcoin.it/wiki/Protocol_documentation">https://en.bitc=
oin.it/wiki/Protocol_documentation</a></div><div><br></div><div>I am not =
sure if it is current concern. Apparently an exception is thrown if =
non-canonical CompactSize in a transaction s parsed.</div><div>Is it =
ensured that transactions are always parsed before computing their =
hash?</div><div><br></div><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;"><br></div></div><div><div>On Feb 1, 2015, at 11:44 AM, Wladimir =
<<a href=3D"mailto:laanwj@gmail.com">laanwj@gmail.com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><br>On Sun, 1 Feb 2015, Tamas Blummer =
wrote:<br><br><blockquote type=3D"cite">I wonder of consequences if =
var_int is used in its longer than necessary forms (e.g encoding 1 as =
0xfd0100 instead of 0x01)<br></blockquote><br>In serialize.h lingo you =
are talking about CompactSize, not VarInt.<br><br>CompactSizes indeed =
have redundancy in their representation, i.e. the same number can be =
represented as up to four different byte sequences.<br><br>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.<br><br><blockquote type=3D"cite">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<br>merkle tree.<br></blockquote><br>Are you sure that this is a =
current concern? Non-canonical CompactSizes are forbidden - in =
serialize.h this is flagged in =
ReadCompactSize.<br><br>Wladimir<br><br><br></blockquote></div><br></body>=
</html>=
--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--
|
