Talk:Scalability: Difference between revisions
No edit summary |
No edit summary |
||
Line 36: | Line 36: | ||
Would also be nice to get some kind of an estimate on how much the crypto-operations could be accelerated with a GPU. | Would also be nice to get some kind of an estimate on how much the crypto-operations could be accelerated with a GPU. | ||
[[User:Jojkaart|Jojkaart]] 20:48, 13 June 2011 (GMT) | [[User:Jojkaart|Jojkaart]] 20:48, 13 June 2011 (GMT) | ||
Shouldn't this (under Opimizations -> Network Structure): "''Switching to DNS would give dramatically faster startup times that do not scale with the size of the network.''" read: "''Switching to DNS would give dramatically faster startup times that do scale with the size of the network.''"? ie Remove the "not". | |||
--[[User:Tokoin|Tokoin]] 09:24, 21 July 2011 (GMT) |
Revision as of 09:24, 21 July 2011
There is one major point that the page overlooks: the limitation on block creation.
Block creation is limited to an average of one block every ten minutes. Furthermore, block size (which includes the transactions in the block) is limited to 1,000,000 bytes.
Each transaction requires 10 bytes, plus approximately 106 bytes for every input and approximately 69 bytes for every output. The exact size depends on the size of the public key, which I have not been able to confirm, but the keys in my wallet.dat seem to be about 65 bytes each.
If we assume that transactions average two inputs and two outputs, then the average transaction size will be about 350 bytes (note that the main page assumes an average of 1KB per transaction). If we further assume that the block size will, in practice, be limited to 500,000 bytes because the transaction fees increase as the block size increases, then that means there will be, on average, approximately 1430 transactions per block. That works out to an average of 2.5 transactions per second - well below the stated goal of at least 4,000 transactions per second.
Even if we assume only one input and one output per transaction, and that each block will contain the full 1,000,000 bytes, that still works out to only 5,405 transactions per block, or 9 transactions per second.
Unfortunately, this is not a limitation that can be overcome by simply increasing memory, or switching to a different ISP with more bandwidth. It is a built-in limitation, designed to deliberately slow down block creation. One solution is to somehow allow blocks to be freely created, while still keeping the rate of coin creation constant.
The bottom line is that, as it sits, this system is not scalable.
- MAX_BLOCK_SIZE has always been planned to increase as needed. That limitation should be ignored. theymos 17:15, 4 March 2011 (GMT)
- What Theymos said. Increasing MAX_BLOCK_SIZE will be done when "lightweight, header-only" client mode is done. Until then, block size has to be kept under control.--Gavin Andresen 00:19, 5 March 2011 (GMT)
- I've updated the page with more discussion of this topic. --Mike March 5 2011
The thing with VISA or and credit card company is that there wouldn't be that many actual transactions. When I buy stuff with my credit card the vender doesn't get paid instantly. I pay my bill once a month and the vender gets all his transactions lumped into one payment from VISA (once a week, I think). Someone correct me if I'm wrong, but the number of real transfers of money would be much smaller. --Randomproof 17:29, 1 April 2011 (GMT)
Would also be nice to get some kind of an estimate on how much the crypto-operations could be accelerated with a GPU. Jojkaart 20:48, 13 June 2011 (GMT)
Shouldn't this (under Opimizations -> Network Structure): "Switching to DNS would give dramatically faster startup times that do not scale with the size of the network." read: "Switching to DNS would give dramatically faster startup times that do scale with the size of the network."? ie Remove the "not". --Tokoin 09:24, 21 July 2011 (GMT)