Reducing block time vs Increasing block size

[tbonetony]

Hi devs,

Instead of a direct on-chain scaling to bump up to 2, 4, or 8MB, etc. How  difficult is it to reduce avg block time to 5mins from 10mins while maintaining 1mb block size?

I have not had the talent to go through all btc codes myself and this is not a political argument question. I just want to understand the technical pros and cons of such an approach to the scaling challenge we face as of today.

Thanks for your contribution to the discussion.

EDIT:
the feasibility portion has been well covered by the great answers below so I changed the title a bit to reflect what is being discussed at the latest.

[1714770523]

1714770523

[TierNolan]

Instead of a direct on-chain scaling to bump up to 2, 4, or 8MB, etc. How  difficult is it to reduce avg block time to 5mins from 10mins while maintaining 1mb block size?

Changing the block time is a hard fork, so it is the same difficulty as increasing the block size.  Both "only" require changing a parameter in the code.

In practice, these changes always require other associated changes.  

Reducing the block time would mean difficulty updates happen every week instead of every 2 weeks.  You could make it so that they happen every 2 weeks by doubling the number of blocks per adjustment.

The minting fee would also need to be considered.  If you don't change it then miners get twice as much per day for mining but it halves once every 2 years instead of once every 4 years.

Making any of these changes could cause unforeseen problems.  

The problem with increasing the block size is not coding, there is politics because there are different viewpoints on the risks.  Not everyone agrees that the risks are worth it or what are the most important risks.

[Edit]
Typo fix on the subsidy halving time

[cr1776]

Instead of a direct on-chain scaling to bump up to 2, 4, or 8MB, etc. How  difficult is it to reduce avg block time to 5mins from 10mins while maintaining 1mb block size?

Changing the block time is a hard fork, so it is the same difficulty as increasing the block size.  Both "only" require changing a parameter in the code.

In practice, these changes always require other associated changes.  

Reducing the block time would mean difficulty updates happen every week instead of every 2 weeks.  You could make it so that they happen every 2 weeks by doubling the number of blocks per adjustment.

The minting fee would also need to be considered.  If you don't change it then miners get twice as much per day for mining but it halves once a year instead of once every 2 years.

Making any of these changes could cause unforeseen problems.  

The problem with increasing the block size is not coding, there is politics because there are different viewpoints on the risks.  Not everyone agrees that the risks are worth it or what are the most important risks.

One correction (which I am sure was just a typo):  Currently it halves every 4 years and this would make it halve every 2 years.

Likewise, it would change the last bitcoin minding date from somewhere around 2140 to perhaps half the remaining time.  Cutting the block time in half is purely a political question, and the probability of it happening on the main chain is essentially zero.

[bibiqua]

