public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ross Nicoll <jrn@jrn.me.uk>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
Date: Fri, 26 Jun 2015 20:18:07 +0100	[thread overview]
Message-ID: <558DA56F.3010703@jrn.me.uk> (raw)
In-Reply-To: <CAPg+sBhrBUSfPdMjbLthLEFD17zBC3LoWf9LvZsOD1Vp0D78BQ@mail.gmail.com>

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

I'd argue that at the point where there's consistently more transactions 
than the network can handle, there are two significant risks. Firstly, 
that people don't care enough to pay the transaction fees required to 
get their transaction prioritised over another's, and secondly that as 
transactions start outright failing (which will happen with enough 
transactions backlogged) the network is considered unreliable, the 
currency illiquid, and there's a virtual "bank rush" to get into a more 
usable currency.

I understand the desire to use current demand to model future, however I 
feel there's a lack of understanding of just how inadequate the main 
chain is as a global clearance network. My go-to example for this is 
CHIPS (US-only, inter-bank only clearance) which already handles 
slightly over 3 transactions per second on average across a year 
(https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en). 
If Bitcoin is to be used across a wider portion of the world's 
population, and/or beyond clearance between financial institutions, it 
needs larger blocks. This is not about handling the several orders of 
magnitude more transactions that would be required to replace credit 
cards or cash, but simply to enabling other technologies to perform that 
scaling.

Also, and I'm aware most on this list do understand the situation better 
than this, I find it immensely frustrating to see people suggesting that 
Greece or other large groups should adopt Bitcoin, while there's clearly 
inadequate support (on chain or off) to do so.

Ross

On 26/06/2015 19:34, Pieter Wuille wrote:
>
> > If you wait until the need to increase block size
>
> It is this sentence I disagree with. Why would there be a need? 
> Bitcoin provides utility at any block size, and potentially more with 
> larger blocks.
>
> But no matter what, I believe the economy will adapt to what is 
> available. And setting a precedent that increasing the size "because 
> of a need" is reasonable is to me essentially the same as saying the 
> size should forever scale to whatever people want.
>
> I believe the most important effect of a limit block size - people 
> deciding not to use (on chain) Bitcoin transactions, is already 
> happening, and it will keep happening at any scale.
>
> Either the resulting market is one which can live with high 
> variability in confirmation times, and blocks will end up being nearly 
> full. Or maybe the current fill level is what is acceptable, and we 
> don't see much growth beyond this, only a change in what it is used for.
>
> -- 
> Pieter
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

  reply	other threads:[~2015-06-26 19:18 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
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 [this message]
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=558DA56F.3010703@jrn.me.uk \
    --to=jrn@jrn.me.uk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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