Faster blocks fork

[kokojie]

Just throwing it out there, would anyone be interested in a Bitcoin fork that has faster blocks (Let's say 10 second blocks). Block size 0.2MB. Effectively increasing block size to 12MB per 10 minute

Advantages:
* Time to 1st confirmation will be a few seconds on average, good enough for even buying coffee and actually getting a confirmation, instead of relying on completely insecure 0-conf or 3rd party service
* Much better tx/sec capacity obviously
* Better user experience overall, it will just feel fluid for all tx, anyone that has used a sub-10 sec altcoin should know the feeling. Everything is just fluid

Disadvantages:
* Potentially bigger blockchain size obviously, but that's not really a big problem unless we are doing VISA level transaction volume
* Orphans for everyone, but that's fair

[CyberKuro]

Still have to learn more about advantages and disadvantages of bigger block.
I really want to see bitcoin transactions be confirmed in matter of seconds instead of waiting for more than 10 minutes even hours for every transaction.
Don't want to pay high fees compare to bytes of bitcoin transaction, it's unattractive to new users and for all of us which ever just paid BTC0.0001xx for bigger transactions.
What does this mean: Orphans for everyone, but that's fair? Orphans?

[Swagtoshi]

10 secs is a bit too short for the block time since the blocks take a few seconds to propagate. Although, a shorter block time would be advantageous as it increases the maximum transaction size and reduces transaction fee. However, I doubt that any sort of change will happen to bitcoin any time soon (except for maybe segwit2x) since no one can ever agree on anything.

[achow101]

Your difficulty would be 1/60th of Bitcoin's so it would be much easier to perform double spend attacks like Finney attacks. Increasing the block frequency means that 1 confirmation is much less secure; to have the same security of 1 confirmation on the Bitcoin blockchain, you would still have to wait 10 minutes so that the same amount of work is being performed (and longer if you are not expecting all of Bitcoin's hash rate to switch to this new coin). So sure, the first confirmation would be fast, but that confirmation is not very secure and a small mining pool operator could perform Finney attacks and double spend.

Also, not only would there be a lot of orphaned blocks, there would also be many multi-block blockchain reorganizations.

[HauntingT-Rex]

I read this earlier today from a bitcoin scalability blog post:

Decreasing the block time would lead to a decrease in security of the Bitcoin protocol; in an extreme scenario, if the block time were to be decreased to one second, and since propagation time is approximately 12 seconds, mining nodes would not have seen the latest block, and would continue to mine on top of a stale block. Mining nodes would be mining blindly, causing a significant amount of the network hashrate to be wasted, leading to the exact same outcome as increasing the block size as explained earlier.

[steamon]

