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
|
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 F3A826C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Dec 2016 19:34:20 +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 237DE110
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Dec 2016 19:34:19 +0000 (UTC)
Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by
mx.zohomail.com with SMTPS id 1480880056996978.1575091748343;
Sun, 4 Dec 2016 11:34:16 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/signed;
boundary="Apple-Mail=_020F4661-DC48-46FC-9F9A-4186FDF2118C";
protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
Date: Mon, 5 Dec 2016 03:34:00 +0800
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Zoho-Virus-Status: 1
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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
Subject: [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 19:34:21 -0000
--Apple-Mail=_020F4661-DC48-46FC-9F9A-4186FDF2118C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Based on Luke Dashjr=E2=80=99s code and BIP: =
https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki , I =
created an experimental network to show how a new header format may be =
implemented.
Basically, the header hash is calculated in a way that non-upgrading =
nodes would see it as a block with only the coinbase tx and zero output =
value. They are effectively broken as they won=E2=80=99t see any =
transactions confirmed. This allows rewriting most of the rules related =
to block and transaction validity. Such technique has different names =
like soft-hardfork, firmfork, evil softfork, and could be itself a =
controversial topic. However, I=E2=80=99d rather not to focus on its =
soft-hardfork property, as that would be trivial to turn this into a =
true hardfork (e.g. setting the sign bit in block nVersion, or setting =
the most significant bit in the dummy coinbase nLockTime)
Instead of its soft-HF property, I think the more interesting thing is =
the new header format. The current bitcoin header has only 80 bytes. It =
provides only 32bits of nonce space and is far not enough for ASICs. It =
also provides no room for committing to additional data. Therefore, =
people are forced to put many different data in the coinbase =
transaction, such as merge-mining commitments, and the segwit =
commitment. It is not a ideal solution, especially for light wallets.
Following the practice of segwit development of making a experimental =
network (segnet), I made something similar and call it the Forcenet (as =
it forces legacy nodes to follow the post-fork chain)
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):
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)
In addition to increasing the max block size, I also showed how the =
calculation and validation of witness commitment may be changed with a =
new header. For example, since the commitment is no longer in the =
coinbase tx, we don=E2=80=99t need to use a 0000=E2=80=A6.0000 hash for =
the coinbase tx like in BIP141.
Something not yet done:
1. The new merkle root algorithm described in the MMHF BIP
2. The nTxsSigops has no meaning currently
3. Communication with legacy nodes. This version can=E2=80=99t talk to =
legacy nodes through the P2P network, but theoretically they could be =
linked up with a bridge node
4. A new block weight definition to provide incentives for slowing down =
UTXO growth
5. Many other interesting hardfork ideas, and softfork ideas that works =
better with a header redesign
For easier testing, forcenet has the following parameters:
Hardfork at block 200
Segwit is always activated
1 minutes block with 40000 (prefork) and 80000 (postfork) weight limit
50 blocks coinbase maturity
21000 blocks halving
144 blocks retarget
How to join: codes at https://github.com/jl2012/bitcoin/tree/forcenet1 , =
start with "bitcoind =E2=80=94forcenet" .
Connection: I=E2=80=99m running a node at 8333.info with default port =
(38901)
Mining: there is only basic internal mining support. Limited GBT support =
is theoretically possible but needs more hacking. To use the internal =
miner, writeup a shell script to repeatedly call =E2=80=9Cbitcoin-cli =
=E2=80=94forcenet generate 1=E2=80=9D
New RPC commands: getlegacyblock and getlegacyblockheader, which =
generates blocks and headers that are compatible with legacy nodes.
This is largely work-in-progress so expect a reset every couple weeks
jl2012
--Apple-Mail=_020F4661-DC48-46FC-9F9A-4186FDF2118C
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
iQGcBAEBCgAGBQJYRG+0AAoJEO6eVSA0viTSpIIL/jDnSLXB7SKTiTtvHT7lCAUe
NUflWl1yC9UX/rcfaa0ffjlE72EvVvzTub20VmxgqLdS6YlddGLRJ0V5wINtpkhl
8Bu3G+Xu8owsygJqQpl0zRR/I+ZBNho+h5c8w+qR5GgQ+GPFrOgUegoSNZPh+XSp
/F+XT7CmKSOPf06P1/XbF7k7o1dEyaYIRExQ1pz6ZNiJB+uZatw3sxw5LVpSiNBu
vpg8IPSwYc7etGQCp2B/hQB1EouT7S2fpsfRSB+1Gom5VSyLAJWNvJl7aasluNSm
ZtaDGBsCBtm841vYfvE9vdJQIP71VK+ntNfJ2ZFDWCVNoHQTDixvE1RiElTdYYP/
G/6NuA2vmEjlpIVlrG9lWpgFPXOBuOeHcIwLcHk1xJ0+0OaZ8TToKp9npK38KprB
Dv9ZGa/U2LL4W3cTwtusxulOd/VXnBib9Vb7vmWcg6cQIShK1UIYo8wRi8VY4oBj
O3yXxcWsK9FTwIjLwPw38o7S11LhPLBqPuAY0JYUsg==
=b11z
-----END PGP SIGNATURE-----
--Apple-Mail=_020F4661-DC48-46FC-9F9A-4186FDF2118C--
|
