Ross Nicoll [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-26 📝 Original message:I'd argue that at the ...
📅 Original date posted:2015-06-26
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/a81ace1f/attachment.html>;
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/a81ace1f/attachment.html>;