Why blocktime decrease instead of blocksize increase is not discussed?

[bathrobehero]

I mean I know the disadvantages of bigger block sizes but I can't think of any disadvantages to having like 5 minute blocks (with obviously half rewards).

Blockchain bloat is not an issue as it's practically all about block sizes anyway.
And of course Bitcoin is quite slow for today's standard so halving the blocktime would help both with that and the maximum TX per seconds as well.
Add 2MB blocks to the mix and the maximum TX per second is already quadrupled without any major effects that I can think of.

It's obviously not even discussed for a good reason but I'm curious what that reason might be.

[1714488742]

1714488742

[1714488742]

1714488742

[1714488742]

1714488742

[1714488742]

1714488742

[1714488742]

1714488742

[1714488742]

1714488742

[jl777]

I mean I know the disadvantages of bigger block sizes but I can't think of any disadvantages to having like 5 minute blocks (with obviously half rewards).

Blockchain bloat is not an issue as it's practically all about block sizes anyway.
And of course Bitcoin is quite slow for today's standard so halving the blocktime would help both with that and the maximum TX per seconds as well.
Add 2MB blocks to the mix and the maximum TX per second is already quadrupled without any major effects that I can think of.

It's obviously not even discussed for a good reason but I'm curious what that reason might be.

its a slippery slope.
first its 5 minutes
then 4, 3, 2, 1

and well before that a lot of hashrate is wasted on orphans and then instead of very rarely seen a block only to see it replaced, it will become much more frequent.

Also, it will bloat the blockhain by 0.01% due to extra overhead of blockheader's 81 bytes
i guess it is 0.008% at 1MB blocks.

James

[jl777]

I mean I know the disadvantages of bigger block sizes but I can't think of any disadvantages to having like 5 minute blocks (with obviously half rewards).

Blockchain bloat is not an issue as it's practically all about block sizes anyway.
And of course Bitcoin is quite slow for today's standard so halving the blocktime would help both with that and the maximum TX per seconds as well.
Add 2MB blocks to the mix and the maximum TX per second is already quadrupled without any major effects that I can think of.

It's obviously not even discussed for a good reason but I'm curious what that reason might be.

Actually the real reason is that there is an active behind the scenes campaign from the avian lobby:

https://en.wikipedia.org/wiki/IP_over_Avian_Carriers

They have spent a lot of money on higher reliability and faster packet times. At the 10 minute blocktime, they have a chance. Dont take that away from them

James

[bathrobehero]

I don't think we ever have to go below 5 minutes. It's a great middle ground I feel. It doesn't have the disadvantage that pools require superb internet connection (like 2+ MB block sizes) and it's also virtually immune to orphans.
I also think transaction fees should be higher to prevent spam but most people hate that idea.

Blockchain bloat I think is a non-issue; internet bandwidth is increasing much faster and even SSD storage prices decrease in a much faster rate than the blocksize would increase. It might be even true even if the TX per second would be unlimited.

The blockchain is like 56 GB or so today and while that seems large, it really isn't. The smallest HDD you can buy is multiple times bigger than that. You can even fit the blockchain on SD cards/pen drives.

Edit: Ipoac  

[jl777]

I don't think we ever have to go below 5 minutes. It's a great middle ground I feel. It doesn't have the disadvantage that pools require superb internet connection (like 2+ MB block sizes) and it's also virtually immune to orphans.
I also think transaction fees should be higher to prevent spam but most people hate that idea.

Blockchain bloat I think is a non-issue; internet bandwidth is increasing much faster and even SSD storage prices decrease in a much faster rate than the blocksize would increase. It might be even true even if the TX per second would be unlimited.

The blockchain is like 56 GB or so today and while that seems large, it really isn't. The smallest HDD you can buy is multiple times bigger than that. You can even fit the blockchain on SD cards/pen drives.

Edit: Ipoac  

When you can do a full blockchain sync in 30 minutes, there is no bloat problem.

I think a much bigger issue is the lack of standard for iporc. If pigeons are compared to rats with wings, then the rat lobby demands representation for ip packets encoded into bits of cheese. The technical challenges are immense, primarily due to consumption of the cheese prior to proper checksums are verified. However, I am assured that the rodents in general and rats in particular are confident that they will be able to create a more reliable packet routing than their flying counterparts

James

[smooth]

It has been discussed. There are threads here about it.

Does not really help with anything. The shorter block time has a comparable effect to larger blocks in terms of relay latency sensitivity. The bandwidth and storage requirements are unchanged.

There is an advantage in terms of faster confirmations, but a disadvantage in terms of longer header chains for SPV clients.

So overall, maybe worth considering, but overall kind of pointless.

[jl777]

It has been discussed. There are threads here about it.

Does not really help with anything. The shorter block time has a comparable effect to larger blocks in terms of relay latency sensitivity. The bandwidth and storage requirements are unchanged.

There is an advantage in terms of faster confirmations, but a disadvantage in terms of longer header chains for SPV clients.

So overall, maybe worth considering, but overall kind of pointless.

doubling tx capacity is pointless?
supposedly dealing with the massive 1MB blocks are the issue that creates resistance to increasing the blocksize. Establishing a txfee market has nothing to do with this resistance. The miners absolutely dont want to make more money by forcing txfees up.

5 minute blocks of 1MB doubles the tx capacity and delays the txfee market that the miners say they dont want, since the block reward is all they care about. Whats a few satoshis worth of txfees anyway?

[jl777]

The coming halving of the blockward, also has absolutely no effect on making the miners wanting to get more txfees.

After all, all businesses love it when their revenues just get cut in half, instantly. When all their costs stay the same, so why would miners do anything to boost their txfee side of the income? With a few thousand tx per block, if the market rate for txfee is pushed to 0.005, then all of a sudden, it isnt just a few satoshis anymore

Follow the money. Usually the answers are there

James

[smooth]

It has been discussed. There are threads here about it.

Does not really help with anything. The shorter block time has a comparable effect to larger blocks in terms of relay latency sensitivity. The bandwidth and storage requirements are unchanged.

There is an advantage in terms of faster confirmations, but a disadvantage in terms of longer header chains for SPV clients.

So overall, maybe worth considering, but overall kind of pointless.

doubling tx capacity is pointless?

What I mean is halving the block time vs. doubling the block size is largely pointless.

supposedly dealing with the massive 1MB blocks are the issue that creates resistance to increasing the blocksize. Establishing a txfee market has nothing to do with this resistance. The miners absolutely dont want to make more money by forcing txfees up.

5 minute blocks of 1MB doubles the tx capacity and delays the txfee market that the miners say they dont want, since the block reward is all they care about. Whats a few satoshis worth of txfees anyway?

I don't think you will find it any easier to double the block rate than double the block size. Just my opinion.

[jl777]

It has been discussed. There are threads here about it.

Does not really help with anything. The shorter block time has a comparable effect to larger blocks in terms of relay latency sensitivity. The bandwidth and storage requirements are unchanged.

There is an advantage in terms of faster confirmations, but a disadvantage in terms of longer header chains for SPV clients.

So overall, maybe worth considering, but overall kind of pointless.

doubling tx capacity is pointless?

What I mean is halving the block time vs. doubling the block size is largely pointless.

supposedly dealing with the massive 1MB blocks are the issue that creates resistance to increasing the blocksize. Establishing a txfee market has nothing to do with this resistance. The miners absolutely dont want to make more money by forcing txfees up.

5 minute blocks of 1MB doubles the tx capacity and delays the txfee market that the miners say they dont want, since the block reward is all they care about. Whats a few satoshis worth of txfees anyway?

I don't think you will find it any easier to double the block rate than double the block size. Just my opinion.

Yes, the problem is that the people with the power to decide are incentivized to create a smaller supply of available tx, and cutting the time in half only eliminates the "bandwidth is so bad here we use pigeons and 1 MB is all that fits in the tiny pouches" excuse. ipoac to the rescue

so it seems we are headed for significant txfee inflation

[findftp]

I don't think we ever have to go below 5 minutes. It's a great middle ground I feel.

History is filled with stories of people with a certain 'feeling'.

And besides, you should only give a patient some adrenaline when it's unresponsive and dead anyway.
Bitcoin's heartbeat of 10 minutes is ok and doesn't need crystal meth while it's still alive.

[bathrobehero]

I don't think we ever have to go below 5 minutes. It's a great middle ground I feel.

History is filled with stories of people with a certain 'feeling'.

And besides, you should only give a patient some adrenaline when it's unresponsive and dead anyway.
Bitcoin's heartbeat of 10 minutes is ok and doesn't need crystal meth while it's still alive.

Oh I agree that Bitcoin is doing just fine and I don't think the transaction rate limit is much of an issue or that it will be in the near future because of TX fees but i also know that many many people think that it's a grave issue so I entertained the idea (even though it's clear we won't reach clear consensus anytime soon if ever).

I said I feel and not I'm convinced because that's what I think is reasonable with the small knowledge I have. But I'm open to change my opinion.

[jl777]

I don't think we ever have to go below 5 minutes. It's a great middle ground I feel.

History is filled with stories of people with a certain 'feeling'.

And besides, you should only give a patient some adrenaline when it's unresponsive and dead anyway.
Bitcoin's heartbeat of 10 minutes is ok and doesn't need crystal meth while it's still alive.

Oh I agree that Bitcoin is doing just fine and I don't think the transaction rate limit is much of an issue or that it will be in the near future because of TX fees but i also know that many many people think that it's a grave issue so I entertained the idea (even though it's clear we won't reach clear consensus anytime soon if ever).

I said I feel and not I'm convinced because that's what I think is reasonable with the small knowledge I have. But I'm open to change my opinion.

it is not a technical issue. I dont even think any code would need to be changed, just some constants, but it would be a hardfork, so it is an economic/politics issue that is determined in BTC via hashrate (aka money)

[Jet Cash]

