Lets talk about block time

Consensus
#1

The point of this thread is to start a productive discussion about the pros and cons of changing block time, and get a better understanding of what impacts both good and bad, it will have on users, businesses, exchanges, miners, devs, etc.

Here is what I understand about block time so far, and how it impacts these different groups of people. Please correct me if I am wrong, I am far from an expert.

  1. Decreasing block time increases the frequency of orphaned blocks which decreases miner profitability. Unless we add something that ETH does where uncle (orphaned) blocks are rewarded coins.
  2. Decreasing block time decreases the variance in time it takes for a transaction to be confirmed.
  3. Decreasing block time makes each block individually weaker as less hash power is securing each block. This could make individual blocks more vulnerable to be maliciously orphaned and make double spending confirmed transactions less costly.
  4. Decreasing block time would improve user experience because confirmation time would have less variance.
  5. Decreasing block time would give businesses the option to accept a faster 1 block confirmation for transactions if they are comfortable with it being backed by less hash power security. This would also make the user experience better.
  6. I understand 0-confirmation is relatively safe for small amounts, but I think most businesses feel much safer if they wait to accept at least 1 confirmation just to make sure everything is okay, myself included.

Questions I have about block time:

  1. Do we know why Satoshi choose 10 minutes for block time? Was it because 2009 tech was slower? If Satoshi was creating Bitcoin today in 2021 what block time do you think he would choose?

  2. In reference to point (3) above. How likely is it that a double spend attack would happen on a shorter block time? Would honest miners come to the rescue to stop a double spend attack? Similar to how honest miners have defended BCH when it came to contentious forks.

  3. I have discussed with crypto users ( mostly traders ) why they choose a coin like LTC over BCH and one of the reasons is because they can move their coins faster between exchanges. Now I understand LTC is the dominant coin for the Scrypt algo which means its less vulnerable to be attacked as it has the most amount of hash power for its algo. While BCH using the sha256 algo only has ~2% of the hash power of BTC. I assume this is the reason why exchanges are more laxed on confirmation times for LTC over BCH. Is there anything BCH can do that would increase the confidence in exchanges to be more laxed on confirmation time or do we just have to wait until we have a bigger % of the sha256 hash power? If we did decrease block time for BCH would it help traders? Or would exchanges just increase the # of block confirmations required because they think BCH is vulnerable to double spend attacks?

  4. In reference to point (6) above. How different is it in terms of security for a business to accept a 0-confirmation transaction or waiting for say a single 15 second block confirmation? Cause I feel I would trust the latter much more even if hash power was weak.

5 Likes
#2

Vitalik Buterin has written a great piece on the considerations involved in choosing block time: On Slow and Fast Block Times | Ethereum Foundation Blog

Regarding your points:

  • Point 1: With shorter block times, the blocks are also smaller, so the main issue here is the fixed component of block propagation and validation time independent of block size - which indeed increases orphan rate. But there is a lot of room between our current 10 minutes and ETH’s 17 seconds.
  • Point 3: Double-spending confirmed transactions does not become cheaper if you increase the number of confirmations you wait proportionally to the block time decrease.

Other than that, I think the main challenges are of transitory nature: making sure the DAA, time-based smart contracts, and other processes tied to block height keep running smoothly though the change.

(BTW, Litecoin is no longer the dominant Scrypt coin - it’s been overtaken by Dogecoin. However, unlike BTC-BCH, both coins are merge-mined.)

3 Likes
#3

Can you articulate a problem that will be solved with a shorter block time? It really doesn’t make any sense to me why a consensus rule would be in place because of current exchange policies. If they change their policy tomorrow do we all have another hard fork to adjust to it? Super silly to me.

3 Likes
#4

The two problems I see it solving are the following:

  1. Decreasing block time would give businesses the option to accept a faster 1 block confirmation for transactions if they are comfortable with it being backed by less hash power security. This would also make the user experience better.

For example, I run a service that users can deposit SLP tokens into. I could accept 0-confirmation SLP token deposits, but I rather wait for one block confirmation. Users have to wait anywhere from a few minutes to an hour to wait for this confirmation before they can use their token on my service. If block times were shorter say 2 minutes, and I was comfortable accepting only one 2 minute block worth of hash power security then the user would only have to wait several seconds or up to 10 minutes for a confirmation. This would provide a much better user experience.

  1. Decreasing block time would improve user experience because confirmation time would have less variance.

A user waiting for a single 10 minute block would have more variance than say a user waiting for five 2 minute blocks. Both have same amount of hash power, but 2 minute blocks would be more predictable and have less time variance, which would provide a much better user experience. Instead of waiting anywhere from a few minutes to an hour with a single 10 minute block confirmation, I would guess the variance of five 2 minute blocks would be somewhere between 5 minutes to 20 minutes. Better user experience with 2 minute blocks.

1 Like
#5

That problem as far as I know could be solved with fraud proofs which would be much less invasive than a hardfork, not to mention, the user experience enhancement would be negligible vs the risk of splitting the network. Also, I don’t see anyone choosing LTC over BCH. That coin has development that’s been abandoned and BCH routinely is higher in market cap, while, BTC with 10 min blocks has hit 60k.

2 Likes
#6

Just mentioning in case you’re unaware, but @tom 's Double-Spend-Proofs (DSP) do a lot to mitigate the double-spend problem.

2 Likes
#7

If the point of lower block times is to make exchange deposits faster, and lowering block times lowers security proportionally, then it wont likely make exchange deposits faster.

Im going to need more data, not speculation, to convince me lowering block times is good for anything.

Maybe a different approach would be better. 0-conf is what needs security. The best first step is double spend proofs. Further advancements would likely require some form of preconsensus, if done intelligently, such as never mandating block inclusion but only rejecting latercomer doublespends. But that could have bad tradeoffs too.

#8

Decreasing block time would give businesses the option to accept a faster 1 block confirmation for transactions

That is an assumption about how businesses that I don’t think is backed by fact.

First of all, our track record with regards to frauds is enough to allow businesses to accept-as-final a transaction much faster than most do today.

The problem of businesses in today’s crypto landscape is one where it pays to be overly cautious. Likewise it can destroy companies if their risk profile is too low.
This, frankly, is no different than any other starting business-sector and history shows that as tech and expertise grows, user experience in this regard goes up.

When you realize this then the idea of differentiating yourself from the best understood crypto (BTC) is actually counter-productive.

The point to remember is that many companies are accepting a host of coins, they can’t possibly have expertise in all of them. Should one coin start to become the one that is used as money the most, this will change the landscape of crypto dramatically.

1 Like
#9

LTC is the dominant coin for the Scrypt algo

That’s no longer the case, because of Doge.

#10

Confirmation time is looked at as finalization of the transfer. I’ve not seen any payment processor or merchant accepts 0 conf and I pay with BCH alot. They are not giving special treatment to BCH based on the track record.

With block times reaching over one hour this can create really bad UX for people who really use BCH for daily payments and transfers.

I understand that some don’t like to change what Satoshi left to us but as you can see many player in the space have moved past this and managed to benefit from it.

Abnormal Block Times

image
image1272Ă—568 67.9 KB

source: fork.lol

See how many times blocks have taken more than 20 minutes to confirm. This adds app when 10-15 confirmations are required.

I think would be useful if we have a data of all sha256 coins and what number of confirmations is required by major exchanges and payment processors for each one. Do they treat BCH differently because of it’s fork history or they do they require the same confirmation time for each one of those minority coins.

I found only one known exchange that publish required confirmation time:

https://support.kraken.com/hc/en-us/articles/203325283-Cryptocurrency-deposit-processing-times

However most exchanges shows that value in the deposit page so might be useful if exchange users can provide required confirmations for sha256 coins.

Coins that uses Sha256:

Few notable sha256 coins:

  • Digibyte (DGB)
  • Peercoin (PPC)
  • Litecoin Cash (LCC)
  • BitcoinSV(BSV)
  • eCash (XEC)
  • TerraCoin (TRC)
  • Syscoin (SYS)

What about increasing confirmation time?

For sake of argument do you think that exchanges, wallets and service providers will reduce confirmation requirements if BCH increase block time from 10 minute to 20 minutes? I don’t think so. The important is the number of confirmations for them as more confirmations means more finalized, more secure. It’s not related to time.

So sticking to 10 minutes is just sticking to a random number that doesn’t seem to make sense in the technical term term.

After all we are already having 5 minutes blocks if you check the chart above and that didn’t seem to cause problem to miners or exchanges.

Who is effected by the problem of long confirmation times

  1. People using wallets (it’s clearly shows transaction as unconfirmed even in Electron Cash) imagine newcomer waiting one hour to get his cash
  2. People sending to exchanges
  3. People using payment processors (Bitpay - CoinPayment - NowPayment)
  4. People using Non Kyc exchanges (ChangeNow - FixedFloat)
  5. People using DEXs (AtomicDEX)
#11

I think there are some misunderstandings here.
Even if a miner gets lucky with a 5-min block, the block will have the same PoW as a 10-min or 20-min block because they’ll all have the difficulty target about the same. Because of variance, you can’t count on time to tell you how much PoW a TX is buried under. Counting the number of blocks will give you a much better estimate because difficulty doesn’t change that much after a few blocks.
However, if DAA target was changed to have 2-min blocks, then blocks would have 1/5 the difficulty and so each block would have 1/5 the PoW of a 10-min block, so exchanges would likely adjust their requirements to 5x. It’s not about time, it’s about cumulative chainwork.
More chainwork = more immutability.

See here how it’s calculated: difficulty - How is "cumulative PoW" calculated to decide between competing chains? - Bitcoin Stack Exchange

#12

I don’t think anyone here is really going to argue 10m is the perfect time. I don’t believe there is a perfect time.

The point is that we have this system that is in production and things like the payout schedule are based on these numbers. We all got into this chain BASED ON THOSE NUMBERS, we bought in with time, money and/or effort.

Changing them halfway through (well, hopefully 1/10th through) is like changing the gravity on this planet. It may be a great idea, but the entire ecosystem is working with the current settings, the time we expect to have left until we run out of fees is based on this. There are probably more intricate things based on this static number than we can come up with collectively in this thread.

It’s not a random number to the people that became active participants of this system. Like gravity is not just a random number.

1 Like
#13

That would be interesting if exchanges really set their confirmation requirements according to chainwork. I’m unable to find much info as it’s not a publicly available.

Here I again ask people which use exchanges to confirm requirement between similar sha256 networks. Sideshift seems to accept eCash but I don’t have eCash to test it and it doesn’t stat it before transaction.

In my quick search I only found that coincraddle.com requires 150 confirmation for BSV and 2 for BCH.

Here are some numbers from Xeggex, For me in first glance the difference in required confirmation doesn’t seems to reflect chainwork, does it?

Sha256 coins

coin Blocktime Xeggex Conf. Req. Kraken
Bitcoin 10 min 2 3
Lightning 10 min 1 Near-instant
BCH 10 min 5 15
Peercoin* 8.57 min 10
Digibyte 15 sec 10
syscoin 2.5 min 10
Ergon 10 min 10

Non sha256

coin Blocktime Xeggex Conf. Req. Kraken
LTC 2.5 min 6 12

Sources

https://www.peercoin.net/docs/comparison

  • peercoin seems to use PoS in a way along with PoW

Hope this information would be useful

1 Like
#14

I don’t think you can compare gravity that humanity have enjoyed for thousands of years to a system that have been there just for a decade and a half and people indeed tried and succeeded with using other “gravity” parameters on other universes :relieved:.

Sure before we destroy the universe we will test that on a different planet before we do it on Earth :slight_smile:

People who actually based their work on having 10 minutes blocks (smart contracts?) come and speak how changing it will effect them.

