From: Pieter Wuille <pieter.wuille@gmail.com>
To: Jeff Garzik <jgarzik@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
Date: Fri, 26 Jun 2015 20:12:54 +0200 [thread overview]
Message-ID: <CAPg+sBg=sn7djO_8H16NDg7S7m7_0eTcrgLVofMWQ2ANz+jw9w@mail.gmail.com> (raw)
In-Reply-To: <CADm_Wca+ow4pMzN7SyKjsMdFo0wuUerYYjf5xKs5G_2Q2PzMmA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5743 bytes --]
I am not saying that economic change is what we want. Only that it is
inevitable, independent of whether larger blocks happen or not.
I am saying that acting because of fear of economic change is a bad reason.
The reason for increase should be because of the higher utility. We need it
at some point, but there should be no rush.
I do understand that we want to avoid a *sudden* change in economic policy,
but I'm generally not too worried. Either fees increase and they get paid,
and we're good. But more likely is that some uses just move off-chain
because the block chain does not offer what they need. That's sad, but it
is inevitable at any size: some uses fit, some don't.
--
Pieter
On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote:
> 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: 7125 bytes --]
next prev parent reply other threads:[~2015-06-26 18:12 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
2015-06-26 18:12 ` Pieter Wuille [this message]
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='CAPg+sBg=sn7djO_8H16NDg7S7m7_0eTcrgLVofMWQ2ANz+jw9w@mail.gmail.com' \
--to=pieter.wuille@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