genjix (OP)
Legendary
 Offline
Activity: 1232
Merit: 1076
|
 |
May 07, 2011, 12:33:22 AM
Last edit: May 10, 2011, 10:06:49 AM by genjix |
|
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.
|
|
|
|
|
|
|
|
"With e-currency based on cryptographic proof, without the need to
trust a third party middleman, money can be secure and transactions
effortless." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
Garrett Burgwardt
|
|
May 07, 2011, 12:34:36 AM |
|
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.
|
|
|
|
|
|
slurch
|
|
May 07, 2011, 12:36:36 AM |
|
|
Donations accepted at: 1AXKzVc1tTmfC6VkWwBNSzKqThqhwsC5mY
For what, I have no idea...
|
|
|
genjix (OP)
Legendary
Offline
Activity: 1232
Merit: 1076
|
|
May 07, 2011, 12:41:08 AM |
|
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? |
|
|
|
|
|
Garrett Burgwardt
|
|
May 07, 2011, 12:47:34 AM |
|
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.
|
|
|
|
|
genjix (OP)
Legendary
Offline
Activity: 1232
Merit: 1076
|
|
May 07, 2011, 03:03:39 PM |
|
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.
|
|
|
|
|
grue
Legendary
Offline
Activity: 2058
Merit: 1431
|
|
May 08, 2011, 12:27:29 AM |
|
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. |
|
|
|
genjix (OP)
Legendary
Offline
Activity: 1232
Merit: 1076
|
|
May 08, 2011, 12:50:37 PM |
|
How about banks though that are all running decades old software from the 80s?
|
|
|
|
|
caveden
Legendary
Offline
Activity: 1106
Merit: 1004
|
|
May 08, 2011, 03:40:46 PM |
|
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.
I share your concern, that's why I proposed this: http://bitcointalk.org/index.php?topic=1865.0It 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... |
|
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1129
|
|
May 10, 2011, 03:37:35 PM |
|
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.
|
|
|
|
|
|
gigabytecoin
|
|
May 11, 2011, 10:24:58 AM |
|
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? |
|
|
|
|
|
