public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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