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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 090FEFA7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 13:18:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com
[209.85.213.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3888E10C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 13:18:53 +0000 (UTC)
Received: by mail-ig0-f174.google.com with SMTP id xg9so40759248igb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 07 Feb 2016 05:18:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=r3G9PqZ28cLodwjCpxIvMyqbkfvN285WEbIG8uvSR/4=;
b=v7LK74MyRYcY5X9fUVosHrZubprCmqqLKrRlewS5q24K9um/Af4CrcGtWre7DNh3J+
1+ecvL9jnbhX52Pr0LnIbLyCRIwL4jtRP2zYELpi7V1zVd/1zGR48fKVGxWEjzHJalUP
RHO5Ds+7HVUZfKJahVoxmctaFPZ3NOceZ5nZuS1i8RezwmxHf1p3pdNp741PtbcCsyo3
fuZY0hYb8/ER/ZVYtuuflHefAfQn0UL/Hdj6km3dDGE/8bYw3Yieauv7dEK5criEEAgI
VYwPctE1iEx0DGifKJGS5nVoxRcH/mSh/NkyLal05DMckWsCZO5zkaFIL4dpvIGC3pOk
+isQ==
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:date
:message-id:subject:from:cc:content-type;
bh=r3G9PqZ28cLodwjCpxIvMyqbkfvN285WEbIG8uvSR/4=;
b=IK4VmWGPrsQOydbsDZHYA9+jVRnEM51f1GOKezM8HIfFYBH6t4JSvty5F2BaieXBuM
ZFzCae8LKC+kGvKfqBWE9+2wRz5h9uX7lbYDX+23QYgKkIkbqroL5iFrs8xxyxZrJQrR
eIYUaPX5dizVZMqJVdqFutE3gapU0XiqRzu2lpkP0pscV3A56g6j1fzJYBUBgqGmfUT4
hWmuDLoJ/4RPuuC+eBpp4/5clTnsS7Nn9LqjMJlrPlNDzsRQUtXarVdt+v0qVkK4LEQi
Tl84+v7x1hc0bJoCmhZkMzogyVh1XOQutH13k8YM57Mw/aCT4TMwxt1rhfP/WSGKSWol
pJxw==
X-Gm-Message-State: AG10YOTvXTmLuHhVIXP1fHm1+vA4mrOd+stcNLQJ+I33pPzpwFPBHFa9IpjIfiPdOZwIq0eJECu4RM5fGxZNAg==
MIME-Version: 1.0
X-Received: by 10.50.2.39 with SMTP id 7mr18914825igr.96.1454851132690; Sun,
07 Feb 2016 05:18:52 -0800 (PST)
Received: by 10.79.77.65 with HTTP; Sun, 7 Feb 2016 05:18:52 -0800 (PST)
In-Reply-To: <201602070952.33457.luke@dashjr.org>
References: <201602070952.33457.luke@dashjr.org>
Date: Sun, 7 Feb 2016 13:18:52 +0000
Message-ID: <CAE-z3OUPwBtpYRQL3CaANMQS88=cw_XLj0tAzyThpZxn0f8yhA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=e89a8f642bd8f7172c052b2deca6
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
MALFORMED_FREEMAIL, MISSING_HEADERS, RCVD_IN_DNSWL_LOW,
T_REMOTE_IMAGE autolearn=no version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Pre-BIP Growth Soft-hardfork
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 07 Feb 2016 13:18:54 -0000
--e89a8f642bd8f7172c052b2deca6
Content-Type: text/plain; charset=UTF-8
This is a specific implementation of the "nuclear option" soft fork (or
"firm-fork").
The problem with any hard-fork (like) change is that there is an incentive
to add as much as possible and then the process gets bogged down.
Since the POW is based on the header 1, you could make header 3
expandable. This would allow adding new fields later.
This could be used for other block commitments. This would save having to
make the merkle tree a sum tree immediately. At a later time, the sum-tree
root could be added. (I think you also need to commit the path to the first
entry in the sum-tree, in order to get compact proofs). There could be
separate sum-trees for each counter (sigops, block size, tx count, sighash?)
Having a dedicated hard fork and soft fork counter is a good idea. There
should also be a field for parallel soft forks. Incrementing the soft fork
counter could set the bitfield soft forks back to zero. Ideally, each soft
fork would have a yes and no bit. If > 50% vote No, then it fails adoption.
The effect of this change is that nodes react to hard forks by stalling the
chain. The hard fork counter means that the new rules could be that nodes
should do that going forward for all new hard forks.
- soft fork (bitfield or count) => warn user that a soft fork has happened
- hard fork count increase => warn user that update is required and don't
process any more blocks
This means that header3 should be kept as simple as possible.
- 2 bytes: hardfork block version
- 2 bytes: softfork block version
- 4 bytes: softfork bitfields
- 32 byte: hash(header4)
Header4 and everything else in the block could be changed when a hard fork
happens. The merged mining rules and header3 would be fixed.
I think confirmation counts should be based on even numbers, i.e. 3800 of
4000, but that is an aesthetic issue and doesn't really matter.
A section on recommendations for the different client types would be useful.
If 1000 of the last 2000 blocks are votes for a hard fork, then warn the
user that a hard fork is being considered
If 4000 of the last 4463 blocks are votes for a hard fork, then warn the
user that a hard fork is likely to occur within the next few days
If a hard fork happens:
- shut down transaction processing
- inform the user that a hard fork has happened
Non-upgraded miners could blacklist the hard forking block and keep mining
on their own chain. Their chain would never reach the threshold to trigger
the hard fork. It would max out at 4323 blocks of the last 4463.
Ironically, if users did this, it would defeat some of the benefit of using
the hard fork field.
Users should definitely be given the option of accepting or rejecting the
hard fork. Otherwise, miners can hard-fork at will, which isn't desirable.
<https://www.avast.com/sig-email> This email has been sent from a
virus-free computer protected by Avast.
www.avast.com <https://www.avast.com/sig-email>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--e89a8f642bd8f7172c052b2deca6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This is a specific implementation of the "nuclea=
r option" soft fork (or "firm-fork").<br><br></div><div>The =
problem with any hard-fork (like) change is that there is an incentive to a=
dd as much as possible and then the process gets bogged down.<br><br></div>=
<div>Since the POW is based on the header 1, you could make header 3 expand=
able.=C2=A0 This would allow adding new fields later.<br><br></div><div>Thi=
s could be used for other block commitments.=C2=A0 This would save having t=
o make the merkle tree a sum tree immediately.=C2=A0 At a later time, the s=
um-tree root could be added. (I think you also need to commit the path to t=
he first entry in the sum-tree, in order to get compact proofs).=C2=A0 Ther=
e could be separate sum-trees for each counter (sigops, block size, tx coun=
t, sighash?)<br><br></div><div>Having a dedicated hard fork and soft fork c=
ounter is a good idea.=C2=A0 There should also be a field for parallel soft=
forks.=C2=A0 Incrementing the soft fork counter could set the bitfield sof=
t forks back to zero.=C2=A0 Ideally, each soft fork would have a yes and no=
bit.=C2=A0 If > 50% vote No, then it fails adoption.<br><br></div><div>=
The effect of this change is that nodes react to hard forks by stalling the=
chain.=C2=A0 The hard fork counter means that the new rules could be that =
nodes should do that going forward for all new hard forks.<br></div><div><b=
r></div><div>- soft fork (bitfield or count) =3D> warn user that a soft =
fork has happened<br></div><div>- hard fork count increase =3D> warn use=
r that update is required and don't process any more blocks<br><br></di=
v><div>This means that header3 should be kept as simple as possible.<br><ul=
><li>2 bytes: hardfork block version</li><li>2 bytes: softfork block versio=
n</li><li>4 bytes: softfork bitfields</li><li>32 byte: hash(header4)</li></=
ul>Header4 and everything else in the block could be changed when a hard fo=
rk happens.=C2=A0 The merged mining rules and header3 would be fixed.<br><b=
r></div><div>I think confirmation counts should be based on even numbers, i=
.e. 3800 of 4000, but that is an aesthetic issue and doesn't really mat=
ter.<br><br></div><div>A section on recommendations for the different clien=
t types would be useful.<br><br></div><div></div><div>If 1000 of the last 2=
000 blocks are votes for a hard fork, then warn the user that a hard fork i=
s being considered<br><br></div><div>If 4000 of the last 4463 blocks are vo=
tes for a hard fork, then warn the user that a hard fork is likely to occur=
within the next few days<br><br></div><div>If a hard fork happens:<br><br>=
</div><div>- shut down transaction processing<br>- inform the user that a h=
ard fork has happened<br></div><div><br></div><div>Non-upgraded miners coul=
d blacklist the hard forking block and keep mining on their own chain.=C2=
=A0 Their chain would never reach the threshold to trigger the hard fork.=
=C2=A0 It would max out at 4323 blocks of the last 4463.<br><br></div><div>=
Ironically, if users did this, it would defeat some of the benefit of using=
the hard fork field.<br><br></div><div>Users should definitely be given th=
e option of accepting or rejecting the hard fork.=C2=A0 Otherwise, miners c=
an hard-fork at will, which isn't desirable.<br></div></div><div id=3D"=
DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><table style=3D"border-top:1px solid =
#aaabb6;margin-top:30px">
<tr>
<td style=3D"width:105px;padding-top:15px">
<a href=3D"https://www.avast.com/sig-email" target=3D"_blank"><img src=
=3D"https://ipmcdn.avast.com/images/logo-avast-v1.png" style=3D"width: 90px=
; height:33px;"></a>
</td>
<td style=3D"width:470px;padding-top:20px;color:#41424e;font-size:13px;fo=
nt-family:Arial,Helvetica,sans-serif;line-height:18px">This email has been =
sent from a virus-free computer protected by Avast. <br><a href=3D"https://=
www.avast.com/sig-email" target=3D"_blank" style=3D"color:#4453ea">www.avas=
t.com</a>
</td>
</tr>
</table><a href=3D"#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width=3D"1" heigh=
t=3D"1"></a></div>
--e89a8f642bd8f7172c052b2deca6--
|