2 Likes
#15

There’s roughly 100 unspent perpetuities with (~46 BCH) mostly paying out monthly with a half-life of about 5.5 years. Lowering the block time would expedite those payout schedules proportionally.

For example, if the blocktime were changed to 1 minute, the half-life of those distributions would decrease by a factor of 10. So instead of paying out half the balance over 66 months, it’d be more like 6.5 months with payments ten times a month. Instead of paying out over 40 years, they might liquidate in 4 years.

Although a seemingly toy protocol, unspent.cash has the potential to be a kind of Mr. Frundles.

At this stage in the long bitcoin time-locking project, drastically reducing the blocktime would still prove the concept. There’s contracts with 1 year half lives where the notional value of principal just keeps going up.

That said, I personally don’t think changing the blocktime will improve security or help exchanges, merchants or users “trust” transactions more.

Coinbase.com will still say a 0-conf withdraw takes 6 hours. I’d expect an exchange that required 10 blocks will likely still require 100 minutes of hashrate and a checkpoint.

The current 10 minute block time would be an EXTREME advantage for a native BCH dex with relatively quick finality and high reliability. That is, if someone can go swap some wBCH for some wXMR instantly and know they probably won’t be in the 0.001% of trades that get’s rolled back on hyperDex, it gives the first seen 0-conf feel to trading, and would be a big draw.

In addition to adjusting the reward schedule as @freetrader suggest below, we might be able to use something like transaction version to separate which transactions expect a 10 minute blocktime and which assume a quicker one. i.e. v1,2 transactions are 10 minutes, v3 are 2 minutes, or something.

From very old discussions, I agree with our former overloads that any merchant transaction taking longer than about 3 seconds to reach finality is a deal breaker.

1 Like
#16

Also one should bear in mind that past discussions have always noted that if decreasing the confirmation time, one could lower the coinbase block reward and adapt the halving interval proportionally to minimize changes to the original payout schedule.

So let’s avoid giving a false impression that such a change would necessarily change the payout schedule or the total issued supply in a material way.

2 Likes
#17

Please give more details about that proposal, you may have seen someone solve that, but it is new to me. How, technically, would you keep the current schedule while having more blocks per hour?

Current; Controlled supply - Bitcoin Wiki

#18

This is about a point I’ve tried to make in the past as well, people that value this kind of trading will never be satisfied with a decentralized and “slow” system. Look at the movement of high frequency trading as a prime example. Even there the competitiveness of being nanoseconds before others is relevant to those that want that kind of thing.

They will in the end always benefit more from some centralized trading house, and that would benefit BitcoinCash too as the volume of transactions on-chain to support gambling like that is bound to overwhelm normal people actually paying their groceries on-chain.

To @tech, what evidence do you present that shortening the blocktime has any positive effects on things like payment providers accepting transactions? And why would you say that 2.5 minutes is Ok for me to hold up the queue in the supermarkt ?

#19

If DAA target would change to 1/5 of the current (to 2 min) then block reward should also get changed to 1/5 the current at the moment of switching from 10 to 2, and halving heights after that would be accordingly recalculated as well. I guess we’d get to 0 a bit sooner due to additional integer division by 5, however if we’d have your increased precision CHIP then we could exactly match the original supply schedule. Anyway, even though nobody has worked out the details doesn’t mean it’s not a solvable technical problem.

The locktime opcodes would continue to work with “legacy” heights, like pretend you subdivide block 123 to 123.0, 123.2, 123.4, 123.6, 123.8. If the TX ends up in any of those, the locktime opcodes would evaluate as 123. To get more granularity would require a new set of locktime opcodes. Anyway, backwards-compatibility with regards to contracts is also a solvable problem.

I think the biggest ecosystem cost would be in having various blockchain analytics pages get messed up and display wrong info.

There’s also the increased headers size, and the question of orphan rates.

4 Likes
#20

Tom, @bitcoincashautist has explained it perfectly in this post