[Changing the block time is a hard fork [...] the most important risks.

Thank you for the explanation. I was wondering as well, now I understand a lot more.

[tbonetony]

Thanks both TierNolan and cr1776 for your excellent insights.

[Chikako]

With this we can see tachnically speaking, is not difficult to change any already written parameter - to change the code value of it, when talking about crypto-currencies the difficulty only comes when adding non-existant features. You can modify any of those features here https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp

But you can't just alter some value in the code and get with it, consensus should be reached to modify even the minimal thing on Bitcoin as you'll modify the code in thousands or millions of user computers, it's decentralized.

[aliashraf]

Hi devs,

Instead of a direct on-chain scaling to bump up to 2, 4, or 8MB, etc. How  difficult is it to reduce avg block time to 5mins from 10mins while maintaining 1mb block size?

I have not had the talent to go through all btc codes myself and this is not a political argument question. I just want to understand the technical pros and cons of such an approach to the scaling challenge we face as of today.

Thanks for your contribution to the discussion.

Obviously, it is not a technical question as any junior programmer can do the job in less than an hour ...

But please! Look at this post!
The poor OP is just apologizing for her simple question! Why? It is quiet  a shame, I think. It says everything about the atmosphere in bitcoin camp ... innovation and courage is dead here, imagination is dead, it is not what bitcoin meant to be ... wake up people, Ethereum is there , Ripple is there the former a dynamic, decentralized sphere and the later a centralized, corporate oriented alternative, where is bitcoin?

[kokojie]

Reducing block time is the much superior solution vs increasing block size, but Bitcoin is too stubborn to adopt the obvious superior solutions of course.

[aliashraf]

Reducing block time is the much superior solution vs increasing block size, but Bitcoin is too stubborn to adopt the obvious superior solutions of course.

Absolutely! And better than SW too. I hate SegWit , being allowed to or not, I really hate this 'brilliant' trick for my own reasons, but playing with block time? A piece of cake, easy to cook, easy to digest ...

Speaking of hate, I hate ASICs and transaction fees as well and now that we are dreaming, let's do it perfectly.

Imagine a new coin, name it fast btc for the moment, it uses (and keeps using) the exact code, guys in bitcoin core, generously publish (I'm unbelievably lazy), except for some minor tweaks plus a very few lines of code change:

1- Of course block time parameter ... mmm ... let's put it 128 seconds. (enough these days to avoid uncle chains)
Note: block time is 'halved' every 10 years i.e. 2,460,000 blocks. (we expect better and faster network propagations with advances in communication devices and protocols) and it won't go faster than 16 seconds  ever (reached after after 30 years).

2- Difficulty adjustment?  ... mmm .... 2700 is good. Once every four days ...  sounds reasonable.

3- Blocksize?  Ask their majesty (bitcoin core devs) .

4- SegWit? Ask them again.

5- Block reward? Let's start with 256 fbtc. (we should supply enough coins in the beginning, you know, it is to be the really fast 'decentralized electronic cash' for daily payment,  people will need a lot of it!

6- Halving ... mmm ... put it 5 years, every  1,230,000 blocks. and it is 'double halving' for 2nd, 4th and 6th halvings (taking care of  block time halvings) and never will be cut down to less than 1 fbtc (there will be no 7th halving ever).
The reward sequence(fbtc):       256, 128, 32, 16, 4, 2, 1 , 1, 1, ...
The block time sequence(seconds): 128, 128, 64, 64, 32, 32, 16, 16, 16, .... (Both started from day zero, with a ticker of 5 years period).

This way, cash supply after 30 years is constantly fixed on 1 fbtc with a block time of 16 seconds. (Oops! Just forgot to say that I prefer cash compared to antiques).

Easy till here, some parameter tweakings and a very few lines of code. But I'm not satisfied yet. We have to put ASICs out ... well it is not that easy , changing the verification and hashing algorithm,  but you know what? I'm not that kind of a lazy person who gives up, I have found a way to do this "somewhat" easily and without cutting the ties with valuable assets like bitcoin software and its developers (I love them, you believe me, don't you?)

Enough for the moment, I will come back to this asap.

[aliashraf]

Now lets go to the main hack:

1- Hashing:
 1-1- Suppose we have a 1GB string  (256 * 2^24) name it the Original Seed or simply OS), for every 200 blocks: consider  the least significant 128
        bits of the calculated hash of the previous 100th  block as a mask, now do a 'xor' on the OS repeatedly for every 16 bytes. The resulting 1GB
        string is the Current Seed (CS) and remains valid for the next  200 blocks. Obviously, miners have a window of 100 blocks  to recalculate the
        next (CS).

  1-2- After adding nounce and calculating SHA256 hash of the intended block header (name it Raw Hash or RH) and before checking difficulty,
         miners MUST add a special 256 bit string(name it Hidden Nounce, HN)  to the end of the block header under consideration. NH is calculated
         this way: The least significant 24 bits of the RH is treated as the address of a 256 bytes segment on CS,  do 'xor' on 32 byte
         chunks of this segment beginning with the first 16 bytes and RH then use the result with the next 16 bytes to do another 'xor' and son on.
         The last result is the desired hidden nounce, NH.
 1-3- After concatenating NH, the resulting string (block header+NH) goes through another SHA256 hash and the result will be checked against the
        difficulty.

2- Verification : Obviously, the block under consideration walks the hashing algorithm just once and can be decided in accordance with the protocol.


As one can observe, we have added 2 simple steps one for maintaining the CS and the other for using it, the former being practically a background job and the later a repetitive one with a 1 GB of memory footprint. Good bye ASIC. Got to the hell!

The point is all of these (my previous post tweaks included) do not impose any radical code base rewrite. And what we got? A totally brand new coin with its rules being radically far from bitcoin and even its hashing algorithm shifted to an ASIC resistant alternative, isn't it awesome?


As I said, our Fbtc baby may fail but not because of insecure immature code base or lack of dev support, it can enjoy both from bitcoin campus,
and its hypothetical failure will not be a result of its lack of feature compared to bitcoin, it is far more decentralized and many times faster than
bitcoin, it is just about determination and enthusiasm.

And the last comment: This proposal reveals one simple fact about bitcoin: It is a great piece of code, with almost infinite possibilities waiting there to be discovered. How and why this code base has become a rigid, untouchable thing with little if not zero evolution, it is up to people who are in charge or think so about their position. Sure, I  understand the current situation in which we are facing a multi billion dollars industry but, what the heck, a real genius should have something in her/his head for such a situation, or we are dealing with ordinary programmers who have over estimated their talents.

EDIT:
I have to apologize from guys who have read this post in first few hours and apply following patch:

Regarding step 1-1 :
    A) We use CS instead of OS and we should use an algorithm like the one in step 1-3 : take the first 16 bytes of CS, 'xor' it with RH, use the result as the new operand for the next 16 bytes and so on.
   B) We add RH to the head of the CS and eliminate last 32 bytes from it, each time it comes to recalculating CS (every 200 blocks).

