diff options
author | Tier Nolan <tier.nolan@gmail.com> | 2015-06-26 14:47:24 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-26 13:47:26 +0000 |
commit | 38315c979cb78ddd7df7042e21da1bc661fbb625 (patch) | |
tree | e776298a86a9e9052889e46f65a05f0fcd3cc674 | |
parent | 0c15338d52c5590593485b81e22a1338630456ef (diff) | |
download | pi-bitcoindev-38315c979cb78ddd7df7042e21da1bc661fbb625.tar.gz pi-bitcoindev-38315c979cb78ddd7df7042e21da1bc661fbb625.zip |
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
-rw-r--r-- | 9f/27ca3c87b92b40a21c6c3829dd0977d0726314 | 128 |
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"><<a href=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cyphe= +rspace.org</a>></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 >80% of miners vote to raise the limit and a miner produces= + a >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'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-- + |