From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A613B408 for ; Wed, 22 Jul 2015 19:17:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 670FC191 for ; Wed, 22 Jul 2015 19:17:49 +0000 (UTC) Received: by pdbnt7 with SMTP id nt7so72289541pdb.0 for ; Wed, 22 Jul 2015 12:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=NlcCyRCHk2283Ba/JAgxa4nPQNtShn3bCW4QU8+p5iM=; b=puNaAzbMHMgHmGco+3XAnq83mr1lSnjwc3P26OzcPYBBysdElq5UxCnzkV2GF6Pfh5 DmfgRDFzbKriVAMs71R4pFNrPODH6el6/xl3YYuXPkr+sCOeXhmo79WYUZkzY+kbVkie H2giqbjIF6pJyKxZepTT218pGZjs7bItsDzTJwKiaHHFwDL/SZTerxPsTGHUckOyj+/1 HQt/qPn4Q0nAH96TvB8ZGWPHOO2b5VBtiPXQ5iLpgJyDrYPRnEY5txOA+0rKbPwdOntI MUjJi88MGRLVzl1aDKUbGAGeyZZUfsisfNqEbZ/V0n87JJevdTvOT32dZ/izAfHZKqPb JfWA== X-Received: by 10.70.31.5 with SMTP id w5mr9120881pdh.3.1437592668938; Wed, 22 Jul 2015 12:17:48 -0700 (PDT) Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id kw5sm4747410pab.29.2015.07.22.12.17.46 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 12:17:47 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_02174A37-04FB-4D42-8176-339E93D1AE0C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: Date: Wed, 22 Jul 2015 12:17:44 -0700 Message-Id: References: To: Jeff Garzik X-Mailer: Apple Mail (2.2098) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 19:17:50 -0000 --Apple-Mail=_02174A37-04FB-4D42-8176-339E93D1AE0C Content-Type: multipart/alternative; boundary="Apple-Mail=_9E02F14E-0A66-4E19-8AA3-11D40A49CEA5" --Apple-Mail=_9E02F14E-0A66-4E19-8AA3-11D40A49CEA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 22, 2015, at 10:33 AM, Jeff Garzik via bitcoin-dev = wrote: >=20 > On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev = > 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. >=20 >=20 >=20 > This completely ignores reality, what users have experienced for the = past ~6 years. >=20 > "Change in economics is always happening" does not begin to approach = the scale of the change. >=20 > 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=E2=80=99s 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=E2=80=A6and I believe the = priorities are misplaced here. We=E2=80=99ve had over six years to start = working on solutions but we keep =E2=80=9Ckicking the can down the = road=E2=80=9D - until when?!?! I believe unless there=E2=80=99s a strong = need to find a solution no solutions will really be found. >=20 > 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. >=20 > 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. >=20 > [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin = > [2] = http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent = >=20 > 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. >=20 > Next, when blocks are consistently full, the past consensus was that = block size limit will be increased eventually. What happens at that = point? >=20 > 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. >=20 > 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. >=20 > 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 >=20 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=E2=80=A6and quite frankly, there are a number of other = significant issues that I think are far bigger obstacles to widespread = adoption than =E2=80=9CI have to pay a fee=E2=80=9D. 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)=E2=80=A6= and places huge centralization pressures on validation=E2=80=A6and = 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. >=20 > 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. >=20 >=20 > False. >=20 > 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. >=20 > 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. >=20 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=E2=80=99re 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. >=20 > Stonewalling size increase changes is just as much as a Ben = Bernanke/FOMC move as increasing the hard limit by hard fork. >=20 >=20 > 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. >=20 > 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. >=20 >=20 > Actually you are. >=20 > 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. >=20 > Further, it increases the market disruption users will experience, as = described above. >=20 > Think about the users. Please. >=20 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=E2=80=A6 More the reason to go through the steps needed while we=E2=80=99re still = small to correct the core issues. >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_9E02F14E-0A66-4E19-8AA3-11D40A49CEA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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> = 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=E2=80=99s 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=E2=80=A6and I = believe the priorities are misplaced here. We=E2=80=99ve had over six = years to start working on solutions but we keep =E2=80=9Ckicking the can = down the road=E2=80=9D - until when?!?! I believe unless there=E2=80=99s = 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
[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


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=E2=80=A6and quite frankly, there are a number of = other significant issues that I think are far bigger obstacles to = widespread adoption than =E2=80=9CI have to pay a fee=E2=80=9D. 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)=E2=80=A6and places huge centralization pressures on = validation=E2=80=A6and 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=E2=80=99re 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=E2=80=A6

More the reason to go = through the steps needed while we=E2=80=99re still small to correct the = core issues.


_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_9E02F14E-0A66-4E19-8AA3-11D40A49CEA5-- --Apple-Mail=_02174A37-04FB-4D42-8176-339E93D1AE0C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVr+xYAAoJEJNAI64YFENUlSIP/0hb1bq4BlWOu2DAAZNlgY1u l6TPlrU/R0zwTuuGSEc6aCgYHb26NJS4i/JmOT+fFsZG9cBckXEZ6mwmxskadi0j Tk8iZEJqjqg1uCPtUAF3X/rgVJWJj4vMGe7cazZjmHOxNG2zOH8OmSM/navET0HN 1cna2rpKSXoyyt0CqIcsvf8jFcd2By7NhfCQfjEHKExImETJC84Tqyh+7/7eykzn Vu1nbScuSeEorLsJI0C6OaA0HdHgJtpj8UW4oMjjKcEQZrSZgDglwwd7ihRrWSWR dJkfeOvCRVBnZ99wxUhLuefyGFcM5gJ/P4nkWjAp9Fs405GWdqpj5BqJpVk5tCWj ZIU9ZczIlBIxmOVW3wz/mlghwjaXu1cBc4PwTYojEh7R6HS8jcfzJkNUIa1h7FM5 czuNQdfiRlLXD8lXFw9ijBph921zSr08ozMlRaWNTGy/7DY0PgGvgl4mOrK00tMw g+Z20bW7SGFJGP4bvKfdhV4dcJcZWa1gMNNCdCi0hFjGp6mHGdN2fTN3GX8aN+8C CsMUyIrJc5SGketWQ/6u+HKy9VAaXhqd6dt0u+peo+BspEgqLChtcxeAE09hbXL0 llffSpriKtThcsgK7cM3tuZzlrcSenrvhlq12LbWZ939oeqpcTccVLnRFOlVoEom ZkK+bDbCQ3zEd40SYmyC =GUxJ -----END PGP SIGNATURE----- --Apple-Mail=_02174A37-04FB-4D42-8176-339E93D1AE0C--