Ross Nicoll [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-18 📝 Original message:I'm struggling to ...
📅 Original date posted:2015-06-18
📝 Original message: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 <jgarzik at bitpay.com
> <mailto:jgarzik at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/bdee73d5/attachment.html>;
📝 Original message: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 <jgarzik at bitpay.com
> <mailto:jgarzik at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/bdee73d5/attachment.html>;