summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Lízner <martin.lizner@gmail.com>2017-03-29 09:49:31 +0200
committerbitcoindev <bitcoindev@gnusha.org>2017-03-29 07:49:53 +0000
commitc8803bd807599ec0d3de2cc0180afc39e2f82b9e (patch)
tree95662897221e82f5daf3c655441fa3deb030fd5a
parent5b14b74b9ede0490fd410e1f62881901f67bbbab (diff)
downloadpi-bitcoindev-c8803bd807599ec0d3de2cc0180afc39e2f82b9e.tar.gz
pi-bitcoindev-c8803bd807599ec0d3de2cc0180afc39e2f82b9e.zip
Re: [bitcoin-dev] Hard fork proposal from last week's meeting
-rw-r--r--f0/990dd2a99f5fec46a2929132bf8d98da6fae68188
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">&lt;<a href=3D"mailto:bitcoi=
+n-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxf=
+oundation.org</a>&gt;</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&#39=
+;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&#39;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&#39;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&#39;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&#39;s<br>
+release, they all become soft fork. We&#39;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--
+