summaryrefslogtreecommitdiff
path: root/70/c295cfdf6b8a7463fd6aceac1e23eef1972f7e
blob: 0dc68ae1aac7ab2e5555e0d367b9eee8fcf62886 (plain)
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
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 3A5EE89E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Mar 2017 17:34:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 567BD20C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Mar 2017 17:34:31 +0000 (UTC)
Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by
	mx.zohomail.com with SMTPS id 1490722468050254.526383525886;
	Tue, 28 Mar 2017 10:34:28 -0700 (PDT)
From: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_BC91FADA-184C-4066-A5A0-1AE5AFC34D10"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 29 Mar 2017 01:34:23 +0800
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
To: Wang Chun <1240902@gmail.com>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
Message-Id: <B93DE8AA-AA01-4E0E-88B6-B788B03282E0@xbt.hk>
X-Mailer: Apple Mail (2.3259)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
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: Tue, 28 Mar 2017 17:34:32 -0000


--Apple-Mail=_BC91FADA-184C-4066-A5A0-1AE5AFC34D10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

You are probably not the first one nor last one with such idea. =
Actually, Luke wrote up a BIP with similar idea in mind:

https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki =
<https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki>

Instead of just lifting the block size limit, he also suggested to =
remove many other rules. I think he has given up this idea because =
it=E2=80=99s just too complicated.

If we really want to prepare for a hardfork, we probably want to do more =
than simply increasing the size limit. For example, my spoonnet =
proposal:

=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/0135=
42.html =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013=
542.html>

In a HF, we may want to relocate the witness commitment to a better =
place. We may also want to fix Satoshi's sighash bug. These are much =
more than simple size increase.

So if we really want to get prepared for a potential HF with unknown =
parameters, I=E2=80=99d suggest to set a time bomb in the client, which =
will stop processing of transactions with big warning in GUI. The user =
may still have an option to continue with old rules at their own risks.

Or, instead of increasing the block size, we make a softfork to decrease =
the block size to 1kB and block reward to 0, activating far in the =
future. This is similar to the difficulty bomb in ETH, which will freeze =
the network.

> On 29 Mar 2017, at 00:59, Wang Chun via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> I've proposed this hard fork approach last year in Hong Kong Consensus
> but immediately rejected by coredevs at that meeting, after more than
> one year it seems that lots of people haven't heard of it. So I would
> post this here again for comment.
>=20
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>=20
> Despite spam tx on the network, the block capacity is approaching its
> limit, and we must think ahead. Shall we code a patch right now, to
> remove the block size limit of 1MB, but not activate it until far in
> the future. I would propose to remove the 1MB limit at the next block
> halving in spring 2020, only limit the block size to 32MiB which is
> the maximum size the current p2p protocol allows. This patch must be
> in the immediate next release of Bitcoin Core.
>=20
> With this patch in core's next release, Bitcoin works just as before,
> no fork will ever occur, until spring 2020. But everyone knows there
> will be a fork scheduled. Third party services, libraries, wallets and
> exchanges will have enough time to prepare for it over the next three
> years.
>=20
> We don't yet have an agreement on how to increase the block size
> limit. There have been many proposals over the past years, like
> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
> on. These hard fork proposals, with this patch already in Core's
> release, they all become soft fork. We'll have enough time to discuss
> all these proposals and decide which one to go. Take an example, if we
> choose to fork to only 2MB, since 32MiB already scheduled, reduce it
> from 32MiB to 2MB will be a soft fork.
>=20
> Anyway, we must code something right now, before it becomes too late.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_BC91FADA-184C-4066-A5A0-1AE5AFC34D10
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""><div class=3D"">You are probably not the first one nor last =
one with such idea. Actually, Luke wrote up a BIP with similar idea in =
mind:</div><div class=3D""><br class=3D""></div><div class=3D""><a =
href=3D"https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawi=
ki" =
class=3D"">https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.medi=
awiki</a></div><div class=3D""><br class=3D""></div><div =
class=3D"">Instead of just lifting the block size limit, he also =
suggested to remove many other rules. I think he has given up this idea =
because it=E2=80=99s just too complicated.</div><div class=3D""><br =
class=3D""></div><div class=3D"">If we really want to prepare for a =
hardfork, we probably want to do more than simply increasing the size =
limit. For example, my spoonnet proposal:</div><div class=3D""><br =
class=3D""></div><div class=3D""><a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Febru=
ary/013542.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Fe=
bruary/013542.html</a></div><div class=3D""><br class=3D""></div><div =
class=3D"">In a HF, we may want to relocate the witness commitment to a =
better place. We may also want to fix Satoshi's sighash bug. These are =
much more than simple size increase.</div><div class=3D""><br =
class=3D""></div><div class=3D"">So if we really want to get prepared =
for a potential HF with unknown parameters, I=E2=80=99d suggest to set a =
time bomb in the client, which will stop processing of transactions with =
big warning in GUI. The user may still have an option to continue with =
old rules at their own risks.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Or, instead of increasing the block =
size, we make a softfork to decrease the block size to 1kB and block =
reward to 0, activating far in the future. This is similar to the =
difficulty bomb in ETH, which will freeze the network.</div><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
29 Mar 2017, at 00:59, Wang Chun via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">I've =
proposed this hard fork approach last year in Hong Kong Consensus<br =
class=3D"">but immediately rejected by coredevs at that meeting, after =
more than<br class=3D"">one year it seems that lots of people haven't =
heard of it. So I would<br class=3D"">post this here again for =
comment.<br class=3D""><br class=3D"">The basic idea is, as many of us =
agree, hard fork is risky and should<br class=3D"">be well prepared. We =
need a long time to deploy it.<br class=3D""><br class=3D"">Despite spam =
tx on the network, the block capacity is approaching its<br =
class=3D"">limit, and we must think ahead. Shall we code a patch right =
now, to<br class=3D"">remove the block size limit of 1MB, but not =
activate it until far in<br class=3D"">the future. I would propose to =
remove the 1MB limit at the next block<br class=3D"">halving in spring =
2020, only limit the block size to 32MiB which is<br class=3D"">the =
maximum size the current p2p protocol allows. This patch must be<br =
class=3D"">in the immediate next release of Bitcoin Core.<br =
class=3D""><br class=3D"">With this patch in core's next release, =
Bitcoin works just as before,<br class=3D"">no fork will ever occur, =
until spring 2020. But everyone knows there<br class=3D"">will be a fork =
scheduled. Third party services, libraries, wallets and<br =
class=3D"">exchanges will have enough time to prepare for it over the =
next three<br class=3D"">years.<br class=3D""><br class=3D"">We don't =
yet have an agreement on how to increase the block size<br =
class=3D"">limit. There have been many proposals over the past years, =
like<br class=3D"">BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, =
248, BU, and so<br class=3D"">on. These hard fork proposals, with this =
patch already in Core's<br class=3D"">release, they all become soft =
fork. We'll have enough time to discuss<br class=3D"">all these =
proposals and decide which one to go. Take an example, if we<br =
class=3D"">choose to fork to only 2MB, since 32MiB already scheduled, =
reduce it<br class=3D"">from 32MiB to 2MB will be a soft fork.<br =
class=3D""><br class=3D"">Anyway, we must code something right now, =
before it becomes too late.<br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_BC91FADA-184C-4066-A5A0-1AE5AFC34D10--