From: Jeff Garzik <jgarzik@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
Date: Fri, 26 Jun 2015 10:57:42 -0700 [thread overview]
Message-ID: <CADm_Wca+ow4pMzN7SyKjsMdFo0wuUerYYjf5xKs5G_2Q2PzMmA@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4845 bytes --]
It is not "fear" of fee pressure.
1) Blocks are mostly not-full on average.
2) Absent long blocks and stress tests, there is little fee pressure above
the anti-spam relay fee metric, because of #1.
3) As such, inducing fee pressure is a delta, a change from years-long
bitcoin economic policy. Each time we approach the soft limit, Bitcoin
Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al.
lobbies miners to upgrade.
(note - this is not an endorsement of these actions - it is a neutral
observation)
4) Inaction leads to consistent fee pressure as the months tick on and
system volume grows; thus, inaction leads to economic policy change.
5) Economic policy change leads to market and software disruption. The
market and software - notably wallets - is not prepared for this.
6) If you want to change economic policy, that's fine. But be honest and
admit you are arguing for a change, a delta from current market
expectations and behavior.
7) It is critical to first deal with what _is_, not what you wish the world
to be. You want a fee market to develop. There is nothing wrong with that
desire. It remains a delta from where we are today, and that is critically
relevant in a $3b+ market.
On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> Hello all,
>
> here I'm going to try to address a part of the block size debate which has
> been troubling me since the beginning: the reason why people seem to want
> it.
>
> People say that larger blocks are necessary. In the long term, I agree -
> in the sense that systems that do not evolve tend to be replaced by other
> systems. This evolution can come in terms of layers on top of Bitcoin's
> blockchain, in terms of the technology underlying various aspects of the
> blockchain itself, and also in the scale that this technology supports.
>
> I do, however, fundamentally disagree that a fear for a change in
> economics should be considered to necessitate larger blocks. If it is, and
> there is consensus that we should adapt to it, then there is effectively no
> limit going forward. This is similar to how Congress voting to increase the
> copyright term retroactively from time to time is really no different from
> having an infinite copyright term in the first place. This scares me.
>
> Here is how Gavin summarizes the future without increasing block sizes in
> PR 6341:
>
> > 1. Transaction confirmation times for transactions with a given fee will
> rise; very-low-fee transactions will fail to get confirmed at all.
> > 2. Average transaction fee paid will rise
> > 3. People or applications unwilling or unable to pay the rising fees
> will stop submitting transactions
> > 4. People and businesses will shelve plans to use Bitcoin, stunting
> growth and adoption
>
> Is it fair to summarize this as "Some use cases won't fit any more, people
> will decide to no longer use the blockchain for these purposes, and the
> fees will adapt."?
>
> I think that is already happening, and will happen at any scale. I believe
> demand for payments in general is nearly infinite, and only a small portion
> of it will eventually fit on a block chain (independent of whether its size
> is limited by consensus rules or economic or technological means).
> Furthermore, systems that compete with Bitcoin in this space already offer
> orders of magnitude more capacity than we can reasonably achieve with any
> blockchain technology at this point.
>
> I don't know what subset of use cases Bitcoin will cater to in the long
> term. They have already changed - you see way less betting transactions
> these days than a few years ago for example - and they will keep changing,
> independent of what effective block sizes we end up with. I don't think we
> should be afraid of this change or try to stop it.
>
> If you look at graphs of block sizes over time (for example,
> http://rusty.ozlabs.org/?p=498), it seems to me that there is very little
> "organic" growth, and a lot of sudden changes (which could correspond to
> changing defaults in miner software, introduction of popular
> sites/services, changes in the economy). I think these can be seen as the
> economy changing to full up the available space, and I believe these will
> keep happening at any size effectively available.
>
> None of this is a reason why the size can't increase. However, in my
> opinion, we should do it because we believe it increases utility and
> understand the risks; not because we're afraid of what might happen if we
> don't hurry up. And from that point of view, it seems silly to make a huge
> increase at once...
>
> --
> Pieter
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 6059 bytes --]
next prev parent reply other threads:[~2015-06-26 17:57 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-26 14:09 [bitcoin-dev] The need for larger blocks Pieter Wuille
2015-06-26 14:38 ` Venzen Khaosan
2015-06-26 15:22 ` Milly Bitcoin
2015-06-26 15:24 ` Pieter Wuille
2015-06-26 18:05 ` Jeff Garzik
2015-06-26 18:32 ` Milly Bitcoin
2015-06-26 15:38 ` Tom Harding
2015-06-26 16:22 ` Venzen Khaosan
2015-06-26 17:04 ` Tom Harding
2015-06-26 17:55 ` Gavin Andresen
2015-06-26 17:57 ` Jeff Garzik [this message]
2015-06-26 18:12 ` Pieter Wuille
2015-06-26 18:23 ` Jeff Garzik
2015-06-26 18:31 ` Mark Friedenbach
2015-06-26 19:05 ` Aaron Voisine
2015-06-26 18:34 ` Pieter Wuille
2015-06-26 19:18 ` Ross Nicoll
2015-06-26 19:36 ` Peter Todd
2015-06-27 6:13 ` Filipe Farinha
2015-06-27 7:14 ` Aaron Voisine
2015-06-27 15:13 ` Peter Todd
2015-06-27 19:40 ` Aaron Voisine
2015-06-26 18:47 ` Patrick Strateman
2015-06-26 19:03 ` Tier Nolan
2015-06-26 19:12 ` Mark Friedenbach
2015-06-26 20:44 ` Owen Gunden
2015-06-27 2:18 ` Eric Lombrozo
2015-06-27 2:54 ` Eric Lombrozo
2015-06-27 8:16 ` Venzen Khaosan
2015-06-26 18:29 ` Alex Morcos
2015-06-27 7:43 ` Wladimir J. van der Laan
2015-06-27 9:55 ` NxtChg
2015-06-27 10:04 ` Wladimir J. van der Laan
2015-06-27 10:29 ` NxtChg
2015-06-27 11:04 ` Jorge Timón
2015-06-27 11:18 ` Eric Lombrozo
2015-06-27 11:43 ` Jorge Timón
2015-06-27 12:10 ` NxtChg
2015-06-28 12:13 ` Jorge Timón
2015-06-28 13:51 ` Ivan Brightly
2015-06-28 14:13 ` Eric Lombrozo
2015-06-28 14:16 ` Eric Lombrozo
2015-06-28 14:22 ` Ivan Brightly
2015-06-28 15:05 ` Jorge Timón
2015-06-28 16:01 ` Ivan Brightly
2015-06-28 15:28 ` s7r
2015-06-28 15:45 ` Jorge Timón
2015-06-27 10:19 ` Venzen Khaosan
2015-06-27 19:55 ` Aaron Voisine
2015-06-28 16:37 ` Venzen Khaosan
2015-06-28 20:56 ` Aaron Voisine
2015-06-27 10:13 ` Jorge Timón
2015-06-27 12:09 ` Wladimir J. van der Laan
2015-06-27 12:15 ` NxtChg
2015-06-27 12:17 ` Greg Sanders
2015-06-27 12:25 ` NxtChg
2015-06-27 12:35 ` Greg Sanders
2015-06-27 12:25 ` Wladimir J. van der Laan
2015-06-27 12:50 ` NxtChg
2015-06-27 13:01 ` Wladimir J. van der Laan
2015-06-28 12:03 ` Jorge Timón
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_Wca+ow4pMzN7SyKjsMdFo0wuUerYYjf5xKs5G_2Q2PzMmA@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