From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3A5EE89E for ; 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 ; 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 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: To: Wang Chun <1240902@gmail.com>, bitcoin-dev In-Reply-To: Message-Id: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 = 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 = 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
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.medi= awiki

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-Fe= bruary/013542.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:

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.

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.

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.

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.

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.

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<= br class=3D"">

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