I've posted several threads about this. It looks as if the optimum would be a 3 minute block interval with a 5 bitcoin reward for miners. The change to be implemented instead of the halving.

[jl777]

I've posted several threads about this. It looks as if the optimum would be a 3 minute block interval with a 5 bitcoin reward for miners. The change to be implemented instead of the halving.

Now you just need to convince the miners that they are ok with 50% revenue cut, even as hashrate increases and no need to boost fees to 0.01 BTC per tx. As I saw in a movie once: "These are not the txfees you are looking for"

James

[gmaxwell]

This was asked, and answered in another recent thread: https://bitcointalk.org/index.php?topic=1378112.msg14031820#msg14031820

[jl777]

This was asked, and answered in another recent thread: https://bitcointalk.org/index.php?topic=1378112.msg14031820#msg14031820

I didnt understand the answer of why a 5 or 6 minute block would be bad, other than a very small increase in orphan rate and delaying any txfee auction market for a while

[smooth]

This was asked, and answered in another recent thread: https://bitcointalk.org/index.php?topic=1378112.msg14031820#msg14031820

I didnt understand the answer of why a 5 or 6 minute block would be bad, other than a very small increase in orphan rate and delaying any txfee auction market for a while

The answer was that the asymmetry is such that making the time too short (given network parameters, which are not really measurable and not stable) is much, much worse than making it too long.

I continue to assert that reducing the time should not be confused with increasing capacity. A block time reduction by a factor of two, all else being equal, would also be accompanied by a reduction in the block size by a factor of two.

[jl777]

This was asked, and answered in another recent thread: https://bitcointalk.org/index.php?topic=1378112.msg14031820#msg14031820

I didnt understand the answer of why a 5 or 6 minute block would be bad, other than a very small increase in orphan rate and delaying any txfee auction market for a while

The answer was that the asymmetry is such that making the time too short (given network parameters, which are not really measurable and not stable) is much, much worse than making it too long.

I continue to assert that reducing the time should not be confused with increasing capacity. A block time reduction by a factor of two, all else being equal, would also be accompanied by a reduction in the block size by a factor of two.

Looking at the data, it seems the negatives of 5 minute block are pretty small and that would give 2MB of blockspace per 10 minutes. So if we assume the error rate difference between 5 and 10 minutes is small enough to being considered equal enough, then having 2 1MB blocks in a 10 minute period sure seems like double the tx capacity per 10 minutes.

Not sure why the blocksize is reduced at half the time, that would defeat the purpose.

given the assumption that 5 and 10 minutes are equal enough, then why would the blocksize need to be cut in half? We can also assume that 1MB per 5 minutes is not any problem for the nodes' bandwidth and wouldnt increase the error rates appreciably.

What error rate at 5 minutes requires cutting the size in half. If there is no need to cut the size in half, then how is it not a doubling in capacity?

Confused...

James

[smooth]

This was asked, and answered in another recent thread: https://bitcointalk.org/index.php?topic=1378112.msg14031820#msg14031820

I didnt understand the answer of why a 5 or 6 minute block would be bad, other than a very small increase in orphan rate and delaying any txfee auction market for a while

The answer was that the asymmetry is such that making the time too short (given network parameters, which are not really measurable and not stable) is much, much worse than making it too long.

I continue to assert that reducing the time should not be confused with increasing capacity. A block time reduction by a factor of two, all else being equal, would also be accompanied by a reduction in the block size by a factor of two.

Looking at the data, it seems the negatives of 5 minute block are pretty small and that would give 2MB of blockspace per 10 minutes. So if we assume the error rate difference between 5 and 10 minutes is small enough to being considered equal enough, then having 2 1MB blocks in a 10 minute period sure seems like double the tx capacity per 10 minutes.

Not sure why the blocksize is reduced at half the time, that would defeat the purpose.

given the assumption that 5 and 10 minutes are equal enough, then why would the blocksize need to be cut in half? We can also assume that 1MB per 5 minutes is not any problem for the nodes' bandwidth and wouldnt increase the error rates appreciably.

What error rate at 5 minutes requires cutting the size in half. If there is no need to cut the size in half, then how is it not a doubling in capacity?

Confused...

James

To answer your last question, if you increase the capacity then you are doubling the bandwidth and storage requirements. If you want to do that, and you have buy-in to do that from the relevant stakeholders, then you might as well just increase the block size.

What you are are ignoring in "the data" is this:

The scaling of this depends on factors like network hashpower distribution and latencies which are hard to measure and which change.

Since 5 minutes is "reasonably close" to the inflection point on the graph where being too low becomes much worse and being too high becomes only slightly worse, it seems quite reasonable in light of the above quote to err on the side of (possibly) too high and just implement a 2x capacity increase with an increase in block size rather than a reduction in block time.

In all honesty, and lacking in hard data, I do believe that 5 minutes would be fine, but what's the point? Going well below 5 minutes would most likely not be fine, so that limits any available capacity increase via that method to roughly 2x. Increasing the block size has no such limit.