Name the wallet, so that they can improve.
4 Likes
I can name three now, Unstoppable wallet, Cake Wallet and Trust wallet.
1 Like
Looking a little, I found this issue on the ‘unstoppable wallet’; Received Instant DASH transactions should appear as confirmed right away · Issue #364 · horizontalsystems/bitcoin-kit-android · GitHub
they don’t even update the balance until confirmed!
Probably the other 2 wallets are similar.
Naturally, this is their choice. They explicitly state this is how they want to operate Unconfirmed Transactions: How They Should Affect Balance · Issue #144 · horizontalsystems/bitcoin-kit-android · GitHub (still Unstoppable wallet)
But here is the good news. If you want instant transactions, you just have to switch to a wallet that understands the BitcoinCash chain better and actually supports that. I love the fact that there are a dozen wallets to choose from, and as most of those are actually open source you can find someone to fix those wallets to reflect reality better.
Hope that helps 
4 Likes
I will leave my 5-cents here.
I dont think preconsensus has to make strong finality guarantees. It is ok to wait for a strong block to make strong finality guarantees. However, preconsensus should make some finality guarantee that is better than 0-conf. This is especially poignant as it will occur with predictable frequency that blocks will take hours.
While it is true that you will have a difficult time enforcing the preconsensus, I believe it is possible to strongly encourage following the preconsensus. For example, everyone agrees transactions should be censorship resistant and we dont want miners colluding with double spenders to mine hitherto unpublished transactions. Both cases are an instance where a miners behavior causes them to deviate from what everyone else would have assumed to happen in the next block.
There is a mechanism to penalize a miner, that is if the majority of the hashrate decides not to build on top of their block, i.e. orphan it. Maybe the strong encouragement to follow preconsensus could be found in game theory, miners who participate in preconsensus make incentivized commitments to preferentially build on preconsensus conformant blocks, thus giving good miners a competitive edge over bad ones (lower orphan rate). Just as a general idea.
It is also the case that preconsensus would offer further benefits over propagation, if a block can be marked with a preconsensus proof (the hash of the contents only that preconsensus postulates), then its contents are already known precisely to all preconsensus participants, and so the contents would not have to be republished to them. Only non preconsensus miners need to have the entire block delivered before they can build on it, and thus they are at a latency disadvantage against preconsensus miners.
The answer is “Use a BCH first wallet.” Selene, Paytaca, Cashonize, Zapit, Electron Cash all operate on 0 conf.
If you insist on using a multicoin or non-BCH focussed wallet, then the poor integration of BCH related features (including 0 conf) is a choice rather than an inevitability.
2 Likes
Did a little analysis of block times: https://twitter.com/bchautist/status/1775125674300198967
The period until the obvious anomaly at x=3371 is pre-fork and that is shared history with BTC. Notice how volatile it was at early days of Bitcoin?
-
The anomalous area between x=3371 and x=3491 was the fork DAA era which was heavily gamed by miners to speed up the chain, and so BCH is now some blocks ahead of BTC, and it is the main reason why our halving is coming a little sooner
-
Then, between x=3491 and x=4571, we had cw-144 DAA which was gameable but to a lesser degree, block times were more stable but there were cyclical oscillations: notice the median dipping with only the average being stable. I think at first it was fine, until pools figured out how to game it, which can be observed on the chart.
-
Finally, we got the ASERT DAA which performs really well, and there’s even been some academic work analyzing it
Note: the plot is based on absolute difference between block times as read from block headers, which don’t always match the real clock.
Zooming in on the last 3 years, we can see some day-to-day volatility but things look generally stable. Note that big price movements can temporarily speed up (while price is moving up) and slow down (while price is going down) the blocks!
Thing is, each day will have 1 or 2 blocks which take more than 1 hour, and people tend to notice those, because there’s always people making transactions, and so there will always be someone who happens to make a TX at that time and he’ll be annoyed by the wait. Sometimes that someone will be you.
If more services adopted 0-conf, nobody would notice. It’s usually people waiting on payment processors or exchange deposits that get frustrated by the wait.
Payment processors could safely accept 0-conf if they wanted - usually the shipment of some good/service is not immediate and it can be reverted if someone tries to double spend. Also, we have double spend proofs which can serve as evidence and be used to punish the customer who tries to do the equivalent of shoplifting.
Exchanges could accept some risk, and have a 0-conf budget for their customers, allowing smaller deposits to be processed immediately.
With 2-minute block times, we’d still have extremes but they would then mean that every day there will be 5-10 blocks which take 14 minutes instead of 1-2 blocks which take 70 minutes. This could reduce frustrations with payment processors who usually require only 1-conf, but exchanges would likely adjust the required number of confirmations.
If starting a new chain, 2-minute block time would be a better choice than 10 minutes. However, changing an already existing chain’s block time would be a big cost on the whole ecosystem because things were built with assumption that it will never be changed, so I doubt it would be worth the trouble.
PS
It’s always the block you’re waiting for which will be the outlier
– Murphy’s law of blockchains
1 Like
Is there a reason why the DAA doesn’t take the halving into account? the recent halving is having a big impact on blocktimes so I wonder if this could not have easily been prevented
3 Likes
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.
3 Likes
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.
2 Likes
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.
1 Like
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
2 Likes
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.
The 0-conf Adoption Problem
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:
- Convince existing big players to adopt 0-conf. They’re all multi-coin (likes of BitPay, Coinbase, Exodus, etc.) and, like it or not, BCH right now is too small for any of those to be convinced by our arguments pro 0-conf. Maybe if we give it 18-more-months™ they will start accepting 0-conf? /s
- Grow 0-conf applications & services. This is viable and we have been in fact been growing it. However, growth on this path is constrained by human resources working on such apps. There’s only so many builders, and they still have to compete for users with other cryptos, services from 1., and with fiat incumbents.
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!
What about Avalanche, TailStorm, ZCEs, etc.?
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.
Main Benefits of Reducing Block Time to 2 Minutes
1. Instant improvement in 1-conf experience
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.
2. Instant improvement in multi-conf experience
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:
- The time until something happens (progress gets updated for +1) will be 1 hour / N.
- The number of confirmations will smoothly increase from 0 / N to N / N.
- I will have to wait 1 hour in total.
How does the individual UX differ from those expectations, depending on target block time?
- See 1-conf above, with 10-min target the perception of something being stuck will occur more often than not.
- Infrequent updating of progress state negatively impacts perception of smoothly increasing progress indicator.
- Variance means that with 10-min blocks the 1 hour will be more often exceed by a lot than with 2-min blocks.
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.
3. DeFi
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).
But Would We Lose on Scalability / Decentralization?
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.
What About Costs of Implementing This?
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.
But Could We Still Call Ourselves Bitcoin?
Who’s to stop us? Did Bitcoin ever make this promise: “Bitcoin must be slow forever”? No, it didn’t.
But What Would BTC Maxis Say?
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.”
5 Likes
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.
1 Like
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
1 Like
Here is another quote for you:
I am not yet done with choosing a solution you know. I am seeking something perfect.
2 Likes
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.
2 Likes
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?
1 Like