From: Eric Lombrozo <elombrozo@gmail.com>
To: Jeff Garzik <jgarzik@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Date: Wed, 22 Jul 2015 12:17:44 -0700 [thread overview]
Message-ID: <D93173FE-B018-4CD8-A31D-714364ADFE80@gmail.com> (raw)
In-Reply-To: <CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 7544 bytes --]
> On Jul 22, 2015, at 10:33 AM, 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 <mailto: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.
This is only because of the fact that only a negligible portion of miner income comes from fees - the vast majority still continues to be subsidized by block rewards. The original design of the protocol was such that this subsidy would be decreased over time to let fees become the predominant source of income for miners. Until we have fee pressures, there’s no incentive for the industry to find solutions to real problems that need solving. I think you underestimate the ingenuity of people when pressed for real solutions. The main barrier to Bitcoin adoption is NOT this issue…and I believe the priorities are misplaced here. We’ve had over six years to start working on solutions but we keep “kicking the can down the road” - until when?!?! I believe unless there’s a strong need to find a solution no solutions will really be found.
>
> 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 <http://hashingit.com/analysis/34-bitcoin-traffic-bulletin>
> [2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent <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
>
The current userbase and market is still tiny - we have to think bigger than this. We already go through loads of pain to use the current system…and quite frankly, there are a number of other significant issues that I think are far bigger obstacles to widespread adoption than “I have to pay a fee”. For example, the current cost of verification is too high to continue to ensure the security of the network (as the July 4th fork clearly illustrated)…and places huge centralization pressures on validation…and simply will not support hundreds of millions of users or billions of users. Increasing block size actually worsens the scaling properties, it does not improve them. We need better scaling solutions - almost certainly this will require avoiding the need for global consensus for the vast majority of transactions (nested consensus or off-chain direct party-to-party contract negotiation, the lightning network, etc. The focus on reducing fee pressure by increasing block size is a distraction from far more fundamental issues, IMHO.
>
> 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.
>
Wrong - the economic policy of bitcoin has always been, from the beginning, to subsidize blocks initially and transition to fees. Artificially continuing to rely on block reward subsidies is what is a new economic policy. We’re already six years in, pretty soon another halving is coming - how long are we going to wait to start transitioning? The lower block reward subsidies are, the more pain fee pressures will cause.
> "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.
>
I think about the billions of people out there in the world that could be using this technology that simply have no access to it right now. The majority or them which are unbanked, etc…
More the reason to go through the steps needed while we’re still small to correct the core issues.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #1.2: Type: text/html, Size: 11329 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
next prev parent reply other threads:[~2015-07-22 19:17 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
2015-07-22 16:52 ` [bitcoin-dev] Bitcoin Core and hard forks Pieter Wuille
2015-07-22 17:18 ` Ross Nicoll
2015-07-22 17:32 ` Milly Bitcoin
2015-07-22 18:45 ` Bryan Cheng
2015-07-22 17:33 ` Jeff Garzik
2015-07-22 18:01 ` Jeff Garzik
2015-07-22 18:03 ` Alex Morcos
2015-07-22 18:24 ` Jeff Garzik
2015-07-23 12:17 ` Jorge Timón
2015-07-23 16:17 ` Tom Harding
2015-07-23 16:28 ` Gavin Andresen
2015-07-23 16:50 ` cipher anthem
2015-07-23 17:14 ` Robert Learney
2015-07-23 18:21 ` Eric Lombrozo
2015-07-23 18:47 ` Jorge Timón
2015-07-23 17:43 ` Eric Lombrozo
2015-07-23 18:10 ` Jameson Lopp
2015-07-23 19:14 ` Eric Lombrozo
2015-07-23 19:35 ` Gavin Andresen
2015-07-23 19:39 ` Eric Lombrozo
2015-07-23 19:51 ` Eric Lombrozo
2015-07-23 19:52 ` Jameson Lopp
2015-07-23 20:26 ` Jorge Timón
2015-07-23 20:52 ` Eric Lombrozo
2015-07-23 23:42 ` Benedict Chan
[not found] ` <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmai>
2015-07-23 23:57 ` Eric Lombrozo
2015-07-24 0:04 ` Eric Lombrozo
2015-07-24 0:20 ` Simon Liu
2015-07-24 0:22 ` Jean-Paul Kogelman
2015-07-24 0:32 ` Eric Lombrozo
2015-07-24 0:38 ` Eric Lombrozo
2015-07-24 0:45 ` Jean-Paul Kogelman
2015-07-24 0:49 ` Jean-Paul Kogelman
2015-07-24 0:53 ` Peter Todd
2015-07-24 1:03 ` Jean-Paul Kogelman
2015-07-24 1:08 ` Eric Lombrozo
2015-07-24 1:25 ` Jean-Paul Kogelman
2015-07-24 1:28 ` Eric Lombrozo
2015-07-24 1:37 ` Eric Lombrozo
2015-07-24 1:42 ` Jean-Paul Kogelman
2015-07-24 1:55 ` Eric Lombrozo
2015-07-24 2:12 ` [bitcoin-dev] Bitcoin, Perceptions, and Expectations Raystonn .
2015-07-24 8:48 ` Jonas Schnelli
2015-07-24 9:42 ` Jorge Timón
2015-07-24 14:37 ` Vincent Truong
2015-07-25 2:18 ` gb
2015-07-25 11:22 ` Slurms MacKenzie
2015-07-25 15:04 ` Thomas Kerin
2015-07-24 0:56 ` [bitcoin-dev] Bitcoin Core and hard forks Eric Lombrozo
2015-07-24 1:05 ` Jean-Paul Kogelman
2015-07-23 18:12 ` Slurms MacKenzie
2015-07-23 18:57 ` Mike Hearn
2015-07-23 17:51 ` Jorge Timón
2015-07-24 6:30 ` Tom Harding
2015-07-24 9:24 ` Jorge Timón
2015-07-24 22:50 ` Tom Harding
2015-07-28 11:29 ` Jorge Timón
2015-07-28 11:32 ` Jorge Timón
2015-07-28 16:44 ` Tom Harding
2015-07-28 17:33 ` Jorge Timón
2015-07-22 19:17 ` Eric Lombrozo [this message]
2015-07-22 21:43 ` Mike Hearn
2015-07-22 21:56 ` Eric Lombrozo
2015-07-22 22:01 ` Mike Hearn
2015-07-22 22:09 ` Eric Lombrozo
2015-07-23 1:53 ` Eric Lombrozo
2015-07-22 22:30 ` Jeff Garzik
2015-07-23 0:27 ` Tom Harding
2015-07-23 0:37 ` Eric Lombrozo
2015-07-23 4:40 ` Edmund Edgar
2015-07-27 12:08 ` Peter Todd
2015-07-27 12:44 ` Milly Bitcoin
2015-07-22 22:40 Raystonn
2015-07-22 23:42 ` Cory Fields
2015-07-22 23:53 ` Eric Lombrozo
2015-07-23 0:05 ` Cory Fields
2015-07-23 0:13 ` Eric Lombrozo
2015-07-23 0:34 ` Cory Fields
2015-07-23 0:43 ` Eric Lombrozo
2015-07-23 7:24 ` Ross Nicoll
2015-07-23 0:49 ` Eric Voskuil
2015-07-23 18:12 ` Jorge Timón
[not found] <BA7ACCE1-81B2-4AC1-B6DD-7A856FD27D52@gmail.com>
2015-07-23 8:24 ` Gareth Williams
2015-07-27 17:05 Alice Larson
2015-07-27 17:22 ` Eric Voskuil
2015-07-28 4:55 ` Wladimir J. van der Laan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D93173FE-B018-4CD8-A31D-714364ADFE80@gmail.com \
--to=elombrozo@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jgarzik@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox