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 --]
next prev parent 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