path: root/70/c295cfdf6b8a7463fd6aceac1e23eef1972f7e

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--