summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAlex Morcos <morcos@gmail.com>2015-07-22 14:03:55 -0400
committerbitcoindev <bitcoindev@gnusha.org>2015-07-22 18:03:58 +0000
commit413b77c775dcd56e9e1dd568789bc10f4f0450b8 (patch)
tree419b47b997d5c9de863e855645545571f815e682
parent70c72e5047620db9edc2212849fe9458e39c00c6 (diff)
downloadpi-bitcoindev-413b77c775dcd56e9e1dd568789bc10f4f0450b8.tar.gz
pi-bitcoindev-413b77c775dcd56e9e1dd568789bc10f4f0450b8.zip
Re: [bitcoin-dev] Bitcoin Core and hard forks
-rw-r--r--37/cb316eba5edb8b7eb7784006536cdc7615b853312
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&#39;s work, =
+so I don&#39;t want to twist your words, but for the clarity of other peopl=
+e reading these posts, it sounds like you&#39;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">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
+ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
+rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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>&quot;Change in economics is always happening&quot=
+; does not begin to approach the scale of the change.</div><div><br></div><=
+div>For the entirety of bitcoin&#39;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 &quot;painful&quot; &quot;wall&quot; 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 &amp; market are forced through this period of chaos=
+ by &quot;let a fee market develop&quot; 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 &amp; 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 &quot;let a fee marke=
+t develop&quot; 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>- &quot;let the fe=
+e market develop, Right Now&quot; 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>&quot;no [code] change&quot;... cha=
+nges bitcoin to a brand new economic policy, picking economic winners &amp;=
+ 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 &quot;=
+kicking the can down the road&quot; 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&#39;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--
+