summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTier Nolan <tier.nolan@gmail.com>2015-06-26 14:47:24 +0100
committerbitcoindev <bitcoindev@gnusha.org>2015-06-26 13:47:26 +0000
commit38315c979cb78ddd7df7042e21da1bc661fbb625 (patch)
treee776298a86a9e9052889e46f65a05f0fcd3cc674
parent0c15338d52c5590593485b81e22a1338630456ef (diff)
downloadpi-bitcoindev-38315c979cb78ddd7df7042e21da1bc661fbb625.tar.gz
pi-bitcoindev-38315c979cb78ddd7df7042e21da1bc661fbb625.zip
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
-rw-r--r--9f/27ca3c87b92b40a21c6c3829dd0977d0726314128
1 files changed, 128 insertions, 0 deletions
diff --git a/9f/27ca3c87b92b40a21c6c3829dd0977d0726314 b/9f/27ca3c87b92b40a21c6c3829dd0977d0726314
new file mode 100644
index 000000000..94fa546c9
--- /dev/null
+++ b/9f/27ca3c87b92b40a21c6c3829dd0977d0726314
@@ -0,0 +1,128 @@
+Return-Path: <tier.nolan@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 25879323
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 26 Jun 2015 13:47:26 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com
+ [209.85.220.170])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 78AEFF2
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 26 Jun 2015 13:47:25 +0000 (UTC)
+Received: by qkhu186 with SMTP id u186so55249740qkh.0
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 26 Jun 2015 06:47:24 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
+ h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
+ :content-type; bh=8sjR4DbgUpGuAweoKLS32llK/4ovDkBZ6K8fnhLv6TY=;
+ b=iYwDjubYQbZAw9DfeFv7vYKySrVjROqa+iwG+Xi2SsjXNfFtI4aJcp8uvsNrqhCrAY
+ fEKT3QAKAZniFSZW3tSEjLaoCnZz6ZXuapWmq0WEjhMtTq9qgr/U7e93bIXJsfCYJhWl
+ vI23d8yppm/B68WDq+4xGTyEEAaVvq6qMJ2Bs+XJo6tksD4UWPn/MtVWuLRYVyYrclid
+ sqtAIrWzKgauP9Q5VaRBI4rlZPS90mmzyQW/N2u0pI92oJhHZos8RsDLuT+0l2kpzcN1
+ 9wUrft5basn1byKBqsFcuksBgUgSqkdMrcvQ4gYxsB/NIRaWQQ+RPKVRpMvyjTea4o/0
+ 8smw==
+MIME-Version: 1.0
+X-Received: by 10.140.237.147 with SMTP id i141mr2399647qhc.25.1435326444653;
+ Fri, 26 Jun 2015 06:47:24 -0700 (PDT)
+Received: by 10.140.85.241 with HTTP; Fri, 26 Jun 2015 06:47:24 -0700 (PDT)
+In-Reply-To: <CALqxMTHQCWSg5Px5iLzNisZchuyzWJ2KwtwbWycywDSjF+4GBA@mail.gmail.com>
+References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
+ <558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com>
+ <CADm_WcZ52_fvNk_rWzu+Nw1CBz2o6t6cMkEfOm3BpdjH7iQKrw@mail.gmail.com>
+ <0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com>
+ <CALqxMTHQCWSg5Px5iLzNisZchuyzWJ2KwtwbWycywDSjF+4GBA@mail.gmail.com>
+Date: Fri, 26 Jun 2015 14:47:24 +0100
+Message-ID: <CAE-z3OXEUE8b_u9Pf8DbPL4jWTqyR7CDJRqKFKoTGpGxnr1QoA@mail.gmail.com>
+From: Tier Nolan <tier.nolan@gmail.com>
+Cc: bitcoin-dev@lists.linuxfoundation.org
+Content-Type: multipart/alternative; boundary=001a1135ad28ded44d05196bfa25
+X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
+ RCVD_IN_DNSWL_LOW 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] Draft BIP : fixed-schedule block size increase
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+Precedence: list
+List-Id: Bitcoin Development 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: Fri, 26 Jun 2015 13:47:26 -0000
+
+--001a1135ad28ded44d05196bfa25
+Content-Type: text/plain; charset=UTF-8
+
+On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org> wrote:
+
+> The hard-cap serves the purpose of a safety limit in case our
+> understanding about the economics, incentives or game-theory is wrong
+> worst case.
+>
+
+True.
+
+BIP 100 and 101 could be combined. Would that increase consensus?
+
+- Miner vote threshold reached
+- Wait notice period or until earliest start time
+- Block size default target set to 1 MB
+- Soft limit set to 1MB
+- Hard limit set to 8MB + double every 2 years
+- Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB
+minimum)
+
+Block size updates could be aligned with the difficulty setting and based
+on the last 2016 blocks.
+
+Miners could leave the 1MB limit in place initially. The vote is to get
+the option to increase the block size.
+
+Legacy clients would remain in the network until >80% of miners vote to
+raise the limit and a miner produces a >1MB block.
+
+If the growth rate over-estimates hardware improvements, the devs could add
+a limit into the core client. If they give notice and enough users update,
+then miners would have to accept it.
+
+The block size becomes min(miner's vote, core devs). Even if 4 years
+notice is given, blocks would only be 4X optimal.
+
+--001a1135ad28ded44d05196bfa25
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr">On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <span dir=3D"lt=
+r">&lt;<a href=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cyphe=
+rspace.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
+=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
+0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+The hard-cap serves the purpose of a safety limit in case our<br>
+understanding about the economics, incentives or game-theory is wrong<br>
+worst case.<br></blockquote><div><br></div><div>True.<br><br>BIP 100 and 10=
+1 could be combined.=C2=A0 Would that increase consensus?<br><br></div><div=
+>- Miner vote threshold reached<br></div><div>- Wait notice period or until=
+ earliest start time<br></div><div>- Block size default target set to 1 MB<=
+br></div><div>- Soft limit set to 1MB<br></div><div>- Hard limit set to 8MB=
+ + double every 2 years<br></div><div>- Miner vote to decide soft limit (lo=
+west size ignoring bottom 20% but 1MB minimum)<br><br></div><div>Block size=
+ updates could be aligned with the difficulty setting and based on the last=
+ 2016 blocks.<br></div><br>Miners could leave the 1MB limit in place initia=
+lly.=C2=A0 The vote is to get the option to increase the block size.<br></d=
+iv><div class=3D"gmail_quote"><div><br>Legacy clients would remain in the n=
+etwork until &gt;80% of miners vote to raise the limit and a miner produces=
+ a &gt;1MB block.<br><br></div><div>If the growth rate over-estimates hardw=
+are improvements, the devs could add a limit into the core client.=C2=A0 If=
+ they give notice and enough users update, then miners would have to accept=
+ it.<br><br></div><div>The block size becomes min(miner&#39;s vote, core de=
+vs).=C2=A0 Even if 4 years notice is given, blocks would only be 4X optimal=
+.<br></div></div></div></div>
+
+--001a1135ad28ded44d05196bfa25--
+