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