public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
Date: Fri, 18 Dec 2015 08:56:45 -0500	[thread overview]
Message-ID: <CADm_WcaxTmnAQR6+fejEEFB8bGQviHEE8_G5SQRygXOX1c6XSQ@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBjbATqf8DXGF7obw9a=371zQ_S0EgTapnUmukAVenTneQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]

On Fri, Dec 18, 2015 at 2:56 AM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

> On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik <jgarzik@gmail.com> wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisfy economic demand. If that is the
> >> case, Bitcoin has failed, in my opinion.
> >
> > Diverging from the satoshi block size change plan[1] and current
> economics
> > would seem to require a high level of months-ahead communication to
> users.
>
> I don't see any plan, but will you say the same thing when the subsidy
>

Yes, I forgot the link:

[1] https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366



> dwindles, and mining income seems to become uncertain? It will equally
> be an economic change, which equally well will have been predictable,
> and it will equally well be treatable with a hardfork to increase the
> subsidy.
>

That is a red herring.  Nobody I know has proposed this, and I am opposed
to changing that fundamental.

It is well known that the 1M limit was never intended to stay, unlike 21M
coin limit etc.

1M was set high in the beginning because it is a DoS engineering limit, not
an [accidental] economic policy tool.




> But I am not against a block size increase hard fork. My talk on
> segregated witness even included proposed pursuing a hard fork at a
> slightly later stage.
>

Great!



> But what you're arguing for is that - despite being completely
> expected - blocks grew fuller, and people didn't adapt to block size
> pressure and a fee market, so the Core committee now needs to kick the
> can down the road, because we can't accept the risk of economic
> change. That sounds very much like a bailout to me.
>

I am arguing for continuing what we know works.  We are 100% certain
blocks-not-full-on-avg works, where a "buffer" of space exists between avg
block size and hard limit.

Any other avenue is by definition speculation and risk.  You _think_ you
know what a healthy fee market _should_ be.  Massive damage occurs to
bitcoin if you are wrong - and I listed several

vis expectation, there is clear consensus and expectation that block size
would increase, from 2010 onward.  It was always a question of _when_ not
if.

Sticking with 1M presents clear risk of (a) economic fracture and (b)
community fracture.  It quite clearly risks massive change to an unknown
system at an unknown, unpredictable date in the future.

BIP 102 presents an expected upgrade at a predictable date in the future.

[-- Attachment #2: Type: text/html, Size: 4189 bytes --]

  parent reply	other threads:[~2015-12-18 13:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16 14:53 [bitcoin-dev] Block size: It's economics & user preparation & moral hazard Jeff Garzik
2015-12-16 18:34 ` Pieter Wuille
2015-12-16 21:08   ` Jeff Garzik
2015-12-16 21:11     ` Pieter Wuille
2015-12-17  2:06       ` Jameson Lopp
2015-12-17 16:58       ` Tier Nolan
2015-12-17 19:44         ` Peter Todd
2015-12-18  5:23           ` Jorge Timón
2015-12-18  9:44           ` Tier Nolan
2015-12-16 21:24     ` Jorge Timón
2015-12-16 21:36       ` Jeff Garzik
2015-12-18  5:11   ` Jeff Garzik
2015-12-18  7:56     ` Pieter Wuille
2015-12-18 10:13       ` sickpig
2015-12-18 15:48         ` Pieter Wuille
2015-12-19 19:04           ` Dave Scotese
     [not found]           ` <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
2015-12-26 16:44             ` Pieter Wuille
2015-12-26 17:20               ` Jorge Timón
2015-12-26 22:55               ` Jonathan Toomim
2015-12-26 23:01                 ` Pieter Wuille
2015-12-26 23:07                   ` Jonathan Toomim
2015-12-26 23:16                     ` Pieter Wuille
2015-12-27  0:03                       ` Jonathan Toomim
2015-12-26 23:15                   ` Justus Ranvier
2015-12-27  0:13                     ` Bryan Bishop
2015-12-27  0:33                       ` Justus Ranvier
2015-12-18 13:56       ` Jeff Garzik [this message]
2015-12-23  6:26   ` Aaron Voisine
2015-12-16 18:36 ` jl2012
2015-12-16 22:27   ` Jeff Garzik
2015-12-17  6:12     ` Dave Scotese

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=CADm_WcaxTmnAQR6+fejEEFB8bGQviHEE8_G5SQRygXOX1c6XSQ@mail.gmail.com \
    --to=jgarzik@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pieter.wuille@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