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
|
Return-Path: <rx@awsomnet.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3E5B89C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Dec 2016 20:00:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com
[209.85.223.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9B27B1B2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Dec 2016 20:00:01 +0000 (UTC)
Received: by mail-io0-f172.google.com with SMTP id j65so564898854iof.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 04 Dec 2016 12:00:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=awsomnet-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=vA9+TnjIBRWG0zsPLFAqam7q7VkybIRixHstL352R4A=;
b=BfPHdfHCn6Dry9Mtqhol3u8+KWlmaE68aGo/uk5LrBMYO+ZN0Y/cpVl4/eAkt4uMp4
z5LnEsjRErAvk4Ju/CGNSObou4Ahg+5cme8nkrFu3zcH0JzFEoteBgGtGtRezcBVh34H
GbmAycUFwn7aoiK3ygSl3ANGsu+LO1Cd4oNvncanrqWQTMI+Gp6RbF90NRsCek44OTGJ
N5s3JjFoab6044ecCtfHBAv1VW3+86kaG7MOI1d0IYPmG7WW9NFfuq2bXH8/t1ZsN4hL
0bfgngrtiMw5fORDU7FHNIHGHNgo+ICTmMMxL9L3fZPTGWue1ShUbkGXrYEpaSQGFM0x
zcBQ==
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=vA9+TnjIBRWG0zsPLFAqam7q7VkybIRixHstL352R4A=;
b=DTh01lLEdIdqw+dP4auRo4ua5z3XCCTb6iz4bYITfZtbNkRMhj1UmAKyuSV9D4E9Nd
KSsgFigJhaIVI0FgeKQR72rtfML4VmqDNMphSlHG5Cgv9o/xDgC2hhebdqSp9ZXgw/1J
sYqDt7yHQB24PXPli2v4wGPYW15g27iXnEBZjZrnVr1Ny8YGD3ImQkn2SESJQTEWhdNa
gVz8Y7As3V+qUVdvlKCbG8ehP/QRVyvYXrAJ76xugn1Ojulzmb1Dv8T0waZ0qPjkTcqs
idDKNZUpdE3IQNJGsfV0+mKY78/htuznXCYN4NkvqApBjXT2oHwetz1DbH5JaeBQY2Gy
9Lmg==
X-Gm-Message-State: AKaTC00WhJRkE08N9zmEihFPFte5NlpZv4hFYsuQ1zT6CH54W1/7fDh6mPlTxZFfiQzGnoqm660bULO6tMWgTA==
X-Received: by 10.36.139.4 with SMTP id g4mr5872182ite.35.1480881600840; Sun,
04 Dec 2016 12:00:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.236.70 with HTTP; Sun, 4 Dec 2016 12:00:00 -0800 (PST)
X-Originating-IP: [73.234.153.245]
In-Reply-To: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
References: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
From: adiabat <rx@awsomnet.org>
Date: Sun, 4 Dec 2016 15:00:00 -0500
Message-ID: <CAKEeUhjYPL+kO6RCc8UDZWeAEmFuX1NRfkv22uqR4K+FiGosDA@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c04abb8c5ddbf0542da9dd2
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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: Sun, 04 Dec 2016 20:00:02 -0000
--94eb2c04abb8c5ddbf0542da9dd2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 hav=
e 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 b=
it
> 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 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.
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 the
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 for
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
--94eb2c04abb8c5ddbf0542da9dd2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=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"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #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><div>First, I'd really rather not have =
variable length fields in the header.=C2=A0 It's so much nicer to just =
have a fixed size.</div><div><br></div><div>Is having both TMR and WMR real=
ly 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 you 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 wi=
tnesses for that transaction.=C2=A0 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 omi=
tting witness data.</div><div><br></div><div>The other question is that the=
re's a bit that's redundant: height is also committed to in the coi=
nbase tx via bip 34 (speaking of which, if there's a hard-fork, how abo=
ut reverting bip 34 and committing to the height with coinbase tx nlocktime=
instead?)</div><div><br></div><div>Total size / weight / number of txs als=
o feels pretty redundant.=C2=A0 Not a lot of space but it's hard to com=
e 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 commit=
ting 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=A02106 is c=
oming up soon :)</div><div><br></div><div>Maybe this is too nit-picky; mayb=
e 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><br>Thanks and looking forward to trying out forcenet!</div><di=
v><br></div><div>-Tadge</div></div></div></div>
--94eb2c04abb8c5ddbf0542da9dd2--
|
