I'm struggling to illustrate how incredibly low 7 transactions per
second is, not just for a payment network, but even just for a clearance
network (i.e. to balance transactions between institutions and/or
chains). As an example, the Clearing House Interbank Payments System
(CHIPS) is a US-only, inter-bank only clearance network, which handled
about 3.5 transactions per second (average) in 2014
(https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en).
While it seems likely the US population of 300 million makes more
transactions individually than many other countries, and therefore we
can't simply multiply that by 20 to estimate what a global clearance
network might require, hopefully it's clear that if Bitcoin is to scale
globally, it needs substantially more transaction throughput even if
main chain transactions become something for banks and the super rich. I
don't know how much more, but I can't look at the 8MB reportedly backed
by a number of mining pools and say it's clearly insufficient, at least.
I should emphasise that I don't think we need to jump straight to 8MB
(or otherwise), if a scaling protocol can be decided upon that would be
ideal, but we should be planning ahead while it's still relatively easy
to make these changes.
Ross
On 18/06/2015 23:33, Mark Friedenbach wrote:
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgar...@bitpay.com
<mailto:jgar...@bitpay.com>> wrote:
The whole point is getting out in front of the need, to prevent
significant negative impact to users when blocks are consistently
full.
To do that, you need to (a) plan forward, in order to (b) set a
hard fork date in the future.
Or alternatively, fix the reasons why users would have negative
experiences with full blocks, chiefly:
* Get safe forms of replace-by-fee and child-pays-for-parent
finished and in 0.12.
* Develop cross-platform libraries for managing micropayment
channels, and get wallet authors to adopt
* Use fidelity bonds, solvency proofs, and other tricks to minimize
the risk of already deployed off-chain solutions as an interim measure
until:
* Deploy soft-fork changes for truly scalable solutions like
Lightning Network.
Not raising the block size limit does not mean doing nothing to solve
the problem.
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
