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
|
Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 75BE340A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Dec 2016 20:37:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wj0-f175.google.com (mail-wj0-f175.google.com
[209.85.210.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5EF47137
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Dec 2016 20:37:41 +0000 (UTC)
Received: by mail-wj0-f175.google.com with SMTP id qp4so274363051wjc.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 04 Dec 2016 12:37:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=4IfEH0vO/bMoNztE1v/WnAV05smvCuDU4ao9KKtMMXU=;
b=qlSthnS3z23wlJzTtd0kXzj5JUj/Nz5jvToA2k2YNKmXWtZF4/n5aWp7cedOYbh64A
bmxaAKWtrV+wCm1HKnt9xgOiZJWS7U5TIR6ssJBmoCaKzQp50XjdBur/PyL6pPkFLEqE
U5Qi53I251gpprH1IqRYz6HVoZaIYvM8sbX4FCfos5YvlW7izy6o6YUkdgdZD6jvKOuN
cd3iHbKE5/vrPvXk4oAPhlnLpgFIGYgF1RRSY+CnBz0+/2bQcf4BxR1jAHoJzSZEphPU
9rWqXYeo4uCKg0VgTZqzZ0QmO0ZPYInvzjQQdjGh4hj56vUiEfAeBsn/wizJcswYg5KX
FOHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=4IfEH0vO/bMoNztE1v/WnAV05smvCuDU4ao9KKtMMXU=;
b=dwKLZMhnHwHLg5VFZyqW3pnvx+JT8ig8e+KoG02niKcl8Le3Q9oAF/eBAXiiHdyQd6
9OWhoaz+tnMjLLoS+t0IUNNqztxRUPvpchjMV4EiYjbRKF8SbytAjNS/eINVJiOIVbxG
m4niJecsU8Q484al6gw+JKXJSS8+DRfagAjX9boPZ+cPjyeP31ldOA36R4yWcjY5aO9K
2yyUM0eOZ+RVymPQHvtzKuNFsQ4g6fNNtrk9iXMESEqU7FyijXonAJzMlvkvZZW/qbCU
iVAYt4Csp3968hKvx9vP2txG5ZdBw4SO6pPFbHvHec/ZSyjmWUXHPS5bMZkzF0rqDADq
qM+Q==
X-Gm-Message-State: AKaTC00NFpC7YYImG0+jpuXNGHzIBs+vhEjC9xirnQROwwgO05zJWFmyKIFU8fhP+y+ILUPw/qBlcwOLlWlprg==
X-Received: by 10.194.39.7 with SMTP id l7mr46656156wjk.182.1480883859931;
Sun, 04 Dec 2016 12:37:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.63.66 with HTTP; Sun, 4 Dec 2016 12:37:39 -0800 (PST)
In-Reply-To: <CAKEeUhjYPL+kO6RCc8UDZWeAEmFuX1NRfkv22uqR4K+FiGosDA@mail.gmail.com>
References: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
<CAKEeUhjYPL+kO6RCc8UDZWeAEmFuX1NRfkv22uqR4K+FiGosDA@mail.gmail.com>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Sun, 4 Dec 2016 21:37:39 +0100
Message-ID: <CAFMkqK-4jATqTsbFmS5GDPHhXW8X+6m+dBvc3nqknmea-fz_YA@mail.gmail.com>
To: adiabat <rx@awsomnet.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=047d7b6251a06cc6910542db24f8
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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
X-Mailman-Approved-At: Sun, 04 Dec 2016 20:42:57 +0000
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: Sun, 04 Dec 2016 20:37:42 -0000
--047d7b6251a06cc6910542db24f8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> Also how about making timestamp 8 bytes? 2106 is coming up soon :)
AFAICT this was fixed in this commit:
https://github.com/jl2012/bitcoin/commit/fa80b48bb4237b110ceffe11edc14c8130=
672cd2#diff-499d7ee7998a27095063ed7b4dd7c119R200
2016-12-04 21:00 GMT+01:00 adiabat via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> Interesting stuff! I have some comments, mostly about the header.
>
> The header of forcenet is mostly described in Luke=E2=80=99s BIP, but I h=
ave made
>> some amendments as I implemented it. The format is (size in parentheses;
>> little endian):
>>
>> 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)
>>
>
> First, I'd really rather not have variable length fields in the header.
> It's so much nicer to just have a fixed size.
>
> 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 s=
ee
> 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 wil=
l
> have to download and store and extra 32 bytes per block, likely offsettin=
g
> any savings from omitting witness data.
>
> 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?)
>
> 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 t=
he
> header, which is 1 byte.
>
> Also how about making timestamp 8 bytes? 2106 is coming up soon :)
>
> Maybe this is too nit-picky; maybe it's better to put lots of stuff in fo=
r
> testing the forcenet and then take out all the stuff that wasn't used or
> had issues as it progresses.
>
> Thanks and looking forward to trying out forcenet!
>
> -Tadge
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--047d7b6251a06cc6910542db24f8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> Also how about making timestamp 8 bytes? =C2=A02106 i=
s coming up soon :)<br><div><br></div><div>AFAICT this was fixed in this co=
mmit: <a href=3D"https://github.com/jl2012/bitcoin/commit/fa80b48bb4237b110=
ceffe11edc14c8130672cd2#diff-499d7ee7998a27095063ed7b4dd7c119R200">https://=
github.com/jl2012/bitcoin/commit/fa80b48bb4237b110ceffe11edc14c8130672cd2#d=
iff-499d7ee7998a27095063ed7b4dd7c119R200</a><br></div><div><br></div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-12-04 21:00 =
GMT+01:00 adiabat via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a>></span>:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Interesting stuff! I have some comments, mostly about the header=
.<div><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span=
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
The header of forcenet is mostly described in Luke=E2=80=99s BIP, but I hav=
e made some amendments as I implemented it. The format is (size in parenthe=
ses; little endian):<br>
<br>
Height (4), BIP9 signalling field (4), hardfork signalling field (3), merge=
-mining hard fork signalling field (1), prev hash (32), timestamp (4), nonc=
e1 (4), nonce2 (4), nonce3 (compactSize + variable), Hash TMR (32), Hash WM=
R (32), total tx size (8) , total tx weight (8), total sigops (8), number o=
f tx (4), merkle branches leading to header C (compactSize + 32 bit hashes)=
<br></blockquote><div><br></div></span><div>First, I'd really rather no=
t have variable length fields in the header.=C2=A0 It's so much nicer t=
o just have a fixed size.</div><div><br></div><div>Is having both TMR and W=
MR really needed?=C2=A0 As segwit would be required with this header type, =
and the WMR covers a superset of the data that the TMR does, couldn't y=
ou get rid of the TMR?=C2=A0 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.=C2=A0 This seems pretty minor, especia=
lly as once they're convinced of block inclusion they can discard the w=
itness data, and also the tradeoff is that light clients will have to downl=
oad and store and extra 32 bytes per block, likely offsetting any savings f=
rom omitting witness data.</div><div><br></div><div>The other question is t=
hat 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 nl=
ocktime instead?)</div><div><br></div><div>Total size / weight / number of =
txs also feels pretty redundant.=C2=A0 Not a lot of space but it's hard=
to come up with a use for them.=C2=A0 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><br></div><div>Also how about making timestamp 8 bytes? =C2=A021=
06 is coming up soon :)</div><div><br></div><div>Maybe this is too nit-pick=
y; maybe it's better to put lots of stuff in for testing the forcenet a=
nd then take out all the stuff that wasn't used or had issues as it pro=
gresses.</div><div><br>Thanks and looking forward to trying out forcenet!</=
div><div><br></div><div>-Tadge</div></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--047d7b6251a06cc6910542db24f8--
|
