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
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 98E82B2E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Dec 2016 11:11:38 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender163-mail.zoho.com (sender163-mail.zoho.com
[74.201.84.163])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6FA4A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Dec 2016 11:11:37 +0000 (UTC)
Received: from [172.21.35.100] (223.197.116.5 [223.197.116.5]) by
mx.zohomail.com with SMTPS id 1481713892676531.0325125978444;
Wed, 14 Dec 2016 03:11:32 -0800 (PST)
Content-Type: multipart/alternative;
boundary="Apple-Mail=_D91A8230-8DF0-4EC7-AD6F-DF12D9A4229B"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <CAKEeUhjYPL+kO6RCc8UDZWeAEmFuX1NRfkv22uqR4K+FiGosDA@mail.gmail.com>
Date: Wed, 14 Dec 2016 19:11:29 +0800
Message-Id: <08ED1F61-BB96-43B8-9474-CD52913F6B34@xbt.hk>
References: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
<CAKEeUhjYPL+kO6RCc8UDZWeAEmFuX1NRfkv22uqR4K+FiGosDA@mail.gmail.com>
To: adiabat <rx@awsomnet.org>
X-Mailer: Apple Mail (2.3124)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new
header format
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2016 11:11:38 -0000
--Apple-Mail=_D91A8230-8DF0-4EC7-AD6F-DF12D9A4229B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On 5 Dec 2016, at 04:00, adiabat <rx@awsomnet.org> wrote:
>=20
> Interesting stuff! I have some comments, mostly about the header.
>=20
> The header of forcenet is mostly described in Luke=E2=80=99s BIP, but =
I have made some amendments as I implemented it. The format is (size in =
parentheses; little endian):
>=20
> Height (4), BIP9 signalling field (4), hardfork signalling field (3), =
merge-mining hard fork signalling field (1), prev hash (32), timestamp =
(4), nonce1 (4), nonce2 (4), nonce3 (compactSize + variable), Hash TMR =
(32), Hash WMR (32), total tx size (8) , total tx weight (8), total =
sigops (8), number of tx (4), merkle branches leading to header C =
(compactSize + 32 bit hashes)
>=20
> First, I'd really rather not have variable length fields in the =
header. It's so much nicer to just have a fixed size.
>=20
> Is having both TMR and WMR really needed? As segwit would be required =
with this header type, and the WMR covers a superset of the data that =
the TMR does, couldn't you get rid of the TMR? The only disadvantage I =
can see is that light clients may want a merkle proof of a transaction =
without having to download the witnesses for that transaction. This =
seems pretty minor, especially as once they're convinced of block =
inclusion they can discard the witness data, and also the tradeoff is =
that light clients will have to download and store and extra 32 bytes =
per block, likely offsetting any savings from omitting witness data.
>=20
I foresee there will be 2 types of headers under this system: the 80 =
bytes short header and the variable length full header. Short headers =
are enough to link everything up. SPV needs the full header only if they =
are interested in any tx in a block.=20
> The other question is that there's a bit that's redundant: height is =
also committed to in the coinbase tx via bip 34 (speaking of which, if =
there's a hard-fork, how about reverting bip 34 and committing to the =
height with coinbase tx nlocktime instead?)
you could omit the transmission of nHeight, as it is implied (saving =
4bytes). Storing nHeight of headers is what every full and SPV nodes =
would do anyway
>=20
> Total size / weight / number of txs also feels pretty redundant. Not =
a lot of space but it's hard to come up with a use for them. Number of =
tx could be useful if you want to send all the leaves of a merkle tree, =
but you could also do that by committing to the depth of the merkle tree =
in the header, which is 1 byte.
Yes, I agree with you that these are not particularly useful. Sum tree =
is more useful but it has other problems (see my other reply)
Related discussion: =
https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541ee=
7a17208 =
<https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe1c2541e=
e7a17208>
>=20
> Also how about making timestamp 8 bytes? 2106 is coming up soon :)
No need. See my other reply
>=20
> Maybe this is too nit-picky; maybe it's better to put lots of stuff in =
for testing the forcenet and then take out all the stuff that wasn't =
used or had issues as it progresses.
>=20
> Thanks and looking forward to trying out forcenet!
>=20
> -Tadge
--Apple-Mail=_D91A8230-8DF0-4EC7-AD6F-DF12D9A4229B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 5 Dec 2016, at 04:00, adiabat <<a =
href=3D"mailto:rx@awsomnet.org" class=3D"">rx@awsomnet.org</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D"">Interesting stuff! I have some comments, mostly =
about the header.<div class=3D""><br class=3D""></div><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
The header of forcenet is mostly described in Luke=E2=80=99s BIP, but I =
have made some amendments as I implemented it. The format is (size in =
parentheses; little endian):<br class=3D"">
<br class=3D"">
Height (4), BIP9 signalling field (4), hardfork signalling field (3), =
merge-mining hard fork signalling field (1), prev hash (32), timestamp =
(4), nonce1 (4), nonce2 (4), nonce3 (compactSize + variable), Hash TMR =
(32), Hash WMR (32), total tx size (8) , total tx weight (8), total =
sigops (8), number of tx (4), merkle branches leading to header C =
(compactSize + 32 bit hashes)<br class=3D""></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">First, I'd really rather =
not have variable length fields in the header. It's so much nicer =
to just have a fixed size.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Is having both TMR and WMR really needed? As segwit =
would be required with this header type, and the WMR covers a superset =
of the data that the TMR does, couldn't you get rid of the TMR? =
The only disadvantage I can see is that light clients may want a merkle =
proof of a transaction without having to download the witnesses for that =
transaction. This seems pretty minor, especially as once they're =
convinced of block inclusion they can discard the witness data, and also =
the tradeoff is that light clients will have to download and store and =
extra 32 bytes per block, likely offsetting any savings from omitting =
witness data.</div><div class=3D""><br =
class=3D""></div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>I foresee there will be 2 types of headers under =
this system: the 80 bytes short header and the variable length full =
header. Short headers are enough to link everything up. SPV needs the =
full header only if they are interested in any tx in a =
block. </div><br class=3D""><blockquote type=3D"cite" class=3D""><div=
class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div class=3D"">The other question is that there's =
a bit that's redundant: height is also committed to in the coinbase tx =
via bip 34 (speaking of which, if there's a hard-fork, how about =
reverting bip 34 and committing to the height with coinbase tx nlocktime =
instead?)</div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>you could omit the transmission of nHeight, as it =
is implied (saving 4bytes). Storing nHeight of headers is what every =
full and SPV nodes would do anyway</div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div class=3D""><br class=3D""></div><div =
class=3D"">Total size / weight / number of txs also feels pretty =
redundant. Not a lot of space but it's hard to come up with a use =
for them. Number of tx could be useful if you want to send all the =
leaves of a merkle tree, but you could also do that by committing to the =
depth of the merkle tree in the header, which is 1 =
byte.</div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>Yes, I agree with you that these are not =
particularly useful. Sum tree is more useful but it has other problems =
(see my other reply)</div><div><br class=3D""></div><div>Related =
discussion: <a =
href=3D"https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd2576fe=
1c2541ee7a17208" =
class=3D"">https://github.com/jl2012/bitcoin/commit/69e613bfb0f777c8dcd257=
6fe1c2541ee7a17208</a></div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""><br =
class=3D""></div><div class=3D"">Also how about making timestamp 8 =
bytes? 2106 is coming up soon =
:)</div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>No need. See my other reply</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div class=3D""><br class=3D""></div><div =
class=3D"">Maybe this is too nit-picky; maybe it's better to put lots of =
stuff in for testing the forcenet and then take out all the stuff that =
wasn't used or had issues as it progresses.</div><div class=3D""><br =
class=3D"">Thanks and looking forward to trying out forcenet!</div><div =
class=3D""><br class=3D""></div><div =
class=3D"">-Tadge</div></div></div></div>
</div></blockquote></div><br class=3D""></body></html>=
--Apple-Mail=_D91A8230-8DF0-4EC7-AD6F-DF12D9A4229B--
|
