diff options
| author | Alphonse Pace <alp.bitcoin@gmail.com> | 2017-03-28 12:23:31 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-03-28 17:23:33 +0000 |
| commit | aadc6f2e9a265536b9947e7a8fbfa3331605f413 (patch) | |
| tree | ac24a8a0da091354984e3cedeac9d14a215bf62e | |
| parent | 04eea78a61c124521d2f78703a81149452ff5ca9 (diff) | |
| download | pi-bitcoindev-aadc6f2e9a265536b9947e7a8fbfa3331605f413.tar.gz pi-bitcoindev-aadc6f2e9a265536b9947e7a8fbfa3331605f413.zip | |
Re: [bitcoin-dev] Hard fork proposal from last week's meeting
| -rw-r--r-- | 07/a0b96d504a51dcf16a2cdb8ef59db2e56b06bf | 204 |
1 files changed, 204 insertions, 0 deletions
diff --git a/07/a0b96d504a51dcf16a2cdb8ef59db2e56b06bf b/07/a0b96d504a51dcf16a2cdb8ef59db2e56b06bf new file mode 100644 index 000000000..c7378e192 --- /dev/null +++ b/07/a0b96d504a51dcf16a2cdb8ef59db2e56b06bf @@ -0,0 +1,204 @@ +Return-Path: <alp.bitcoin@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 8717A8EE + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 28 Mar 2017 17:23:33 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-pg0-f66.google.com (mail-pg0-f66.google.com [74.125.83.66]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1459623A + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 28 Mar 2017 17:23:32 +0000 (UTC) +Received: by mail-pg0-f66.google.com with SMTP id 81so22788069pgh.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 28 Mar 2017 10:23:32 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to; + bh=lfA7XXirNhsmE9ToxfExKdOApwQCTdkZPdoOmkXKCLE=; + b=gS9/txsKTkLHyolVqwK5iQCPTHd66kl/zMlijU2Ed368412b7Jdk3XTth9lhYyGzZA + oertwQAslBRfXBEqwectGz7V1XybNtPTfjsbV0fZ1Mdyookqgk9oaxwX0FDMv9D12yI5 + 9rcgShY6byTjDxutoDV3ye/TtPsvNGcSSSfmvHUZW1xlmFAT6LN8ligW+kKVfZA9QY2z + O1c0ywlX9lNjmp6EcoY9B7lCLv1FOdeOjZ6mL/3ee3ktfxrlbiWzKHu0rRXSEYgRyW/v + GPLRNWPlwnaqWADl2zXbsNPTFUcnSigZZ1j2JEz+8fJVQKkIPYLEKFE32XZsvgQL/aXE + HWhQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to; + bh=lfA7XXirNhsmE9ToxfExKdOApwQCTdkZPdoOmkXKCLE=; + b=Dwcq22z6FMCsC3piimjVI5zj6mkkh5Id4W/YImDttE4yhmQSmOrZiUXBwexiooXaoJ + 72w4+2qLkpQJ1oeqkkkA+NxSVHUoFjp7nUeg+vgoSAqV2JHpZisv8CE0FmnrqEvSQ1oG + 0RLV9C2R/x1VWShw5lFreIbGbLbXoKjMrDHo7cDpZ9JQHrbWYxD5hlI7kG2QvwXgvpWc + UwUiOgrIUXnGnu96bpDv0eCDIQGh1DxNWDI720xjalBO3lKpHr5FeGHxeQOM/fyMpAKm + icSVtNTgG/mvnuPRD6njvvQJ7/Qv+BMeunyaIHd2bNPL4dFCfqsefulch//67Lrf7NTT + 9P4Q== +X-Gm-Message-State: AFeK/H3IjM0nxfTbSBi/uB3+dhnmpVOBcx6FPche51ZlmAjHOhBt8dmNmcoVWJTtJfS3dktsCLhNZRMZxNE5BQ== +X-Received: by 10.99.140.27 with SMTP id m27mr32009080pgd.174.1490721811890; + Tue, 28 Mar 2017 10:23:31 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.100.128.19 with HTTP; Tue, 28 Mar 2017 10:23:31 -0700 (PDT) +In-Reply-To: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com> +References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com> +From: Alphonse Pace <alp.bitcoin@gmail.com> +Date: Tue, 28 Mar 2017 12:23:31 -0500 +Message-ID: <CAMBsKS8oSKS5g8UEyCu18bjzGJWpA+sJEaxBUV9FXAmXhX1ApA@mail.gmail.com> +To: Wang Chun <1240902@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=94eb2c1b6a240e874b054bcdb865 +X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + RCVD_IN_DNSWL_NONE, + RCVD_IN_SORBS_SPAM autolearn=no 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:23:33 -0000 + +--94eb2c1b6a240e874b054bcdb865 +Content-Type: text/plain; charset=UTF-8 + +What meeting are you referring to? Who were the participants? + +Removing the limit but relying on the p2p protocol is not really a true +32MiB limit, but a limit of whatever transport methods provide. This can +lead to differing consensus if alternative layers for relaying are used. +What you seem to be asking for is an unbound block size (or at least +determined by whatever miners produce). This has the possibility (and even +likelihood) of removing many participants from the network, including many +small miners. + +32MB in less than 3 years also appears to be far beyond limits of safety +which are known to exist far sooner, and we cannot expect hardware and +networking layers to improve by those amounts in that time. + +It also seems like it would be much better to wait until SegWit activates +in order to truly measure the effects on the network from this increased +capacity before committing to any additional increases. + +-Alphonse + + + +On Tue, Mar 28, 2017 at 11:59 AM, 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 +> + +--94eb2c1b6a240e874b054bcdb865 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">What meeting are you referring to?=C2=A0 Who were the part= +icipants?<div><br></div><div>Removing the limit but relying on the p2p prot= +ocol is not really a true 32MiB limit, but a limit of whatever transport me= +thods provide.=C2=A0 This can lead to differing consensus if alternative la= +yers for relaying are used.=C2=A0 What you seem to be asking for is an unbo= +und block size (or at least determined by whatever miners produce).=C2=A0 T= +his has the possibility (and even likelihood) of removing many participants= + from the network, including many small miners. =C2=A0</div><div><br></div>= +<div>32MB in less than 3 years also appears to be far beyond limits of safe= +ty which are known to exist far sooner, and we cannot expect hardware and n= +etworking layers to improve by those amounts in that time.</div><div><br></= +div><div>It also seems like it would be much better to wait until SegWit ac= +tivates in order to truly measure the effects on the network from this incr= +eased capacity before committing to any additional increases.</div><div><br= +></div><div>-Alphonse</div><div><br></div><div><br></div></div><div class= +=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Mar 28, 2017 at 11:= +59 AM, Wang Chun via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bi= +tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li= +nuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote= +" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I= +'ve proposed this hard fork approach last year in Hong Kong Consensus<b= +r> +but immediately rejected by coredevs at that meeting, after more than<br> +one year it seems that lots of people haven't heard of it. So I would<b= +r> +post this here again for comment.<br> +<br> +The basic idea is, as many of us agree, hard fork is risky and should<br> +be well prepared. We need a long time to deploy it.<br> +<br> +Despite spam tx on the network, the block capacity is approaching its<br> +limit, and we must think ahead. Shall we code a patch right now, to<br> +remove the block size limit of 1MB, but not activate it until far in<br> +the future. I would propose to remove the 1MB limit at the next block<br> +halving in spring 2020, only limit the block size to 32MiB which is<br> +the maximum size the current p2p protocol allows. This patch must be<br> +in the immediate next release of Bitcoin Core.<br> +<br> +With this patch in core's next release, Bitcoin works just as before,<b= +r> +no fork will ever occur, until spring 2020. But everyone knows there<br> +will be a fork scheduled. Third party services, libraries, wallets and<br> +exchanges will have enough time to prepare for it over the next three<br> +years.<br> +<br> +We don't yet have an agreement on how to increase the block size<br> +limit. There have been many proposals over the past years, like<br> +BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so<br> +on. These hard fork proposals, with this patch already in Core's<br> +release, they all become soft fork. We'll have enough time to discuss<b= +r> +all these proposals and decide which one to go. Take an example, if we<br> +choose to fork to only 2MB, since 32MiB already scheduled, reduce it<br> +from 32MiB to 2MB will be a soft fork.<br> +<br> +Anyway, we must code something right now, before it becomes too late.<br> +______________________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +</blockquote></div><br></div> + +--94eb2c1b6a240e874b054bcdb865-- + |