Just throwing it out there, would anyone be interested in a Bitcoin fork that has faster blocks (Let's say 10 second blocks). Block size 0.2MB. Effectively increasing block size to 12MB per 10 minute

Advantages:
* Time to 1st confirmation will be a few seconds on average, good enough for even buying coffee and actually getting a confirmation, instead of relying on completely insecure 0-conf or 3rd party service
* Much better tx/sec capacity obviously
* Better user experience overall, it will just feel fluid for all tx, anyone that has used a sub-10 sec altcoin should know the feeling. Everything is just fluid

Disadvantages:
* Potentially bigger blockchain size obviously, but that's not really a big problem unless we are doing VISA level transaction volume
* Orphans for everyone, but that's fair

The idea sounds great. But what happens if you can use Bitcoin with low transaction taxes. People will start using it at a VISA level and yes that's great for the adoption and all. But we first need to find a solution for the increasing blockchain size before making the blocks faster in my opinion.

Overall on the streets, people that know about blockchain do say the following why would I use Bitcoin to pay at the gas station or buy a coffee because the transaction costs are too high? If that barrier is gone yes more people would start using it for smaller transactions. Just that you need insane HDDs then to just store the full blockchain on.

If they can fix the scaling problem and they can get to a solution where everyone agrees on with increased security then it would be nice. But now we must just see it as digital gold at its current level.

[Wahyuihib]

Still have to learn more about advantages and disadvantages of bigger block.
I really want to see bitcoin transactions be confirmed in matter of seconds instead of waiting for more than 10 minutes even hours for every transaction.
Don't want to pay high fees compare to bytes of bitcoin transaction, it's unattractive to new users and for all of us which ever just paid BTC0.0001xx for bigger transactions.
What does this mean: Orphans for everyone, but that's fair? Orphans?

Whats example fast bitcoin?

[defined]

10 seconds is too fast. 10 minutes is too slow. Maybe 2 minutes can work, it is 5 times faster, but slow enough to stop 'Orphans for everyone'.

I read this earlier today from a bitcoin scalability blog post:

Decreasing the block time would lead to a decrease in security of the Bitcoin protocol; in an extreme scenario, if the block time were to be decreased to one second, and since propagation time is approximately 12 seconds, mining nodes would not have seen the latest block, and would continue to mine on top of a stale block. Mining nodes would be mining blindly, causing a significant amount of the network hashrate to be wasted, leading to the exact same outcome as increasing the block size as explained earlier.

Hashrate is 'wasted' anyway, it has no use after a block is found.

[kokojie]

10 seconds is too fast. 10 minutes is too slow. Maybe 2 minutes can work, it is 5 times faster, but slow enough to stop 'Orphans for everyone'.

I read this earlier today from a bitcoin scalability blog post:

Decreasing the block time would lead to a decrease in security of the Bitcoin protocol; in an extreme scenario, if the block time were to be decreased to one second, and since propagation time is approximately 12 seconds, mining nodes would not have seen the latest block, and would continue to mine on top of a stale block. Mining nodes would be mining blindly, causing a significant amount of the network hashrate to be wasted, leading to the exact same outcome as increasing the block size as explained earlier.

Hashrate is 'wasted' anyway, it has no use after a block is found.

I feel if we are going with a faster block fork, it has to be different enough to feel the difference.

2 minute is not much different than 10 minutes really, it's still an awkward wait period for 1st confirmation, though certainly a lot less awkward.

You have to think from a user experience perspective, not from a technical/engineering perspective.

You have to make the technology work toward better user experience. Not build what you think is the best/most efficient technology, and make user suffer inconveniences.

Ideally, the faster block chain should strive for eventually having sub-1 second blocks if the technology allows.

[matt4054]

Just as a reminder, there are many such coins like this already. For example, Litecoin (started in 2011) uses 2.5 minutes mean block intervals. There have been many others with even shorted block periods, giving essentially what you described, i.e. many orphans.

The major argument against this is that confirmations are supposed to reflect how securely transactions have been settled, and to put it simple, you need 60 confirmations from a 10 second interval chain to "match" the level of security of 1 confirmation on a 10 minutes interval chain (with hashrates supposed being equal for this comparison). The only upside is that on-chain transactions (even with fewer confs) are by far more secure than zero-conf transactions.

[aleksej996]

This seems like a very old debate. It is like you are reinventing Litecoin.

It is great and all, but there are maybe people out there that have a little slower Internet connection or bigger latency. Bitcoin is decentralized and distributed, that means we all have to be in this together.

Decreasing block intervals from 10 minutes to 2 minutes would make Bitcoin faster, but if you are going to wait for 2 minutes, does it really make that much of difference to wait for 10? If you wanted to use Bitcoin as a credit card and just swipe it at the supermarket and leave, then 2 minutes is still going to piss you off.

As we make block intervals smaller then minutes and place it into seconds we are forcing people to have fast and very reliable connections. We are making people involved to be very closely interconnected with no room for error.

Block confirmations really aren't a good solution for instant transactions. Maybe the lighting network or something else is a way to go, but decreasing the block interval is really an inefficient way of dealing with this.

[jkminkov]

why is the proposal for segwit 2x to increase blocksize to 2Mb instead shorting 10 minute blocks to 5 minute blocks and double 6 confirms to 12 and 1440 blocks difficulty retarget to 2880 and last but not least important cut block reward by half so the original inflation curve stays the same?

[aleksej996]

why is the proposal for segwit 2x to increase blocksize to 2Mb instead shorting 10 minute blocks to 5 minute blocks and double 6 confirms to 12 and 1440 blocks difficulty retarget to 2880 and last but not least important cut block reward by half so the original inflation curve stays the same?

Because 5 minute blocks would help much. you still need to wait couple of minutes. But there is a drawback of having a bigger chance for 2 blocks to be mined at the same time, which means that one confirmation has a bigger chance of becoming invalid. Miners will need to have faster Inernet connections and people who are further away from the place the new block was mined would be at a disadvantage because of latency.

If you have 5 second blocks you get a network that has to be very closely interconnected and here you have the same problem, but smaller.

It could cause a lot of complications for practically no good benefit. Litecoin was created for these purposes.

[Argon2]

At 10 second spacing the network would produce more orphan blocks than valid blocks.

[Taras]

I think faster blocks would definitely be contentious, no matter what, because of the block reward. Everyone agrees that 12.5 BTC are to be created roughly every 10 minutes, until the next halving, and so on. But when blocks become 1 minute, you have to adjust the block reward along with it, or else bitcoin production will increase tenfold, which is unacceptable. Since every block reward will have to be scaled down, the distribution schedule will need to be changed to support that. I don't think that's ever going to happen; that is the most untouchable line of code in the entire project.

[jubalix]

Just throwing it out there, would anyone be interested in a Bitcoin fork that has faster blocks (Let's say 10 second blocks). Block size 0.2MB. Effectively increasing block size to 12MB per 10 minute

Advantages:
* Time to 1st confirmation will be a few seconds on average, good enough for even buying coffee and actually getting a confirmation, instead of relying on completely insecure 0-conf or 3rd party service
* Much better tx/sec capacity obviously
* Better user experience overall, it will just feel fluid for all tx, anyone that has used a sub-10 sec altcoin should know the feeling. Everything is just fluid

Disadvantages:
* Potentially bigger blockchain size obviously, but that's not really a big problem unless we are doing VISA level transaction volume
* Orphans for everyone, but that's fair

It doesn't really help having faster blocks as you need more confirms.

re-target code maybe needed fore core

[Cryptonomist]

Just throwing it out there, would anyone be interested in a Bitcoin fork that has faster blocks (Let's say 10 second blocks). Block size 0.2MB. Effectively increasing block size to 12MB per 10 minute

Advantages:
* Time to 1st confirmation will be a few seconds on average, good enough for even buying coffee and actually getting a confirmation, instead of relying on completely insecure 0-conf or 3rd party service
* Much better tx/sec capacity obviously
* Better user experience overall, it will just feel fluid for all tx, anyone that has used a sub-10 sec altcoin should know the feeling. Everything is just fluid

Disadvantages:
* Potentially bigger blockchain size obviously, but that's not really a big problem unless we are doing VISA level transaction volume
* Orphans for everyone, but that's fair

I agree that a increase in the block creation rate would be useful. It would allow for much quicker settlement of transactions, which I consider very important if we want that Bitcoin becomes more mainstream. However I see a couple of problems:

The problems associated with much higher block creation rates have been thoroughly studied. It causes, like mentioned before, an increase in the orphan block rate and so also a decrease in the efficiency of the network, which makes the network more vulnerable to attacks. More computing power is wasted on orphans, so the attacker needs less computing power to have a reasonable chance of success. However, solutions have been suggested for this problem. One of it is GHOST, which chooses the chain to mine on top of differently. An interesting article is Sompolinsky, Zohar "Fast money grows on trees, not chains". A more accessible article is of Vitalik Buterin "Toward a 12-second block time". These changes allow for very high block frequencies.

A different problem is of course that the higher block frequency will make it more resource intensive to run a node in my opinion. Not only will the block chain increase rapidly in size, also the bandwidth usage and probably CPU usage will increase. This will result in fewer people running nodes, which will lead to more centralization. This is in my opinion something that we really need to avoid. So i think we would also need some kind of compression method, so that this burden is decreased, and kept within the range of ordinary users. Even an increase to 0.2 MB per 10 seconds or 12MB per 10 minutes will in my opinion be a problem.

Next to that there is in my opinion also an implementation issue. It would require a massive rewriting of the Bitcoin code and will be a hard fork. It would in my opinion be much more difficult to implement this than a "simple" increase of the block size like segwit2x, etc... suggest. This makes it in my opinion practically impossible to do.

A simpler solution would be to increase the transaction processing by using sidechains or something like that. For example there would be a chain that starts with a few relevant bitcoin UTXO's which serve as the basis for the sidechain. Transactions are done quickly on the sidechain, which has a much higher block creation rate (for example every 10 seconds). This can be done by using GHOST and small blocks. Once every few hours a settlement is done on the Bitcoin blockchain on the basis of the end result of the balances on the sidechain. A bit like the Lightning network but using a blockchain.