With this patch we keep ASIC out of the game, As the 1G array is evolving in a quick, unpredictable and deterministic way.

[tbonetony]

Reducing block time is the much superior solution vs increasing block size, but Bitcoin is too stubborn to adopt the obvious superior solutions of course.

Absolutely! And better than SW too. I hate SegWit , being allowed to or not, I really hate this 'brilliant' trick for my own reasons, but playing with block time? A piece of cake, easy to cook, easy to digest ...

Speaking of hate, I hate ASICs and transaction fees as well and now that we are dreaming, let's do it perfectly.

Imagine a new coin, name it fast btc for the moment, it uses (and keeps using) the exact code, guys in bitcoin core, generously publish (I'm unbelievably lazy), except for some minor tweaks plus a very few lines of code change:

1- Of course block time parameter ... mmm ... let's put it 128 seconds. (enough these days to avoid uncle chains)
Note: block time is 'halved' every 10 years i.e. 2,460,000 blocks. (we expect better and faster network propagations with advances in communication devices and protocols) and it won't go faster than 16 seconds  ever (reached after after 30 years).

2- Difficulty adjustment?  ... mmm .... 2700 is good. Once every four days ...  sounds reasonable.

3- Blocksize?  Ask their majesty (bitcoin core devs) .

4- SegWit? Ask them again.

5- Block reward? Let's start with 256 fbtc. (we should supply enough coins in the beginning, you know, it is to be the really fast 'decentralized electronic cash' for daily payment,  people will need a lot of it!

6- Halving ... mmm ... put it 5 years, every  1,230,000 blocks. and it is 'double halving' for 2nd, 4th and 6th halvings (taking care of  block time halvings) and never will be cut down to less than 1 fbtc (there will be no 7th halving ever).
The reward sequence(fbtc):       256, 128, 32, 16, 4, 2, 1 , 1, 1, ...
The block time sequence(seconds): 128, 128, 64, 64, 32, 32, 16, 16, 16, .... (Both started from day zero, with a ticker of 5 years period).

This way, cash supply after 30 years is constantly fixed on 1 fbtc with a block time of 16 seconds. (Oops! Just forgot to say that I prefer cash compared to antiques).

Easy till here, some parameter tweakings and a very few lines of code. But I'm not satisfied yet. We have to put ASICs out ... well it is not that easy , changing the verification and hashing algorithm,  but you know what? I'm not that kind of a lazy person who gives up, I have found a way to do this "somewhat" easily and without cutting the ties with valuable assets like bitcoin software and its developers (I love them, you believe me, don't you?)

Enough for the moment, I will come back to this asap.

I, too, am a sw dev for quite some time so I can smell a lot of the typical dev mentalities around. troll or not, i enjoy reading your "hacks" so far XD

[DooMAD]

Reducing block time is the much superior solution vs increasing block size, but Bitcoin is too stubborn to adopt the obvious superior solutions of course.

With the obvious exception of average confirmation time being slightly more convenient for users, it's effectively no different to an increase to the blocksize in terms of resource usage.  If, for example, you halve the time it takes to append a block, but don't halve the blocksize as well, you're potentially doubling the rate at which the total size of the blockchain grows.  Equally as resource intensive with respect to bandwidth and storage as simply increasing the blocksize (or fractionally more intensive with a greater number of block headers taking up tiny amounts of space).

[tbonetony]

Reducing block time is the much superior solution vs increasing block size, but Bitcoin is too stubborn to adopt the obvious superior solutions of course.

With the obvious exception of average confirmation time being slightly more convenient for users, it's effectively no different to an increase to the blocksize in terms of resource usage.  If, for example, you halve the time it takes to append a block, but don't halve the blocksize as well, you're potentially doubling the rate at which the total size of the blockchain grows.  Equally as resource intensive with respect to bandwidth and storage as simply increasing the blocksize (or fractionally more intensive with a greater number of block headers taking up tiny amounts of space).

While I acknowledge your analysis I would not agree with your conclusion.

Reducing block time will increase responsiveness. Bitcoin is a revolution today with what it brings to us. Average of 10 minutes to send remittances around the globe is fascinating today but 5 years down the road, this likely would not be so appealing to users in the current ever-accelerating world. So I don't see how this gain would merely be "slightly more convenient".

Now speaking on the payload overhead. Bitcoin protocol today is already highly efficient. As you have said it would be "tiny amounts of space". this could be negligible and therefore I would see it as a weak argument.

A counter example would be to propose 6M block on an average of 60 minutes. We could save 5x more payload but such responsiveness would appear silly.

IMO a shorter block time would also reduce miner rewards variance (as rewards are distributed more often), thus encouraging more decentralization in mining. Smaller pools today would be able to earn less volatile revenue and therefore more likely to afford PPS rather than PPLNS. When more pools are available in PPS, miners will be less likely to hop only on the mega pools, instead more miners could start reflecting what pools they truly support or disapprove due to less emphasis on earning differentiation.

[aliashraf]

Reducing block time is the much superior solution vs increasing block size, but Bitcoin is too stubborn to adopt the obvious superior solutions of course.

With the obvious exception of average confirmation time being slightly more convenient for users, it's effectively no different to an increase to the blocksize in terms of resource usage.  If, for example, you halve the time it takes to append a block, but don't halve the blocksize as well, you're potentially doubling the rate at which the total size of the blockchain grows.  Equally as resource intensive with respect to bandwidth and storage as simply increasing the blocksize (or fractionally more intensive with a greater number of block headers taking up tiny amounts of space).

While I acknowledge your analysis I would not agree with your conclusion.

Reducing block time will increase responsiveness. Bitcoin is a revolution today with what it brings to us. Average of 10 minutes to send remittances around the globe is fascinating today but 5 years down the road, this likely would not be so appealing to users in the current ever-accelerating world. So I don't see how this gain would merely be "slightly more convenient".

Now speaking on the payload overhead. Bitcoin protocol today is already highly efficient. As you have said it would be "tiny amounts of space". this could be negligible and therefore I would see it as a weak argument.

A counter example would be to propose 6M block on an average of 60 minutes. We could save 5x more payload but such responsiveness would appear silly.

IMO a shorter block time would also reduce miner rewards variance (as rewards are distributed more often), thus encouraging more decentralization in mining. Smaller pools today would be able to earn less volatile revenue and therefore more likely to afford PPS rather than PPLNS. When more pools are available in PPS, miners will be less likely to hop only on the mega pools, instead more miners could start reflecting what pools they truly support or disapprove due to less emphasis on earning differentiation.

Brilliant! I am just wondering: Why in the hell didn't we take it into consideration much earlier? I mean look at this, just read and re-read it:

IMO a shorter block time would also reduce miner rewards variance (as rewards are distributed more often), thus encouraging more decentralization in mining. Smaller pools today would be able to earn less volatile revenue and therefore more likely to afford PPS rather than PPLNS.

Unbelievably damn right! And you say you have contributed to SW development! With all due respects, you have been wasting your time, you are better in strategic understanding of the whole thing rather than coding programming tricks like that.

A small objection to your reply though:

First of all I think we don't need a more 5 years to realise the 10 minute block time being too much. It is almost 9 years, and we all know Satoshi being a more than conservative in issues like this( honestly I think it has been too much from the first beginning)

And ... I have fixed the problem of communications and networking technology improvements impact on the propagation speed of remittances, in my proposal. I have proposed a 10 year halving of block time up to 16 seconds (beginning from 128 seconds it means 3 halvings)

[aliashraf]

With this we can see tachnically speaking, is not difficult to change any already written parameter - to change the code value of it, when talking about crypto-currencies the difficulty only comes when adding non-existant features. You can modify any of those features here https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp

But you can't just alter some value in the code and get with it, consensus should be reached to modify even the minimal thing on Bitcoin as you'll modify the code in thousands or millions of user computers, it's decentralized.

Regarding your comment about consensus ... No, we can simply get rid of bitcoin, we should, it is inevitable as I am going to show ...

From the first beginning, bitcoin wasn't meant to be some 'dominant cryptocurrency' (I doubt there can be ever such a monster) it was , and it is yet, an experiment.

Besides ordinary clueless people, two groups  do not understand the word, experiment, business men and women who hang around tech shows  waiting for on opportunity to grab, and mid-level technologists who fall in love with the current state of 'any tech product that works'. These two camps are the true forces behind everything happening in the last couple of years in the bitcoin ecosystem.

And guess what? There exist no other camps! Bitcoin is overtaken, it is no more a place for any kind of improvement revolutionary or incremental, it can't be a 'decentralized cash system' and won't become anything near that, never. It is and will be digital gold, forget about money.

I mean ... are you kidding? A payment system facing a network congestion with an average of 3 transactions per second?

Yet there is a very crucial point that is exceptional about the bitcoin experiment and its so called 'success', it deserves a credit IMO:
One should distinguish between bitcoin blockchain, the real working chain of blocks replicated thousands times around the globe and under careful maintenance of its miners, and bitcoin code base, Satoshi's legacy, although being claimed by "bitcoin core" but definitely open source and public domain. The later is the one that  deserves much of the credit and has the right to live and improve, no matter which chain is using it and whether the chain operators reach consensus about its evolution or not.

What I hate about much of the altcoins is their being reckless about the Satoshi code, I prefer incremental evolution and enhancements in bitcoin (and literally any good piece of) code. So, I will soon come with a complete proposal fora brand new coin, loyal to the bitcoin code base, indifferent about the bitcoin block chain, having block time re-adjustment in its heart and ASIC resistance in its brain, both with minor improvements in the mainstream bitcoin code base.

[kokojie]

Reducing block time is the much superior solution vs increasing block size, but Bitcoin is too stubborn to adopt the obvious superior solutions of course.

With the obvious exception of average confirmation time being slightly more convenient for users, it's effectively no different to an increase to the blocksize in terms of resource usage.  If, for example, you halve the time it takes to append a block, but don't halve the blocksize as well, you're potentially doubling the rate at which the total size of the blockchain grows.  Equally as resource intensive with respect to bandwidth and storage as simply increasing the blocksize (or fractionally more intensive with a greater number of block headers taking up tiny amounts of space).

While I acknowledge your analysis I would not agree with your conclusion.

Reducing block time will increase responsiveness. Bitcoin is a revolution today with what it brings to us. Average of 10 minutes to send remittances around the globe is fascinating today but 5 years down the road, this likely would not be so appealing to users in the current ever-accelerating world. So I don't see how this gain would merely be "slightly more convenient".

Now speaking on the payload overhead. Bitcoin protocol today is already highly efficient. As you have said it would be "tiny amounts of space". this could be negligible and therefore I would see it as a weak argument.

A counter example would be to propose 6M block on an average of 60 minutes. We could save 5x more payload but such responsiveness would appear silly.

IMO a shorter block time would also reduce miner rewards variance (as rewards are distributed more often), thus encouraging more decentralization in mining. Smaller pools today would be able to earn less volatile revenue and therefore more likely to afford PPS rather than PPLNS. When more pools are available in PPS, miners will be less likely to hop only on the mega pools, instead more miners could start reflecting what pools they truly support or disapprove due to less emphasis on earning differentiation.

Yep, it's all good reasons, except it will be blocked by the big PoW mining farms, just like they blocked segwit. The biggest issue right now in Bitcoin is not block time or block size, it's the centralization of PoW mining. As long as this centralization exists, progress can be blocked as they see fit.

[aliashraf]

...
Yep, it's all good reasons, except it will be blocked by the big PoW mining farms, just like they blocked segwit. The biggest issue right now in Bitcoin is not block time or block size, it's the centralization of PoW mining. As long as this centralization exists, progress can be blocked as they see fit.

Seriously?! Then why should bother each other, reasoning about anything?

IMO, the protocol and the code that implements it is far more important than the block chain (data) generated through the last few years, named bitcoin. I don't have faith in this coin, as it has failed almost all of its primary goals and it can't just improve. A huge inertia, billions of dollars of interest and semi-corporate stake holders, no it won't change and any discussion about it is practically useless. But the protocol is one of the most important events in recent years and its implementation is a masterpiece, one of the most solid codes ever written.

Let's discuss the protocol, improve it and initiate a much smarter coin, meanwhile keep mining or trading bitcoin, ethereum, ... just don't fall in love with the coins, stick with the protocol.