diff options
author | Martin Lízner <martin.lizner@gmail.com> | 2017-03-29 09:49:31 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-03-29 07:49:53 +0000 |
commit | c8803bd807599ec0d3de2cc0180afc39e2f82b9e (patch) | |
tree | 95662897221e82f5daf3c655441fa3deb030fd5a | |
parent | 5b14b74b9ede0490fd410e1f62881901f67bbbab (diff) | |
download | pi-bitcoindev-c8803bd807599ec0d3de2cc0180afc39e2f82b9e.tar.gz pi-bitcoindev-c8803bd807599ec0d3de2cc0180afc39e2f82b9e.zip |
Re: [bitcoin-dev] Hard fork proposal from last week's meeting
-rw-r--r-- | f0/990dd2a99f5fec46a2929132bf8d98da6fae68 | 188 |
1 files changed, 188 insertions, 0 deletions
diff --git a/f0/990dd2a99f5fec46a2929132bf8d98da6fae68 b/f0/990dd2a99f5fec46a2929132bf8d98da6fae68 new file mode 100644 index 000000000..7c81e0e19 --- /dev/null +++ b/f0/990dd2a99f5fec46a2929132bf8d98da6fae68 @@ -0,0 +1,188 @@ +Return-Path: <martin.lizner@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 87C5787A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 29 Mar 2017 07:49:53 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com + [209.85.216.179]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E86167C + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 29 Mar 2017 07:49:52 +0000 (UTC) +Received: by mail-qt0-f179.google.com with SMTP id i34so5996104qtc.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 29 Mar 2017 00:49:52 -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=Q6+0zlr4pLiLvVONRSEmKSXwuiwzEesMrEEUBjmmiOo=; + b=GgPLtAYoiPkxwpr9GdE+PlBIIiPNnRYcgJ9eAtCpE8r7MzqUr42lZJzDjB9z8BO5fr + c+C/BQKs05UqLGp2+k/0W7OIyvmh0m5A2liS8epLzpFaq2Zv0RfmwQE9+ej3y8gFhUWN + Axfepq2G47KtJKKKh7xWflBUJEiabjGjf6Bwuxh0hMzz4kP4oPrpelya83G+3IU75kiL + GBndd24socDp4HLVTY1+nDJ3iGP7i1hf4f69UhcJlsew9k59N3UMOTXbqWhboD2cwxG/ + e+IKTuAwoEv9O3WBb7AVB2QNg5q9zNDcec0Fep2d122uXnLjcvBnleabk5l/rt9nlNUg + XF4w== +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=Q6+0zlr4pLiLvVONRSEmKSXwuiwzEesMrEEUBjmmiOo=; + b=F2Ey3nAp+8f+ZebGxlM46HNI4obRkXoMjW8WPIkAaUZAn+9dIDAafSyByuGOPO2Qi4 + M1yDPrKU+K264UN1M1YwNkWt4AQtub1AI0tH/9+mWeg35/Y3sLE56hfi//U+DJgMfcFp + y1qnvwu2qLAxp52L22XeOU66d6d2OOOG1uUGS3dooo/FIUOye8fXXP/ZfF7Bi/fXybLz + AeEIm/oD2qP4qV3WHhxcYFQXDfBNy/BxKA1pi7HdbjOMPPGAuib3E4M2KlCbICjY3GGl + GL2vjdaD01P8WzhoTCGejaEkFSgqt/fHB4DcDYfnVw1kmMZwxI9MRsKu9jDjHPyThPqp + zhUQ== +X-Gm-Message-State: AFeK/H01SM9igmiiYUHJv7KR9VKxQjENO5KtsMFo2tN+bBkpXe5cZjUnilmrkTp4JovlFU+7PnhhPrdw/m5bAQ== +X-Received: by 10.200.56.210 with SMTP id g18mr29064112qtc.63.1490773791840; + Wed, 29 Mar 2017 00:49:51 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.200.41.124 with HTTP; Wed, 29 Mar 2017 00:49:31 -0700 (PDT) +In-Reply-To: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com> +References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com> +From: =?UTF-8?Q?Martin_L=C3=ADzner?= <martin.lizner@gmail.com> +Date: Wed, 29 Mar 2017 09:49:31 +0200 +Message-ID: <CAB-xxiPV9oN1r2hV5a=U1pcYuiZ_qmth-AM-H+1Cjgc2uw-0xA@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=001a1142917c4dbb47054bd9d226 +X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + RCVD_IN_DNSWL_LOW, + RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Wed, 29 Mar 2017 13:48:39 +0000 +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: Wed, 29 Mar 2017 07:49:53 -0000 + +--001a1142917c4dbb47054bd9d226 +Content-Type: text/plain; charset=UTF-8 + +If there should be a hard-fork, Core team should author the code. Other dev +teams have marginal support among all BTC users. + +Im tending to believe, that HF is necessary evil now. But lets do it in +conservative approach: +- Fix historical BTC issues, improve code +- Plan HF activation date well ahead - 12 months+ +- Allow increasing block size on year-year basis as Luke suggested +- Compromise with miners on initial block size bump (e.g. 2MB) +- SegWit + +Martin Lizner + +On Tue, Mar 28, 2017 at 6:59 PM, 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 +> + +--001a1142917c4dbb47054bd9d226 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">If there should be a hard-fork, Core team should author th= +e code. Other dev teams have marginal support among all BTC users.<div><br>= +</div><div>Im tending to believe, that HF is necessary evil now. But lets d= +o it in conservative approach:</div><div>- Fix historical BTC issues, impro= +ve code</div><div>- Plan HF activation date well ahead - 12 months+</div><d= +iv>- Allow increasing block size on year-year basis as Luke suggested</div>= +<div>- Compromise with miners on initial block size bump (e.g. 2MB)</div><d= +iv>- SegWit</div><div><br></div><div>Martin Lizner</div></div><div class=3D= +"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Mar 28, 2017 at 6:59 P= +M, Wang Chun via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoi= +n-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxf= +oundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st= +yle=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<br> +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> + +--001a1142917c4dbb47054bd9d226-- + |