I’d guess simplicity. If you wanted to adjust difficulty at halving you can’t simply halve the difficulty too, because that would be making the assumption that fees are 0.
The halving-friendly DAA would have to sample some window of blocks for the fees and then take that into account when calculating the halving adjustment.
Hash could move off before the halving, which we saw this time (appeared to move off 10 blocks before). So this makes it difficult to account for. If hash drops just before, then the algorithm adjusts, and then the algorithm adjusts again 10 blocks later, we could have bigger swings.
Not sure it makes sense to change. This would not be an issue at all if BCH was in BTC’s place in total market value and had the by and large majority of hash (as there would be no other chain to move any significant hash to).
I hope this is the last time we have this issue because maybe, MAYBE, we can reclaim much or all of BTC’s market cap.
Right.
My reasoning was along the lines: Halvings don’t break anything, but it is a nuisance every 4 years. If there was a change that could be done to improve it without breaking anything else we should do it. I expected that things change when we get majority hash, but fees also need to be taken into consideration which I didn’t. Depending on how fees ramp up in the future the problem could also disappear within the next few halvings.
2024 halving was the first halving with ASERT DAA!
Post halving it took only a few days for block times to go back to normal
There was a recent discussion about block times and I’d like to revive this topic. I was initially opposed to the idea of changing the blocktime just because I thought it would be too costly and complicated to implement, but what if it wouldn’t? What if the costs would be worth it? I was skeptical about the benefits, too, but I changed my mind on that, too. I will lay it out below.
Obviously we’d proportionately adjust emission, DAA, and ABLA. My main concern was locktime and related Script opcodes, but those are solvable, too.
Note: in my original post I used Poisson distribution to calculate probabilities, but that answers the wrong question, it answered the: “How many blocks will be longer than X?”. I have edited this post with updated numbers based on Erlang distribution, which answers the right question: “If I decide to make a TX now, what’s the likelihood of having to wait longer than X for N confirmations?”. More details here.
I love 0-conf, it works fantastic as long as you stay in the 0-conf zone. But as soon as you want to do something outside the zone, you’ll be hit with the wait. If you could do everything inside the 0-conf zone, that would be great, but unfortunately for us - you can’t.
How I see it, we can get widespread adoption of 0-conf in 2 ways:
We want to grow the total number of people using BCH, right?
Do our potential new users have to first to go through 1. in order to even try 2.? How many potential users do we fail to convert if they enter through 1.? If user’s first experience of BCH is through 1. then the UX suffers and maybe the users will just give up and go elsewhere, without bothering to try any of our apps from 2.
Is that the reason that, since '17, LTC’s on-chain metrics grew more than BCH’s?
In any case, changing the block time doesn’t hamper 0-conf efforts, and if it would positively impact the user funnel from 1. to 2. then it would result in increase of 0-conf adoption, too!
Whatever finality improvements can be done on top of 10-minute block time base, the same can be done on top of 2-minue block time base.
Even if we shipped some improvement like that - we would still have to convince payment processors etc. to recognize it and reduce their confirmation requirements.
This is a problem similar to our 0-conf efforts. Would some new tech be more likely to gain recognition from same players who couldn’t be convinced to support 0-conf?
How I see it, changing the block time is the only way to improve UX all across and all at once, without having to convince services 1 by 1 and having to depend on their good will.
Think payment processors like BitPay, ATM operators, multi-coin wallets, etc. Some multi-coin wallets won’t even show incoming TX until it has 1 conf! Imagine users waiting 20 minutes and thinking “Did something go wrong with my transfer?”.
BCH reducing the block time would result in automatic and immediate improvement of UX for users whose first exposure to BCH is through these services.
With a random process like PoW mining is, there’s 75% chance you’ll have to wait more than the target 10 minutes (Erlang distribution) in order to get that 1 confirmation, and 40% chance of having to wait more than double the target time (20 minutes) for that 1 confirmation.
Table - likelihood of first confirmation wait time exceeding N minutes
Specific studies for crypto UX haven’t been done but maybe this one can give us an idea of where the tolerable / intolerable threshold is:
A 2014 American Express survey found that the maximum amount of time customers are willing to wait is 13 minutes.
So, there’s a 60% chance of experiencing intolerable wait time every time you use BCH outside the 0-conf zone!
What about really slow experience, like 3 times the target (10 minutes). Chances of that are 20%, and after 1 week of daily use there’s a 79% chance you’ve had to wait for at least one “outlier” block of 30 minutes or more.
If you’re a newbie, you may decide to go and complain on some social media. Then you’ll be met with old-timers with their usual arguments “Just use 0-conf!”, “It’s fixable if only X would do Y!”. How will that look like from perspective of new users? Also, if we somehow grow the number of users, and % will complain, then the number of complainers will grow as well! Who will meet and greet all of them? It becomes an eternal September problem.
Or, you’ll get on general crypto forum and people will just tell you “Bruh, BCH is slow, just go use something else.”. How many potential new users did we silently lose this way?
With 2-minute blocks, however, there’d be only a 1% chance of having to wait more than 13 minutes for 1 confirmation! In other words, 99% blocks would fall into the tolerable zone, unlikely to trigger an user enough to go and complain or look for alternatives.
Assume that exchanges will keep target wait time of 1 hour, i.e. require 6 x 10-min confirmations or 30 x 2-min confirmations. On average, nothing changes, right? Devil is in the details.
Users don’t care about aggregate averages, they care about their individual experience, and they will have expectations about their individual experience:
How does the individual UX differ from those expectations, depending on target block time?
Table - likelihood of 1 hour target wait time exceeding N minutes
Note that even when waiting 80 minutes, the experience will differ depending on target time: with 10 min the total wait may exceed 80 min just due to 1 extremely slow block, or 2 blocks getting “stuck” for 20 minutes each. With 2 min target, it will still regularly update, the slowdown will be experienced as a bunch of 3-5min blocks, with the “progress bar” still updating.
This “progress bar” effect has noticeable impact on making even a longer wait more tolerable:
(source)
This study was for page loading times where expected waiting time is much lower so this is in seconds and can’t directly apply to our case, but we can at least observe how the progress bar effect increases tolerable waiting time.
While our current DeFi apps are all working smoothly with 0-conf, there’s always a risk of 0-conf chains getting invalidated by some alternative TX or chain, either accidentally (concurrent use by many users) or intentionally (MEV).
During the discussion on Telegram, someone linked to a great past discussion on Reddit, where @jtoomim said:
The main concern I have about shortening the block time is that shorter block times reduce the capacity of the network , as they make the block propagation bottleneck worse. If you make blocks come 10x as fast, then you get a 10x higher orphan rate. To compensate and keep the network safe, we would need to reduce the block size limit, but decreasing block size by 10x would not be enough. To compensate for a 10x increase in block speed, we would need to reduce block size by about 20x. The reason for this is that block propagation time roughly follows the following equation:
block_prop_time = first_byte_latency + block_size/effective_bandwidthIf the block time becomes 10x lower, then block_prop_time needs to fall 10x as well to have the same orphan rate and safety level. But because of that constant
first_byte_latencyterm, you need to reduce block_size by more than 10x to achieve that. If your first_byte_latency is about 1 second (i.e. if it takes 1 second for an empty block to be returned via stratum from mining hardware, assembled into a block by the pool, propagated to all other pools, packaged into a stratum job, and distributed back to the miners), and if the maximum tolerable orphan rate is 3%, then a 60 second block time will result in a 53% loss of safe capacity versus 600 seconds, and a 150 second block time will result in an 18% loss of capacity.
(source)
So yes, we’d lose something in technological capacity, but our blocksize limit floor is currently at 32 MB, while technological limit is at about 200 MB, so we still have headroom to do this.
If we changed block time to 2 minutes and blocksize limit floor to 6.4 MB in proportion - we’d keep our current capacity the same, but our technological limit would go down maybe to 150 MB.
However, technology will continue to improve at same rates, so from there it would still continue to improve as network technology improves, likely before our adoption and adaptive blocksize limit algorithm would get anywhere close to it.
In the same comment, J. Toomim gave a good summary:
If we change the block time once, that change is probably going to be permanent. Changing the block time requires quite a bit of other code to be modified, such as block rewards, halving schedules, and the difficulty adjustment algorithm. It also requires modifying all SPV wallet code, which most other hard forks do not. Block time changes are much harder than block size changes. And each time we change the block time, we have to leave the code in for both block times, because nodes have to validate historical blocks as well as new blocks. Because of this, I think it is best to not rush this, and to make sure that if we change the block time, we pick a block time that will work for BCH forever.
These costs would be one-off and mostly contained to node software, and some external software.
Ongoing costs would somewhat increase because block headers would grow by 57.6 kB/day as opposed to 11.52kB/day now.
Benefits would pay off dividends in perpetuity: 1-conf would forever be within tolerable waiting time.
Who’s to stop us? Did Bitcoin ever make this promise: “Bitcoin must be slow forever”? No, it didn’t.
Complaining about BCH making an objective UX improvement that works good would just make them look like clowns, imagine this conversation:
A: “Oh but you changed something and it works good!”
B: “Yes.”
You do have some points, I am not negating everything you have said.
But your solution is the type of solution where you sacrifice something to get something else, which is what I precisely don’t like.
I prefer the absolute “have cake and eat cake”-type solutions, like for example CashTokens.
CashTokens are absolutely genius in this way, because they did not sacrifice anything, while gaining everything (lots of amazing new functionalities, contracts, introspection, tokens and other things).
Above is my reasoning for working on Intermediate Blocks (the linked topic). I want everything while sacrificing nothing. The golden goose solution. Like CashTokens.
There are thousands of different cryptos, each of them have SOME advantages with some sacrifices and disadvantages.
How do you break through and win the attention of the people and make yourself stand out and make a difference ? With exactly these type of solutions - the Ultimate Absolutes™ 
.
If you want to really make a difference in the world and become BIG, you have also to aim BIG. You cannot just aim for average stuff.
The basic issue I have with the rationale is the “if only I do this one thing, that girl will like me”.
That is not how the world works. The reasons why BCH isn’t getting the attention it deserves can be explained and backed up with many examples of propaganda, lack of out-reach, actually being the target of a very large movement that hates us etc.
Changing the one thing for the girl just doesn’t seem like the sane thing to do.
Isn’t that always the case, there are always trade-offs, but the “net profit” should be positive when we make them. CashTokens did this, too. It was not without costs, both one-off and ongoing, but the costs were worth it.
There are no solutions. There are only trade-offs.
– Thomas Sowell
I don’t believe that they solve the problem of TX confirmations. They solve other problems: block and mining reward variance. And they don’t do it without costs: for it to work consensus needs a change in how rewards are calculated and distributed, network code needs a lot of work, etc.
And even if they somehow did address the problem of TX confirmation (if 1-conf services could be convinced to accept 1-sub-conf instead) - adoption of this would face the same problem 0-conf faces now.
I’m all in favour of this. Ever since dsproof’s came out we had a simple timeline and one feature NEVER materialized. Which is a shame as 90% of the ecosystem uses it and they can’t actually use dsproofs to protect their incoming payments.
Please consider pushing this in order to get more people using dsproofs: Make DoubleSpendProof checking a little bit smarter. · Issue #237 · cculianu/Fulcrum · GitHub
Here is another quote for you:
I am not yet done with choosing a solution you know. I am seeking something perfect.
This analogy doesn’t hold. We’re not trying to attract 1 particular girl that’s playing whimsical games with us. We’re trying to make ourselves attractive enough to ALL the girls, so that we may take a bigger % of their attention and commerce than we currently do. Most girls don’t end up with the best possible guy, they go with the good enough guy that they happened to meet first. The big services like BitPay and Coinbase means they could regularly happen to meet BCH through them. Question is - do they then decide it is not good enough because they had to wait 30 minutes for something to happen? Psychology of humans doesn’t really change overnight, we’re still the same apes, and apes get annoyed if they wait too long, and they will remember the annoyance.
The bottom line is: 10-minute target means confirmation time is good enough* only 50% of the time, while 2-minute target blocks would make us good enough 99.8% of the time.
*Good enough: having to wait less than 13 minutes for something to happen (1-conf, or +1 on multi-conf progress indicator)
We don’t have to be the best (can’t compete with PoS that confirms in seconds), we just have to be good enough.
I’m saying that 10 minutes target time isn’t good enough, and that 2 minutes would be good enough, and that this will continue to be so as time goes on no matter that there exist even faster networks. Good enough is good enough.
Especially because a big chunk of commerce is moving to online / delivery services. You pay, you go to another tab to check out something else like some social media, few minutes fly quickly, you tab back and you already have 1-conf, TX confirmed, nice, so fast!
But not with BCH when it is having that 20-min block, you check back in after a little scroll on socials, still waiting - ugh, why is it so slow.
I agree we’re not trying to attract a whimsical girl, and that actually supports the analogy.
The analogy is about there being actual real world examples of BitcoinCash being shat on and more often than not being called a scam. Never ever mentioned in mainstream media, has been shorted to hell and back for years etc.
The analogy is thus not about whimsical games, it is about you picking one largely irrelevant point you can fix and trying to fix it.
While I think that is laudable, it is also putting your head squarely in the sand and ignoring the actual problems that make people not even look long enough to notice the thing you focused on improving.
Here is the actual bottom line:
if the problems of BCH not being mentioned in the media, not being accepted by most web-stores and mostly being seen as a scam, when those problems are solved then the blocktime suddenly doesn’t matter very much at all.
Your argument may very well be valid on benefits and costs. But it doesn’t matter when the underlying reason for our lackluster uptake isn’t fixed first. And if its fixed, then the problem is irrelevant to most. So why bother putting energy into it?
I guess the question is - would the “net profit” (benefits - costs) make a significant enough difference, even considering hypothetical fixing of some other underlying reason? How can we answer that question? I guess keep talking and see what everyone says.
Even if it would do 0 for pulling new users in, it would permanently improve lives of those who have already adopted BCH. I know I’ve paid for some stuff with 1-conf payment processors and was annoyed by the Murphy’s law of blockchains:
It’s always the block you’re waiting for which will be the outlier.
I’d rather have had to wait that outlier for 4 minutes instead of 20.
if i may ask, “what is the 0-conf zone?” … how do you quantify what is within and what is outside? i’ve never understood this, and I believe MOST merchants who would consider implementing 0-conf haven’t either…
in my experience, 20 minutes is SPOT ON! as i’m often accompanied by “no-coiners” when I’m cryptoin’, they’ll tolerate anything in the neighborhood of 15-20 mins, then it becomes extremely awkward (when you can’t reasonably explain to them why u have no idea how much longer)
and thank you for quantifying how “often” this occurs … i think most notably, we can clearly see that 14% is HIGHER than the ~10% that LN currently fails to satisfy ITS users.
(and how satisfied are we all wrt LN??? – 18 more months…)
imma call this “The Bchashers Fallacy” … as soon as everyone else realizes that we’re right and they’re wrong, all of our problems are solved…
essentially waiting for BTC to completely fail is the BCH master plan – a win by default??? – but wait, now there are literally hundreds of other “non-shit-coins” (offering unique value to their communities) to compete with as well – so will that plan EVER work???
i applaud your bravery for taking such an unpopular position @bitcoincashautist 
🫡
加油！
I’m with you on this.
x.com – found today just after getting off. People hate having to deal with exchanges. I doubt many will increase number of blocks necessary if we cut block time.
Also, 10 block reorg protection would cover (assuming 2min block time) ~20min vs 1.7hrs
Well the number of blocks would need a revision, too, don’t just assume we’d keep it at 10.
If you can just continue about your business without having to wait a confirmation, you’re in the 0-conf zone. Consider this hypothetical chain of events from user’s perspective: buy some BCH, get 0-conf TX in wallet, proceed to buy something on Bitgree with 0-conf, then put some of that change in a “hedge” contract, then proceed to mint some CashNinjas NFTs, then list one of those on TapSwap, then remember to buy something more on Bitgree, then deposit some into read.cash and upvote some article, then make a memo.cash post.
Through this entire chain of events, the user will face 0 wait, and his actions will build a chain of 8 TXs in the mempool.
Then he decides to buy something with a merchant using BitPay - he’s out of the zone, because now he’s waiting for that 1-conf (but he can still proceed to do 0-conf activities with change of that TX).
ok, and that’s precisely how i envision the utility of 0-conf being leveraged as well … but somewhere in time it mutated into being THE ONLY solution to satisfy EVERY possible need … and clearly that one-size fits all strategy hasn’t been cutting it…
thank you for reinforcing what i thought i already knew…
You are mixing 2 things. How well 0-conf works has currently literally nothing to do with how it is received by the populace. Good PR is missing here. You cannot fix PR problems with tech. Prejudiced/brainwashed people are the problem, not the tech.
It’s not the only solution, nobody said that. In fact, the community is currently working on other solutions. But it is a very good solution, still.
