Block Size Benchmarks

[Hydrogen]

There is much discussion on the topic of block size.

What is lacking in these talks is hard data.

Benchmarks, evidence, testing which conclusively demonstrate block size makes a difference in transactions.

The block size debate is a loose equivalent to debates geeks had in past years where some believed increasing RAM on a PC could make a big improvement in performance, while others held the opposing view; increasing RAM wouldn't make a noticeable difference in most cases.

The block size debate is like Intel vs AMD all over again.

We have benchmarks and testing that can quantify to a reasonable degree how Intel and AMD processors stack up against each other.

Where are benchmarks showing bitcoin unlimited or segwit have a legitimate claim to better transaction speed via increasing block size?

 

[jonald_fyookball]

Gavin did some testing with bigger blocks a while back.

https://bravenewcoin.com/news/gavin-andresen-tests-bitcoin-block-size-increase/

[Hydrogen]

Are there breakdowns or benchmarks which give an idea of how much faster a 2MB, 8MB or 20MB block size might be over current block size?

What if a 20MB blocksize only increased transactions to 10 per second.

 

It would be nice to have some idea of how many transactions per second a block size increase would yield.

[jonald_fyookball]

Are there breakdowns or benchmarks which give an idea of how much faster a 2MB, 8MB or 20MB block size might be over current block size?

What if a 20MB blocksize only increased transactions to 10 per second.

 

It would be nice to have some idea of how many transactions per second a block size increase would yield.

All things being equal, I would think there'd be a linear relationship between TPS and blocksize.
If 3 TPS is generally filling blocks up to 1MB, then we should get about 30 TPS for 10MB blocks.

Obviously size in bytes of transactions matters but no reason that would change... Slightly
longer time for block propogation shouldn't matter either as the 10min timeframe would still
stay the mean after difficulty adjustments.

Am I missing anything big?

[Kakmakr]

Are there breakdowns or benchmarks which give an idea of how much faster a 2MB, 8MB or 20MB block size might be over current block size?

What if a 20MB blocksize only increased transactions to 10 per second.

 

It would be nice to have some idea of how many transactions per second a block size increase would yield.

All things being equal, I would think there'd be a linear relationship between TPS and blocksize.
If 3 TPS is generally filling blocks up to 1MB, then we should get about 30 TPS for 10MB blocks.

Obviously size in bytes of transactions matters but no reason that would change... Slightly
longer time for block propogation shouldn't matter either as the 10min timeframe would still
stay the mean after difficulty adjustments.

Am I missing anything big?

Yea, you are quick to explain how "good" bigger Block sizes will be for Bitcoin. Now try to be biased and explain how vulnerable 10MB / 20MB blocks sizes will be to other attack vectors and why Satoshi never increased it to those levels from the start.

How long can you upgrade only the Block size to match transactions throughput equivalent to VISA and Mastercard?

I am curious to see your answer to this. ^smile^

[panju1]

Now try to be biased and explain how vulnerable 10MB / 20MB blocks sizes will be to other attack vectors and why Satoshi never increased it to those levels from the start.

Satoshi never increased to those levels from the start, because they weren't necessary.

Here is a whitepaper for all the calculations you need.
https://bravenewcoin.com/assets/Whitepapers/block-size-1.1.1.pdf

[Kakmakr]

Now try to be biased and explain how vulnerable 10MB / 20MB blocks sizes will be to other attack vectors and why Satoshi never increased it to those levels from the start.

Satoshi never increased to those levels from the start, because they weren't necessary.

Here is a whitepaper for all the calculations you need.
https://bravenewcoin.com/assets/Whitepapers/block-size-1.1.1.pdf

I read the White paper from back to front and I know Satoshi did not implement bigger blocks at the time, because there were no need for it, but he also held back because he/she knew bigger blocks can also be exploited with new attack vectors. So in my opinion increasing only the Block sizes, to scale will not be the answer and might even be dangerous.

I am also looking at the competition and I am thinking, will a increase in Block size scale to their levels? < Stop with the, Bitcoin is only a store of value argument, because that gets old and we know Satoshi wanted this to be a digital P2P payment network >

We have not even touched on other reasons, why only Bigger blocks, will not be the answer to scaling :

~ Larger blocks make full nodes more expensive to operate.
~ larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which    makes Bitcoin require more trust, which weakens Bitcoins value proposition.

[aarons6]

Yea, you are quick to explain how "good" bigger Block sizes will be for Bitcoin. Now try to be biased and explain how vulnerable 10MB / 20MB blocks sizes will be to other attack vectors and why Satoshi never increased it to those levels from the start.

How long can you upgrade only the Block size to match transactions throughput equivalent to VISA and Mastercard?

I am curious to see your answer to this. ^smile^

wait.. wasnt the "original" block size 32mb??

it was brought down to 1mb AFTER by the "core" developers, and it was temporary to keep spam down..

[Amph]

Yea, you are quick to explain how "good" bigger Block sizes will be for Bitcoin. Now try to be biased and explain how vulnerable 10MB / 20MB blocks sizes will be to other attack vectors and why Satoshi never increased it to those levels from the start.

How long can you upgrade only the Block size to match transactions throughput equivalent to VISA and Mastercard?

I am curious to see your answer to this. ^smile^

wait.. wasnt the "original" block size 32mb??

it was brought down to 1mb AFTER by the "core" developers, and it was temporary to keep spam down..

yeah it was but it was not used, apparently they were only two people using it, and those people were probably dev(satoshi and dunno...), and you can't expect any attack from them to the network(would be silly if not for testing), therefore having that huge limit, wasn't a problem back then

basically the block was changed only because of the evil nature of the human, if no one was going to attack it anyway there were no reason to change it

[jonald_fyookball]

Are there breakdowns or benchmarks which give an idea of how much faster a 2MB, 8MB or 20MB block size might be over current block size?

What if a 20MB blocksize only increased transactions to 10 per second.

 

It would be nice to have some idea of how many transactions per second a block size increase would yield.

All things being equal, I would think there'd be a linear relationship between TPS and blocksize.
If 3 TPS is generally filling blocks up to 1MB, then we should get about 30 TPS for 10MB blocks.

Obviously size in bytes of transactions matters but no reason that would change... Slightly
longer time for block propogation shouldn't matter either as the 10min timeframe would still
stay the mean after difficulty adjustments.

Am I missing anything big?

Yea, you are quick to explain how "good" bigger Block sizes will be for Bitcoin. Now try to be biased and explain how vulnerable 10MB / 20MB blocks sizes will be to other attack vectors and why Satoshi never increased it to those levels from the start.

The original size was 32MB.   I do not doubt there may be attack vectors that open up with really large blocks but to be honest I haven't heard too much about that.  Maybe you can enlighten me as to what those are and also why emergent consensus wouldn't mitigate those issues (miners refusing to create blocks that are problematic)

How long can you upgrade only the Block size to match transactions throughput equivalent to VISA and Mastercard?

I am curious to see your answer to this. ^smile^

I suppose that would depend on how technology evolves.   So, its an unknown.

For the record, i NEVER said I'm categorically against all off chain scaling, as long as there's free choice rather than a block limit which forces everyone off the main chain.

[eternalgloom]

Is there some kind of calculation to see how much the transaction speed would go up when Segwit is implemented with 1mb block size?
Bigger blocks will be needed, but to me it seems like it would be far more beneficial if segwit were implemented before changing block size.

[Carlton Banks]

Gavin did some testing with bigger blocks a while back.

https://bravenewcoin.com/news/gavin-andresen-tests-bitcoin-block-size-increase/

Usual lying by omission from you jonald


Gavin did these tests on his domestic 20 Mb/s connection. That's nowhere near what a typical internet user can even get access to, let alone afford.

wait.. wasnt the "original" block size 32mb??

it was brought down to 1mb AFTER by the "core" developers, and it was temporary to keep spam down..

yeah it was

Satoshi put in the 1MB, long before Bitcoin rebranded to Bitcoin Core

Is there some kind of calculation to see how much the transaction speed would go up when Segwit is implemented with 1mb block size?
Bigger blocks will be needed, but to me it seems like it would be far more beneficial if segwit were implemented before changing block size.

Bigger blocks are NOT the best way to increase the transaction rate


Bigger blocks are the most dangerous way to increase the transaction rate, there are OTHER OPTIONS APART FROM BIGGER BLOCKS. We should do the least sensible, most dangerous increases LAST, not FIRST.

[Xester]

Gavin did some testing with bigger blocks a while back.

https://bravenewcoin.com/news/gavin-andresen-tests-bitcoin-block-size-increase/

Usual lying by omission from you jonald


Gavin did these tests on his domestic 20 Mb/s connection. That's nowhere near what a typical internet user can even get access to, let alone afford.

wait.. wasnt the "original" block size 32mb??

it was brought down to 1mb AFTER by the "core" developers, and it was temporary to keep spam down..

yeah it was

Satoshi put in the 1MB, long before Bitcoin rebranded to Bitcoin Core

Is there some kind of calculation to see how much the transaction speed would go up when Segwit is implemented with 1mb block size?
Bigger blocks will be needed, but to me it seems like it would be far more beneficial if segwit were implemented before changing block size.

Bigger blocks are NOT the best way to increase the transaction rate


Bigger blocks are the most dangerous way to increase the transaction rate, there are OTHER OPTIONS APART FROM BIGGER BLOCKS. We should do the least sensible, most dangerous increases LAST, not FIRST.

If we all have the technology to speed things up without even increasing blocksize then it will be very helpful. But given our situation today that our technology could not cope up with the volume of transaction that are occurring daily then an increase in the blocksize is the last resort to make things faster. You have said that there are other options aside from bigger blocks, then would you care explaining it to us so we can also have an idea as to what is the best thing to do.

[Carlton Banks]

If we all have the technology to speed things up without even increasing blocksize then it will be very helpful. But given our situation today that our technology could not cope up with the volume of transaction that are occurring daily then an increase in the blocksize is the last resort to make things faster. You have said that there are other options aside from bigger blocks, then would you care explaining it to us so we can also have an idea as to what is the best thing to do.

The main point is that bigger blocks is NOT changing the scale of the network AT ALL. People really have to get this before we can move forward with this debate.


Bigger blocks increases the amount of transactions by the same amount no matter how much extra blocksize is added. A 1:1 rate of increase. So with a maximum of about 2500 transactions in 1MB, 2MB gives 5000 per block, 4 MB gives 10,000 per block etc etc.

THAT'S NOT THE ENGINEERING DEFINITION OF SCALING UP. It's literally keeping the scale the same.



2nd layers are the first way to go with real scaling, because they're developed, tested and proven. They're not perfect, but they don't need to be used for everything, and they work better for the most useful case anyway.

So, Lightning is a great fit for IRL bricks and mortar shops. I'll explain -

• Lightning transactions are confirmed instantly, the confirmation concept doesn't really exist in LN, because the transactions don't go into a block, so there is no block to wait for for confirms
• The shops can run their own Lightning node to use with their customers, instead of giving fees to banks or Card Companies like they do now
• Lightning's main flaw is that people who you deal with on the LN can try to screw with you by doing replay attacks and such. IRL shops need their customers to trust them, and are strongly motivated not to do that
• This avoids the "Hub" situation often misleadingly depicted as the problem with Lightning. You don't have to use a big channel that's acting as a Hub, you can use small channels that independent small shops can open for themselves

Because Lightning can fit 1000's of times the amount of transactions more into a block than on-chain bigger blocks can (because it's >1000:1 scaling, not 1:1), it's actually going to give us a more efficient network. It doesn't work well the more you have to trust the other party, but like I say, it works well for some cases and not for others.


For on-chain scaling, we could reduce the target of the time between blocks, currently targeting a 10 minute average. I don't know how much we could reduce it by, no-one has ever done testing of this on a Bitcoin testnet that I'm aware of.

BUT, the problems this could create (more orphaned blocks, so less confidence in the number of confirms that are considered safe) have been vastly improved because of all the improvements made to the efficiency that blocks are now relayed across the network (the dedicated Block Relay network and the Compact Blocks scheme have done the most to enable this possibility). These relay latency improvements will have given the developers SOME extra room in the propagation behaviour to reduce the time between blocks. Maybe it could be reduced to 5 mniutes, and that would have the same effect as a 2MB blocksize (i.e. half the interval, double the tx rate). This would mean changing the 25BTC block reward for mining by half too, otherwise we'd end up with far more than 21 million BTC total, which would not be good.


There are many many more way than just 2nd layers (other 2nd layer sclaing proposals are beginning to appear), or block interval reduction that could ACTUALLY change the scale we use the resources of the network.

But, and I reiterate, BIGGER BLOCKS DOES NOT IMPROVE THE SCALE. It creates more transactions per second, but LEAVES THE SCALE OF THE NETWORK THE SAME. For that reason, it's a dangerous last resort, definitely not what we should be considering to do FIRST.

[seradj0]

It would be better if segwit is implemented before changing block size

[eternalgloom]

Is there some kind of calculation to see how much the transaction speed would go up when Segwit is implemented with 1mb block size?
Bigger blocks will be needed, but to me it seems like it would be far more beneficial if segwit were implemented before changing block size.

Bigger blocks are NOT the best way to increase the transaction rate


Bigger blocks are the most dangerous way to increase the transaction rate, there are OTHER OPTIONS APART FROM BIGGER BLOCKS. We should do the least sensible, most dangerous increases LAST, not FIRST.

That's kinda what I was trying to say, I'm just an end-user, not a developer, but common sense makes me think that by implementing segwit, we're making the use of space more efficient (correct me if I'm wrong), which seems the best and most logical step to take first.

I did say that bigger blocks will be needed, because this seems to be inevitable in the future. Could Bitcoin even handle, say, 50 transactions per second without bigger blocks?

What would be the maximum amount of transactions per seconds it could handle without bigger blocks? Are there other solutions, improvements aside from segwit?

[jonald_fyookball]

Is there some kind of calculation to see how much the transaction speed would go up when Segwit is implemented with 1mb block size?
Bigger blocks will be needed, but to me it seems like it would be far more beneficial if segwit were implemented before changing block size.

Bigger blocks are NOT the best way to increase the transaction rate


Bigger blocks are the most dangerous way to increase the transaction rate, there are OTHER OPTIONS APART FROM BIGGER BLOCKS. We should do the least sensible, most dangerous increases LAST, not FIRST.

That's kinda what I was trying to say, I'm just an end-user, not a developer, but common sense makes me think that by implementing segwit, we're making the use of space more efficient (correct me if I'm wrong), which seems the best and most logical step to take first.

Why is that the best and most logical step to take first?

Why not do the simplest, least risky, least invasive, least controversial thing first, which would be to bump the blocks to 8MB or even 2MB?

The network can easily handle then... THEN maybe we can talk about segwit.

Where did this myth come from that its better to do segwit first?

[Carlton Banks]

That's kinda what I was trying to say, I'm just an end-user, not a developer, but common sense makes me think that by implementing segwit, we're making the use of space more efficient (correct me if I'm wrong), which seems the best and most logical step to take first.

Well, Segwit opens that door, but it doesn't do it on it's own.

Segwit is bigger blocks, on-chain scaling. But, because signature malleability isn't possible with Segwit transactions, it enables much improved 2nd layer solutions to work far better than they otherwise could (2nd layers have been possible since BIP 65 and BIP 66 soft forks activated last year).


Segwit arguably does change transaction space efficiency, but with a trade off: it make a new pruning mode possible, as only the signatures from newer blocks are needed to keep a full node running on the right blockchain. But that's a centralisation risk in it's own right, as then only miners need the signatures to run, users can switch to sig pruning mode. It saves the regular user 75% of their hard disk space, but I'm not sure its worth it. I'll be keeping the signatures (aka witness mode) on my node, and I hope the devs see sense to keep witness mode on as the default.

[eternalgloom]

Is there some kind of calculation to see how much the transaction speed would go up when Segwit is implemented with 1mb block size?
Bigger blocks will be needed, but to me it seems like it would be far more beneficial if segwit were implemented before changing block size.

Bigger blocks are NOT the best way to increase the transaction rate


Bigger blocks are the most dangerous way to increase the transaction rate, there are OTHER OPTIONS APART FROM BIGGER BLOCKS. We should do the least sensible, most dangerous increases LAST, not FIRST.

That's kinda what I was trying to say, I'm just an end-user, not a developer, but common sense makes me think that by implementing segwit, we're making the use of space more efficient (correct me if I'm wrong), which seems the best and most logical step to take first.

Why is that the best and most logical step to take first?

Why not do the simplest, least risky, least invasive, least controversial thing first, which would be to bump the blocks to 8MB or even 2MB?

The network can easily handle then... THEN maybe we can talk about segwit.

Where did this myth come from that its better to do segwit first?

Well, according to this page, increasing the block size also seems to be somewhat controversial.
https://en.bitcoin.it/wiki/Block_size_limit_controversy

And then this:
https://bitcoinmagazine.com/articles/security-researcher-found-bug-knocked-out-bitcoin-unlimited/
https://cointelegraph.com/news/community-reacts-to-bitcoin-unlimited-bug-calls-for-segwit-activation

I mean if I see all this stuff, as a non-developer, it seems to me that Bitcoin unlimited also has plenty of issues to be worried about.

[AliceWonderMiscreations]

Is there some kind of calculation to see how much the transaction speed would go up when Segwit is implemented with 1mb block size?
Bigger blocks will be needed, but to me it seems like it would be far more beneficial if segwit were implemented before changing block size.

Bigger blocks are NOT the best way to increase the transaction rate


Bigger blocks are the most dangerous way to increase the transaction rate, there are OTHER OPTIONS APART FROM BIGGER BLOCKS. We should do the least sensible, most dangerous increases LAST, not FIRST.

That's kinda what I was trying to say, I'm just an end-user, not a developer, but common sense makes me think that by implementing segwit, we're making the use of space more efficient (correct me if I'm wrong), which seems the best and most logical step to take first.

Why is that the best and most logical step to take first?

Why not do the simplest, least risky, least invasive, least controversial thing first, which would be to bump the blocks to 8MB or even 2MB?

The network can easily handle then... THEN maybe we can talk about segwit.

Where did this myth come from that its better to do segwit first?

Well, according to this page, increasing the block size also seems to be somewhat controversial.
https://en.bitcoin.it/wiki/Block_size_limit_controversy

And then this:
https://bitcoinmagazine.com/articles/security-researcher-found-bug-knocked-out-bitcoin-unlimited/
https://cointelegraph.com/news/community-reacts-to-bitcoin-unlimited-bug-calls-for-segwit-activation

I mean if I see all this stuff, as a non-developer, it seems to me that Bitcoin unlimited also has plenty of issues to be worried about.

Well if we are worried about the block size maybe causing issues, there is something we can do.

Instead of using a hard-coded block size that can only be changed by a hard fork, we could make the block size variable and determined by consensus.

That way if a size were to be used that started resulting in issues, the consensus could reduce it.

Someone should suggest that...