Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Ross Nicoll <jrn@jrn.me.uk>]

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

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@bitpay.com 
> <mailto:jgarzik@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


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