📅 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>;
Ross Nicoll [ARCHIVE] /
npub10p…pfaef
2023-06-07 15:38:36
in reply to nevent1q…dnmp
Author Public Key
npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaefSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:38:36Event JSON
{
"id": "6ed64de65244b84a204b28a82ee2c188dd8caf1b5b4418f191adc7e7f793669d",
"pubkey": "787ecd48da0d9610d322fb67c86ad23a5287d688559b2ff8ee546721fd990129",
"created_at": 1686152316,
"kind": 1,
"tags": [
[
"e",
"23c1bb2f25b9e7356b48aa2a86751c4f26fb3977b440917a1cb3512c200b0b2f",
"",
"root"
],
[
"e",
"d64fa948bd6414c23ebce4d85dbf1f44f6f665440be3c65e66486e200f98be76",
"",
"reply"
],
[
"p",
"33228a8ed797b24e872fc0257c1515fc9bca74c0b230dcbb7d3d2bd38fd97ed7"
]
],
"content": "📅 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",
"sig": "71ba74743e0ec7a8d91f63d34d14c241c15a1b1224175f016df102d248a685ed9189ae054a245512f138ee9067d0e495fa473769acd46be1713e99a6457a1a1e"
}