That said I think we should be bumping up the block size sooner rather than later.
Agreed.
Why not build Bitcoin so that it doesn't need to scale from the start?
Topic: Limit on transaction speed (Read 3096 times)
Agreed.
Why not build Bitcoin so that it doesn't need to scale from the start?
I'm not planning on implementing block size checks in BitCoinJ. Most users will end up on lightweight clients that don't implement every single check, so it'll probably be OK.
That said I think we should be bumping up the block size sooner rather than later.
That said I think we should be bumping up the block size sooner rather than later.
I'm skeptical of this happening. Right now it's easy to upgrade while the community is small and people download their client from one source.
But once everybody is running different flavours of Bitcoin, network-wide upgrades are not a solution.
But once everybody is running different flavours of Bitcoin, network-wide upgrades are not a solution.
I share your concern, that's why I proposed this: https://bitcointalksearch.org/topic/block-size-limit-automatic-adjustment-1865
It would still need one backward incompatible change, but just one. Gavin once showed himself open to the idea, if somebody manages to implement it safely. Now we "only" need somebody good enough in C++ willing to give it a try...
How about banks though that are all running decades old software from the 80s?
I'm skeptical of this happening. Right now it's easy to upgrade while the community is small and people download their client from one source.
But once everybody is running different flavours of Bitcoin, network-wide upgrades are not a solution.
Take a look at ipv4 and ipv6 today. The internet runs slower, less secure and is running out of addresses but nobody upgrades. Eventhough there's been many years to enable ipv6 and the running out of ipv4 addresses was well predicted in advance.
that's because ipv6 required an hardware upgrade. But once everybody is running different flavours of Bitcoin, network-wide upgrades are not a solution.
Take a look at ipv4 and ipv6 today. The internet runs slower, less secure and is running out of addresses but nobody upgrades. Eventhough there's been many years to enable ipv6 and the running out of ipv4 addresses was well predicted in advance.
I'm skeptical of this happening. Right now it's easy to upgrade while the community is small and people download their client from one source.
But once everybody is running different flavours of Bitcoin, network-wide upgrades are not a solution.
Take a look at ipv4 and ipv6 today. The internet runs slower, less secure and is running out of addresses but nobody upgrades. Eventhough there's been many years to enable ipv6 and the running out of ipv4 addresses was well predicted in advance.
But once everybody is running different flavours of Bitcoin, network-wide upgrades are not a solution.
Take a look at ipv4 and ipv6 today. The internet runs slower, less secure and is running out of addresses but nobody upgrades. Eventhough there's been many years to enable ipv6 and the running out of ipv4 addresses was well predicted in advance.
There was an upgrade before, where the software was set to change to the new protocol after block XXXXX, and it was far enough away that most people upgraded before then.
When we start bumping up against the top of the block size limit, we can raise it. Until then it's just low to prevent spam.
Wouldn't this fork the chain? And don't you need the mutual agreement from loads of differing clients that might not upgrade simultaneously?
When we start bumping up against the top of the block size limit, we can raise it. Until then it's just low to prevent spam.
Hey,
I met a web designer guy who last night made a point about the number of transactions being limited because of the block size. I did some calculations. Can somebody confirm these numbers for me?
MAX_BLOCK_SIZE = 1000000 bytes
Average transaction = ~200 bytes (conservative lower limit)
Average number of tx per block = 1000000/200 = 5000
Each block has an interval of ~10 mins
that means 5000 confirmed tx / 10 mins OR 500 tx / min OR
8 tx / s
---------------
Visa must do thousands of tx a second or maybe more.
I met a web designer guy who last night made a point about the number of transactions being limited because of the block size. I did some calculations. Can somebody confirm these numbers for me?
MAX_BLOCK_SIZE = 1000000 bytes
Average transaction = ~200 bytes (conservative lower limit)
Average number of tx per block = 1000000/200 = 5000
Each block has an interval of ~10 mins
that means 5000 confirmed tx / 10 mins OR 500 tx / min OR
8 tx / s
---------------
Visa must do thousands of tx a second or maybe more.
Jump to: