Question Re: Block Size and Time

[ranlo]

We keep having discussions about increasing the maximum block size to speed up transactions when we have a congested network. Why don't we just:

Leave block size the same
Decrease block rate to 5m
Decrease block finder reward by half to 12.5

Would this not help solve the same problem, while at the same time speeding up transactions as a whole?

There must be something I'm missing. I know block time affects security but can't we assume the network is secure with the current hash rate?

[1715065948]

1715065948

[1715065948]

1715065948

[jl2012]

I know block time affects security

You have answered your question. I think having 2MB Block/10 minutes is securer than 1MB Block/5 minutes because the latter would have higher orphan rate (i.e. wasted hashing power).

The difference should be more obvious if miners will mine a block header before the block is completely validated.

[ranlo]

I know block time affects security

You have answered your question. I think having 2MB Block/10 minutes is securer than 1MB Block/5 minutes because the latter would have higher orphan rate (i.e. wasted hashing power).

The difference should be more obvious if miners will mine a block header before the block is completely validated.

5m shouldn't make a huge difference on orphans though. Even some coins with 1m blocks don't suffer from high orphan rates. And usually block time is seen as a security flaw when there is little hash power. BTC has so much that at this point, those who would be able to exploit it with a faster block could do it even with the slower one since they'd be the majority of the mining power.

I just feel like we're tackling the wrong issue here.

[jl2012]

I know block time affects security

You have answered your question. I think having 2MB Block/10 minutes is securer than 1MB Block/5 minutes because the latter would have higher orphan rate (i.e. wasted hashing power).

The difference should be more obvious if miners will mine a block header before the block is completely validated.

5m shouldn't make a huge difference on orphans though. Even some coins with 1m blocks don't suffer from high orphan rates. And usually block time is seen as a security flaw when there is little hash power. BTC has so much that at this point, those who would be able to exploit it with a faster block could do it even with the slower one since they'd be the majority of the mining power.

I just feel like we're tackling the wrong issue here.

I think it also depends on the block size. I suppose most of those 1min blocks are empty. As the block size approaches the network bandwidth limit, the adverse effect of short block interval will be more obvious.

[Mikestang]

We keep having discussions about increasing the maximum block size to speed up transactions when we have a congested network. Why don't we just:

Leave block size the same
Decrease block rate to 5m
Decrease block finder reward by half to 12.5

Would this not help solve the same problem, while at the same time speeding up transactions as a whole?

There must be something I'm missing. I know block time affects security but can't we assume the network is secure with the current hash rate?

If you want to do that, make another coin and set it up that way.

What you're missing is this is how Satoshi designed the system to function.  If you want faster tx, try an alt coin.

[ranlo]

We keep having discussions about increasing the maximum block size to speed up transactions when we have a congested network. Why don't we just:

Leave block size the same
Decrease block rate to 5m
Decrease block finder reward by half to 12.5

Would this not help solve the same problem, while at the same time speeding up transactions as a whole?

There must be something I'm missing. I know block time affects security but can't we assume the network is secure with the current hash rate?

If you want to do that, make another coin and set it up that way.

What you're missing is this is how Satoshi designed the system to function.  If you want faster tx, try an alt coin.

By increasing the block size, they are attempting to make transactions faster (by not having transactions that should be in the first block have to wait 2-3-4 blocks to be added).

[-ck]

5m shouldn't make a huge difference on orphans though. Even some coins with 1m blocks don't suffer from high orphan rates.

Do you have anything to support that conjecture? Sure the random coins with 1m blocks you're talking about dont have high orphan rates but that's almost certainly because the number of actual effective mining nodes is small rather than "1 minute is okay". One only produces orphans when there are other nodes finding blocks within a short time frame. The less nodes there are mining, the lower the probability of orphans. Not to mention the blocks will always be tiny with virtually no transactions on these altchains. They can't be compared.

[Mikestang]

We keep having discussions about increasing the maximum block size to speed up transactions when we have a congested network. Why don't we just:

Leave block size the same
Decrease block rate to 5m
Decrease block finder reward by half to 12.5

Would this not help solve the same problem, while at the same time speeding up transactions as a whole?

There must be something I'm missing. I know block time affects security but can't we assume the network is secure with the current hash rate?

If you want to do that, make another coin and set it up that way.

What you're missing is this is how Satoshi designed the system to function.  If you want faster tx, try an alt coin.

By increasing the block size, they are attempting to make transactions faster (by not having transactions that should be in the first block have to wait 2-3-4 blocks to be added).

No, that is not what increasing the block size is going to do, you misunderstand the issue.

[ranlo]

We keep having discussions about increasing the maximum block size to speed up transactions when we have a congested network. Why don't we just:

Leave block size the same
Decrease block rate to 5m
Decrease block finder reward by half to 12.5

Would this not help solve the same problem, while at the same time speeding up transactions as a whole?

There must be something I'm missing. I know block time affects security but can't we assume the network is secure with the current hash rate?

If you want to do that, make another coin and set it up that way.

What you're missing is this is how Satoshi designed the system to function.  If you want faster tx, try an alt coin.

By increasing the block size, they are attempting to make transactions faster (by not having transactions that should be in the first block have to wait 2-3-4 blocks to be added).

No, that is not what increasing the block size is going to do, you misunderstand the issue.

Then what does it do?

[Mikestang]

https://www.google.com/cse?cx=016660200577587308545%3Aesf40ml9aag&ie=UTF-8&q=increase+block+size&sa=Google+search#gsc.tab=0&gsc.q=increase%20block%20size&gsc.page=1

It prevents a bottleneck from happening as the number of transactions increases.

[ranlo]

https://www.google.com/cse?cx=016660200577587308545%3Aesf40ml9aag&ie=UTF-8&q=increase+block+size&sa=Google+search#gsc.tab=0&gsc.q=increase%20block%20size&gsc.page=1

It prevents a bottleneck from happening as the number of transactions increases.

So it is literally what I said. Re-read the statement.

[Mikestang]

You said, "... they are attempting to make transactions faster..", so no, it is not literally what you said.  There is no attempt being made here to speed up transactions, that will always be every 10 minutes +/-.

[ranlo]

You said, "... they are attempting to make transactions faster..", so no, it is not literally what you said.  There is no attempt being made here to speed up transactions, that will always be every 10 minutes +/-.

I see the issue now. You quit reading before you actually read the statement, and instead resort to a false implication of what I was saying rather than taking the extra 2-3 seconds and just reading it. To help spell it out for you:

"(by not having transactions that should be in the first block have to wait 2-3-4 blocks to be added)."

If the current block size can hold 100 transactions and there are 101, they will be put into two blocks. The second one has to come after the first (right? Bitcoin won't let two blocks be filled at the exact same time). The time for a block is 10 minutes. Therefore, one transaction will be forced to wait 10 minutes AFTER the current block.

Increasing block size allows all 101 to enter the first block. Basic math tells us that with an average block time of 10 minutes, the first scenario would result in 20 minutes (avg.) used, while the second would only require 10. To break this down:

Block 1: 10* minutes, 100 transactions
Block 2: 20* minutes, 1 transaction

*time from last block.

According to WolframAlpha, 10 minutes is less than 20 minutes (click the link, and it will calculate it for you).

Therefore, it has just concluded that increasing the block size will speed up transactions (once the blocks are getting to the point where they are full/overfilled, which is what the increase is in relation to). Because, again, having them all in one block is faster than having them in two blocks. Simple math.

As per my original question, which nobody has really been able to explain (and has nothing to do with any of your replies since you were caught up trying to avoid reading my statement and just making false inferences) is how this is different than halving the block time/rewards and leaving the maximum block size at 1/2 whatever they're going for (10Mb instead of 20), which would ALSO benefit in giving faster transactions while at the same time fixing the original problem.

So far, the reason has been that "Satoshi" didn't make it that way. We've made multiple changes away from how it was originally created, so that's not a reason. It was made as an alpha (which has been stressed over and over for years) and is designed to be altered as needed and as experimenting shows changes are needed. Guess what: Satoshi also didn't set the maximum block size as 20Mb, so maybe we shouldn't do that either, since it wasn't like that in the beginning.


Edit: I also want to state that I'm not necessarily advocating for major changes to the way things work. I'm really just curious as to why what seems like the best solution (and should result in the same thing they're going for BUT also bring more usable applications) isn't the target. There's obviously something I'm missing here.

[jl2012]

As per my original question, which nobody has really been able to explain (and has nothing to do with any of your replies since you were caught up trying to avoid reading my statement and just making false inferences) is how this is different than halving the block time/rewards and leaving the maximum block size at 1/2 whatever they're going for (10Mb instead of 20), which would ALSO benefit in giving faster transactions while at the same time fixing the original problem.

It is you now ignoring my reply:

I think it also depends on the block size. I suppose most of those 1min blocks are empty. As the block size approaches the network bandwidth limit, the adverse effect of short block interval will be more obvious.

Those alt-coins with 1 min blocks work fine because most of their blocks are empty (correct me if it's not). If most blocks are full and it's close to the network bandwidth limit, many forks could happen during the propagation and the network will not converge.

And you are actually proposing 2 protocol changes at once: a) shorter block interval and b) more tx/s. Either one of them is already too controversial.

[ranlo]

As per my original question, which nobody has really been able to explain (and has nothing to do with any of your replies since you were caught up trying to avoid reading my statement and just making false inferences) is how this is different than halving the block time/rewards and leaving the maximum block size at 1/2 whatever they're going for (10Mb instead of 20), which would ALSO benefit in giving faster transactions while at the same time fixing the original problem.

It is you now ignoring my reply:

I think it also depends on the block size. I suppose most of those 1min blocks are empty. As the block size approaches the network bandwidth limit, the adverse effect of short block interval will be more obvious.

Those alt-coins with 1 min blocks work fine because most of their blocks are empty (correct me if it's not). If most blocks are full and it's close to the network bandwidth limit, many forks could happen during the propagation and the network will not converge.

And you are actually proposing 2 protocol changes at once: a) shorter block interval and b) more tx/s. Either one of them is already too controversial.

Ah, I saw your post before, but LTC doesn't have a orphan rate, and it's 5m with a lot of users/power backing it, isn't it?

Bringing up controversial changes does make sense, though... it seems like the community really hates change.

[jl2012]

As per my original question, which nobody has really been able to explain (and has nothing to do with any of your replies since you were caught up trying to avoid reading my statement and just making false inferences) is how this is different than halving the block time/rewards and leaving the maximum block size at 1/2 whatever they're going for (10Mb instead of 20), which would ALSO benefit in giving faster transactions while at the same time fixing the original problem.

It is you now ignoring my reply:

I think it also depends on the block size. I suppose most of those 1min blocks are empty. As the block size approaches the network bandwidth limit, the adverse effect of short block interval will be more obvious.

Those alt-coins with 1 min blocks work fine because most of their blocks are empty (correct me if it's not). If most blocks are full and it's close to the network bandwidth limit, many forks could happen during the propagation and the network will not converge.

And you are actually proposing 2 protocol changes at once: a) shorter block interval and b) more tx/s. Either one of them is already too controversial.

Ah, I saw your post before, but LTC doesn't have a orphan rate, and it's 5m with a lot of users/power backing it, isn't it?

Bringing up controversial changes does make sense, though... it seems like the community really hates change.

LTC is 2.5 min, not 5.

Are you sure there are a lot of users backing LTC? Just go to the page http://explorer.litecoin.net/chain/Litecoin and you will see most blocks are nearly empty.

Although I believe we should raise the tx/s, I feel hesitate to decrease the block interval. Having a slightly lower block interval (e.g 2.5 min in LTC) is not particularly helpful. 2.5min is still way too long for buying newspaper on the street, and we all know why it couldn't be 2.5sec. On the other hand, for online shopping, 10min or 2.5min makes no difference because it will always take at least several hours for merchants to deliver.

[ranlo]

I feel hesitate to decrease the block interval. Having a slightly lower block interval (e.g 2.5 min in LTC) is not particularly helpful. 2.5min is still way too long for buying newspaper on the street, and we all know why it couldn't be 2.5sec. On the other hand, for online shopping, 10min or 2.5min makes no difference because it will always take at least several hours for merchants to deliver.

Valid point as well. I've felt for a while now like BTC is going to basically be gold -- a store of value that you don't really use day to day. Sure, you can sell it to get what you want, but people won't accept gold at places like Walmart.

An altcoin would then take its place for day-to-day transactions (much like cash).

[Cubic Earth]

ranlo - check out this thread - "Faster blocks vs bigger blocks" @ https://bitcointalk.org/index.php?topic=673415.msg7626485#msg7626485 if you haven't already.  In my OP there is a link to yet another discussion on this topic.

I still think moving to 5 minutes would be a safe improvement, but the counter argument seems to be that making a faster block interval is not the most efficient way to achieve quick transaction confidence.  By 'efficient' I mean from a human-resource point of view, that any fork takes lots of person-hours in code changes, review, and political discussion.  Although perhaps, as you have suggested, if it was done as part of the attempt to increase the networks base capacity, it would be easier to pull off.

I think I remember Gavin mentioning that the easiest time to pull off such a change would be at a block reward having, which is coming up in just about a year.  The timing could line up nicely!

[ranlo]

ranlo - check out this thread - "Faster blocks vs bigger blocks" @ https://bitcointalk.org/index.php?topic=673415.msg7626485#msg7626485 if you haven't already.  In my OP there is a link to yet another discussion on this topic.

I still think moving to 5 minutes would be a safe improvement, but the counter argument seems to be that making a faster block interval is not the most efficient way to achieve quick transaction confidence.  By 'efficient' I mean from a human-resource point of view, that any fork takes lots of person-hours in code changes, review, and political discussion.  Although perhaps, as you have suggested, if it was done as part of the attempt to increase the networks base capacity, it would be easier to pull off.

I think I remember Gavin mentioning that the easiest time to pull off such a change would be at a block reward having, which is coming up in just about a year.  The timing could line up nicely!

Reading through this now, and it's great to see I'm not the only one that thinks this would be a good solution, .

[virtualx]

ranlo - check out this thread - "Faster blocks vs bigger blocks" @ https://bitcointalk.org/index.php?topic=673415.msg7626485#msg7626485 if you haven't already.  In my OP there is a link to yet another discussion on this topic.

I still think moving to 5 minutes would be a safe improvement, but the counter argument seems to be that making a faster block interval is not the most efficient way to achieve quick transaction confidence.  By 'efficient' I mean from a human-resource point of view, that any fork takes lots of person-hours in code changes, review, and political discussion.  Although perhaps, as you have suggested, if it was done as part of the attempt to increase the networks base capacity, it would be easier to pull off.

I think I remember Gavin mentioning that the easiest time to pull off such a change would be at a block reward having, which is coming up in just about a year.  The timing could line up nicely!

Reading through this now, and it's great to see I'm not the only one that thinks this would be a good solution, .

I think this choice may create some split in the bitcoin community. Some will move to an alt or chain.