Pages:
Author

Topic: Why blocktime decrease instead of blocksize increase is not discussed? (Read 1818 times)

legendary
Activity: 2814
Merit: 2472
https://JetCash.com
I would suggest you all convert your BTC to nanosecond block time cryptocoins.

Oh wait...


the data we were given shows that the error rates for 5 minutes is very close to 10 minutes and I think it was several years old data?, if so, the safe blocktime would be even faster, probably 3 minutes range. Does LTC have massive amounts of orphans?

James

Thank you - that is what I've been suggesting on this board for some time now. Couple it with a 5 Bitcoin mining reward, and introduce it at the next halving. That seems to be the easiest option.
legendary
Activity: 1176
Merit: 1134
I would suggest you all convert your BTC to nanosecond block time cryptocoins.

Oh wait...


the data we were given shows that the error rates for 5 minutes is very close to 10 minutes and I think it was several years old data?, if so, the safe blocktime would be even faster, probably 3 minutes range. Does LTC have massive amounts of orphans?

James
legendary
Activity: 1176
Merit: 1134
Supposedly, changing the block time is a more complex and bigger change than changing the block size.

I still think it's worth it to have faster block time. 10 minutes is a cruel joke, just read about the many complaints that are happening in the real world:
https://www.reddit.com/r/Bitcoin/comments/48m9xq/average_confirmation_times/
Anything is more complex than changing the blocksize, since that's just changing a #define, right?

If anybody uses code complexity to reject faster blocktime, they are not using a valid technical objection. Now maybe it is possible to be more backward/forward compatible with larger blocksize but we are talking about a hardfork change and in that context changing blocktime falls into the really easy to do category
legendary
Activity: 1022
Merit: 1008
Delusional crypto obsessionist
I would suggest you all convert your BTC to nanosecond block time cryptocoins.

Oh wait...

legendary
Activity: 2002
Merit: 1051
ICO? Not even once.
10 minutes I also think is a joke for today's standards.

And it's clear that pools are strongly against having to process big chunks of data at once regardless of block frequency.
Twice the frequency would cut the amount of data that would have to be processed at a time.

Reducing transaction sizes would probably be the best solution but I'd imagine that would be the most complicated option.


The more I read about the topic the more I feel that there's way too much politics and bickering going on to reach consensus anytime soon.
legendary
Activity: 1806
Merit: 1003
Supposedly, changing the block time is a more complex and bigger change than changing the block size.

I still think it's worth it to have faster block time. 10 minutes is a cruel joke, just read about the many complaints that are happening in the real world:
https://www.reddit.com/r/Bitcoin/comments/48m9xq/average_confirmation_times/
legendary
Activity: 1176
Merit: 1134
This was asked, and answered in another recent thread: https://bitcointalksearch.org/topic/m.14031820
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.


thanks. mostly makes sense, but the last part sounds like doubling via 5 minutes is a onetime gain and we will have to increase blocksize at some point anyway, so no sense in doubling via 5 minutes.

using that logic, it leaves a "free" doubling unused and to me that seems a waste. Also 5 minutes would offer the advantage of half the latency, which many would view as a positive. so it is not just a lack of negative, but a presence of positive

James

P.S. There are ways to increase capacity 10x or more without increasing blocksize or even reducing the blocktime, but would require more significant changes in the core, but doing both would boost the overall capacity and I thought more capacity was better than less
legendary
Activity: 2968
Merit: 1198
This was asked, and answered in another recent thread: https://bitcointalksearch.org/topic/m.14031820
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.

legendary
Activity: 1176
Merit: 1134
This was asked, and answered in another recent thread: https://bitcointalksearch.org/topic/m.14031820
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
legendary
Activity: 2968
Merit: 1198
This was asked, and answered in another recent thread: https://bitcointalksearch.org/topic/m.14031820
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.
legendary
Activity: 1176
Merit: 1134
This was asked, and answered in another recent thread: https://bitcointalksearch.org/topic/m.14031820
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
staff
Activity: 4284
Merit: 8808
This was asked, and answered in another recent thread: https://bitcointalksearch.org/topic/m.14031820
legendary
Activity: 1176
Merit: 1134
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. Smiley
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
legendary
Activity: 2814
Merit: 2472
https://JetCash.com
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. Smiley
legendary
Activity: 1176
Merit: 1134
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)
legendary
Activity: 2002
Merit: 1051
ICO? Not even once.
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.
legendary
Activity: 1022
Merit: 1008
Delusional crypto obsessionist
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.
legendary
Activity: 1176
Merit: 1134
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.

Quote
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
legendary
Activity: 2968
Merit: 1198
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.

Quote
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.
legendary
Activity: 1176
Merit: 1134
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
Pages:
Jump to: