diff options
author | Alex Morcos <morcos@gmail.com> | 2015-07-22 14:03:55 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-07-22 18:03:58 +0000 |
commit | 413b77c775dcd56e9e1dd568789bc10f4f0450b8 (patch) | |
tree | 419b47b997d5c9de863e855645545571f815e682 | |
parent | 70c72e5047620db9edc2212849fe9458e39c00c6 (diff) | |
download | pi-bitcoindev-413b77c775dcd56e9e1dd568789bc10f4f0450b8.tar.gz pi-bitcoindev-413b77c775dcd56e9e1dd568789bc10f4f0450b8.zip |
Re: [bitcoin-dev] Bitcoin Core and hard forks
-rw-r--r-- | 37/cb316eba5edb8b7eb7784006536cdc7615b853 | 312 |
1 files changed, 312 insertions, 0 deletions
diff --git a/37/cb316eba5edb8b7eb7784006536cdc7615b853 b/37/cb316eba5edb8b7eb7784006536cdc7615b853 new file mode 100644 index 000000000..9a98b5610 --- /dev/null +++ b/37/cb316eba5edb8b7eb7784006536cdc7615b853 @@ -0,0 +1,312 @@ +Return-Path: <morcos@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 36FAE71F + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 22 Jul 2015 18:03:58 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com + [209.85.212.177]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB26F1AE + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 22 Jul 2015 18:03:56 +0000 (UTC) +Received: by wibud3 with SMTP id ud3so164725347wib.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 22 Jul 2015 11:03:55 -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:to + :cc:content-type; + bh=ugMjmztXfyf2ydsmx+weGY6T0Qh7D9iQlEN9c/5uMo8=; + b=Eo3xx598DZBE3xw185YvBfcqCIaMYU884pqx2xvfGcoxFzIVtJ0EOcbeuaSIRup2cE + LPjiUckt179+JpHGC0KeYhn9hZukdDEGhLyZ3I/Ue3RCF1okrer+VT+jNKKjsGNr/bdw + F+UIByyvW2d0lHdvHe74YzRt6RN8c/HyxgJ+z1ETmRzhM8C/JlJlj7J2ONUrUEz+CVPv + QaTVkbwIaspclR8iXc3XmgLo6RrcBlht/SbIYwvaTBsTQx37Nx1I5PxTOb21D5KnqIT5 + Krwl6uPltYTkwIw1jMnTZEmsPpJpjy/mb7Qp2CxqiQAnOYWBiGzV9tawdv8YaArqAwcV + +rwg== +MIME-Version: 1.0 +X-Received: by 10.180.10.200 with SMTP id k8mr8859199wib.5.1437588235298; Wed, + 22 Jul 2015 11:03:55 -0700 (PDT) +Received: by 10.180.168.34 with HTTP; Wed, 22 Jul 2015 11:03:55 -0700 (PDT) +In-Reply-To: <CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com> +References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com> + <CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com> + <CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com> +Date: Wed, 22 Jul 2015 14:03:55 -0400 +Message-ID: <CAPWm=eW8RgrG1CMEAMN4GeiMjZecFvNtZB_Y4rZNeofWSD0=Wg@mail.gmail.com> +From: Alex Morcos <morcos@gmail.com> +To: Jeff Garzik <jgarzik@gmail.com> +Content-Type: multipart/alternative; boundary=001a11c26458195162051b7a986b +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: bitcoin-dev@lists.linuxfoundation.org +Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks +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: Wed, 22 Jul 2015 18:03:58 -0000 + +--001a11c26458195162051b7a986b +Content-Type: text/plain; charset=UTF-8 + +Jeff I respectively disagree with many of your points, but let me just +point out 2. + +Over the last 6 years there may not have been fee pressure, but certainly +there was the expectation that it was going to happen. Look at all the +work that has been put into fee estimation, why do that work if the +expectation was there would be no fee pressure? + +I know you respect Pieter's work, so I don't want to twist your words, but +for the clarity of other people reading these posts, it sounds like you're +accusing Pieter and others of stonewalling size increases and not +participating in planning for them. Without debate, no one has done more +for this project to make eventual size increases technically feasible than +Pieter. We only have the privilege of even having this debate as a result +of his work. + + + +On Wed, Jul 22, 2015 at 1:33 PM, Jeff Garzik via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +>> Some people have called the prospect of limited block space and the +>> development of a fee market a change in policy compared to the past. I +>> respectfully disagree with that. Bitcoin Core is not running the Bitcoin +>> economy, and its developers have no authority to set its rules. Change in +>> economics is always happening, and should be expected. Worse, intervening +>> in consensus changes would make the ecosystem more dependent on the group +>> taking that decision, not less. +>> +>> +> This completely ignores *reality*, what users have experienced for the +> past ~6 years. +> +> "Change in economics is always happening" does not begin to approach the +> scale of the change. +> +> For the entirety of bitcoin's history, absent long blocks and traffic +> bursts, fee pressure has been largely absent. +> +> Moving to a new economic policy where fee pressure is consistently present +> is radically different from what users, markets, and software have +> experienced and *lived.* +> +> Analysis such as [1][2] and more shows that users will hit a "painful" +> "wall" and market disruption will occur - eventually settling to a new +> equilibrium after a period of chaos - when blocks are consistently full. +> +> [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin +> [2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent +> +> First, users & market are forced through this period of chaos by "let a +> fee market develop" as the whole market changes to a radically different +> economic policy, once the network has never seen before. +> +> Next, when blocks are consistently full, the past consensus was that block +> size limit will be increased eventually. What happens at that point? +> +> Answer - Users & market are forced through a second period of chaos and +> disruption as the fee market is rebooted *again* by changing the block +> size limit. +> +> The average user hears a lot of noise on both sides of the block size +> debate, and really has no idea that the new "let a fee market develop" +> Bitcoin Core policy is going to *raise fees* on them. +> +> It is clear that +> - "let the fee market develop, Right Now" has not been thought through +> - Users are not prepared for a brand new economic policy +> - Users are unaware that a brand new economic policy will be foisted upon +> them +> +> +> +>> So to point out what I consider obvious: if Bitcoin requires central +>> control over its rules by a group of developers, it is completely +>> uninteresting to me. Consensus changes should be done using consensus, and +>> the default in case of controversy is no change. +>> +> +> False. +> +> All that has to do be done to change bitcoin to a new economic policy - +> not seen in the entire 6 year history of bitcoin - is to stonewall work on +> block size. +> +> Closing size increase PRs and failing to participate in planning for a +> block size increase accomplishes your stated goal of changing bitcoin to a +> new economic policy. +> +> "no [code] change"... changes bitcoin to a brand new economic policy, +> picking economic winners & losers. Some businesses will be priced out of +> bitcoin, etc. +> +> Stonewalling size increase changes is just as much as a Ben Bernanke/FOMC +> move as increasing the hard limit by hard fork. +> +> +> +>> My personal opinion is that we - as a community - should indeed let a fee +>> market develop, and rather sooner than later, and that "kicking the can +>> down the road" is an incredibly dangerous precedent: if we are willing to +>> go through the risk of a hard fork because of a fear of change of +>> economics, then I believe that community is not ready to deal with change +>> at all. And some change is inevitable, at any block size. Again, this does +>> not mean the block size needs to be fixed forever, but its intent should be +>> growing with the evolution of technology, not a panic reaction because a +>> fear of change. +>> +>> But I am not in any position to force this view. I only hope that people +>> don't think a fear of economic change is reason to give up consensus. +>> +> +> Actually you are. +> +> When size increase progress gets frozen out of Bitcoin Core, that just +> *increases* the chances that progress must be made through a contentious +> hard fork. +> +> Further, it increases the market disruption users will experience, as +> described above. +> +> Think about the users. Please. +> +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> + +--001a11c26458195162051b7a986b +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Jeff I respectively disagree with many of your points, but= + let me just point out 2.<div><br></div><div>Over the last 6 years there ma= +y not have been fee pressure, but certainly there was the expectation that = +it was going to happen.=C2=A0 Look at all the work that has been put into f= +ee estimation, why do that work if the expectation was there would be no fe= +e pressure?</div><div><br></div><div>I know you respect Pieter's work, = +so I don't want to twist your words, but for the clarity of other peopl= +e reading these posts, it sounds like you're accusing Pieter and others= + of stonewalling size increases and not participating in planning for them.= +=C2=A0 Without debate, no one has done more for this project to make eventu= +al size increases technically feasible than Pieter.=C2=A0 We only have the = +privilege of even having this debate as a result of his work.</div><div><br= +></div><div>=C2=A0=C2=A0</div></div><div class=3D"gmail_extra"><br><div cla= +ss=3D"gmail_quote">On Wed, Jul 22, 2015 at 1:33 PM, Jeff Garzik via bitcoin= +-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat= +ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></s= +pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= +;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class= +=3D"">On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <span = +dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta= +rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:= +<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span clas= +s=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;= +border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:= +solid;padding-left:1ex"><p dir=3D"ltr">Some people have called the prospect= + of limited block space and the development of a fee market a change in pol= +icy compared to the past. I respectfully disagree with that. Bitcoin Core i= +s not running the Bitcoin economy, and its developers have no authority to = +set its rules. Change in economics is always happening, and should be expec= +ted. Worse, intervening in consensus changes would make the ecosystem more = +dependent on the group taking that decision, not less.<br></p> +<p dir=3D"ltr"></p></blockquote><div><br></div></span><div>This completely = +ignores <i>reality</i>, what users have experienced for the past ~6 years.<= +/div><div><br></div><div>"Change in economics is always happening"= +; does not begin to approach the scale of the change.</div><div><br></div><= +div>For the entirety of bitcoin's history, absent long blocks and traff= +ic bursts, fee pressure has been largely absent.</div><div><br></div><div>M= +oving to a new economic policy where fee pressure is consistently present i= +s radically different from what users, markets, and software have experienc= +ed and <i>lived.</i></div><div><br></div><div>Analysis such as [1][2] and m= +ore shows that users will hit a "painful" "wall" and ma= +rket disruption will occur - eventually settling to a new equilibrium after= + a period of chaos - when blocks are consistently full.</div><div><br></div= +><div>[1]=C2=A0<a href=3D"http://hashingit.com/analysis/34-bitcoin-traffic-= +bulletin" target=3D"_blank">http://hashingit.com/analysis/34-bitcoin-traffi= +c-bulletin</a></div><div>[2]=C2=A0<a href=3D"http://gavinandresen.ninja/why= +-increasing-the-max-block-size-is-urgent" target=3D"_blank">http://gavinand= +resen.ninja/why-increasing-the-max-block-size-is-urgent</a></div><div><br><= +/div><div>First, users & market are forced through this period of chaos= + by "let a fee market develop" as the whole market changes to a r= +adically different economic policy, once the network has never seen before.= +</div><div><br></div><div>Next, when blocks are consistently full, the past= + consensus was that block size limit will be increased eventually.=C2=A0 Wh= +at happens at that point?</div><div><br></div><div>Answer - Users & mar= +ket are forced through a second period of chaos and disruption as the fee m= +arket is rebooted <i>again</i> by changing the block size limit.</div><div>= +<br></div><div>The average user hears a lot of noise on both sides of the b= +lock size debate, and really has no idea that the new "let a fee marke= +t develop" Bitcoin Core policy is going to <i>raise fees</i>=C2=A0on t= +hem.</div><div><br></div><div>It is clear that</div><div>- "let the fe= +e market develop, Right Now" has not been thought through</div><div>- = +Users are not prepared for a brand new economic policy</div><div>- Users ar= +e unaware that a brand new economic policy will be foisted upon them</div><= +span class=3D""><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_= +quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-= +color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir=3D"= +ltr">So to point out what I consider obvious: if Bitcoin requires central c= +ontrol over its rules by a group of developers, it is completely uninterest= +ing to me. Consensus changes should be done using consensus, and the defaul= +t in case of controversy is no change.</p></blockquote><div><br></div></spa= +n><div>False.</div><div><br></div><div>All that has to do be done to change= + bitcoin to a new economic policy - not seen in the entire 6 year history o= +f bitcoin - is to stonewall work on block size.</div><div><br></div><div>Cl= +osing size increase PRs and failing to participate in planning for a block = +size increase accomplishes your stated goal of changing bitcoin to a new ec= +onomic policy.</div><div><br></div><div>"no [code] change"... cha= +nges bitcoin to a brand new economic policy, picking economic winners &= + losers.=C2=A0 Some businesses will be priced out of bitcoin, etc.</div><di= +v><br></div><div>Stonewalling size increase changes is just as much as a Be= +n Bernanke/FOMC move as increasing the hard limit by hard fork.</div><span = +class=3D""><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote= +" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color= +:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> +<p dir=3D"ltr">My personal opinion is that we - as a community - should ind= +eed let a fee market develop, and rather sooner than later, and that "= +kicking the can down the road" is an incredibly dangerous precedent: i= +f we are willing to go through the risk of a hard fork because of a fear of= + change of economics, then I believe that community is not ready to deal wi= +th change at all. And some change is inevitable, at any block size. Again, = +this does not mean the block size needs to be fixed forever, but its intent= + should be growing with the evolution of technology, not a panic reaction b= +ecause a fear of change.<br></p> +<p dir=3D"ltr">But I am not in any position to force this view. I only hope= + that people don't think a fear of economic change is reason to give up= + consensus.</p></blockquote><div><br></div></span><div>Actually you are.</d= +iv><div><br></div><div>When size increase progress gets frozen out of Bitco= +in Core, that just <i>increases</i>=C2=A0the chances that progress must be = +made through a contentious hard fork.</div><div><br></div><div>Further, it = +increases the market disruption users will experience, as described above.<= +/div><div><br></div><div>Think about the users.=C2=A0 Please.</div><div><br= +></div></div><br></div></div> +<br>_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +<br></blockquote></div><br></div> + +--001a11c26458195162051b7a986b-- + |