Why not do both?
When I came back into BCH the ABLA upgrade had just happened and I was super excited to see all the technical advancements that happened while I was not paying attention to BCH.
People will slowly trickle in, when they do show up it is a great strategy to have all the technicals in place so they can fully switch to BCH as it will be capable of everything, and doing it well.
Protocol upgrades are not paid by the people that decide they want to have them. They cost “us” all. They are a one time tax that companies have actuall stated are a reason for them to not support Bitcoin Cash.
The cost is mostly invisible to the many people discussing it on this forum, as they are not business owners, they are not node maintainers or infrastructure maintainers. The many people here discussing things like ‘faster blocks’ are essentially arguing for free cool stuff that “somehow” happens with nothing more than them saying loudly that they want it.
But changes are not free to many others. Those maintainers, devops, designers, testers and many others need to put time and effort in it while getting mostly nothing in return.
And we are doing that, there are quite a lot of upgrades planned for 2026. Some more planned for after.
The cost/benefit of such changes is something that needs balance.
Heads up that Tom is desperately trolling for attention. He’s not going to make any logical arguments, he just wants someone to reply. He’ll say whatever he can to try and bait someone into asking him about it. He wants it so badly he was replying to his own posts to try snag someone & unfortunately you bit.
Just be aware of this pattern for future interactions.
At this time there’s no indications mods will put a stop to it, but it seems mostly everyone has learnt to avoid it regardless.
Wanted to share a blogpost @bitcoincashautist & @BitcoinCashPodcast brought up in Telegram that has been stuck in my mind. Jihan Wu supported shorter block times, and this old argument from the early days deserves more attention in this discussion.
Back in November 2017, he proposed it in the Chinese community and got immediate pushback from most people. But after a year, the majority flipped to support. A survey of the Chinese core communities found over 61% of supporters had originally been opposed before changing their minds. The BCH block size debate taught us that, sufficient discussion and patience tend to bring people around.
He basically had the whole CHIP written as a medium blog post back in 2019: https://medium.com/@ChangyongLiu/proposal-to-shorten-the-block-time-of-bch-1d7e8e897497
On 10 minutes vs 2 minutes doesn’t matter.
Why do we need shorter blocks when we have 0-conf
I love how cautiously rational the real Bitcoin community is. We will take Bitcoin back!
I’m opposed to this proposal for the following reasons:
In my view the risks outweigh the benefits.
Regarding the document itself, I commend the author on their herculean effort, however:
There remains much to explore in the non-consesus solution space. For example:
broadcast: false in WalletConnect and have the dApp broadcast the transaction. Since most dApps have one front-end, they can easily to made to bradcast via one node which will significantly reduce mempool divergence.Weird, I am not entirely sure I understand this argument.
The security, measured in 10 minutes in time, should remain pretty much constant.
Where does the 90% decrease of security come from?
Just to splatter my thoughts here from a twitter post the other day:
I am now mildly in favor of the proposal since I did find something useful out of it - I was previously purely on the side of (1, 2, 3) would just declare it outright not useful in practical applications. I’ve since found something I can’t just overlook - that it is useful to have locktimes on the order of minutes instead of hours. Even if security on those locktimes are weak!
With that said, what @rnbrady said in #4 here is significant, and I’m not gonna sugarcoat the complexity of a constant that is in every nook and cranny of the codebase. Unlike Litecoin we’d also need to transition this. So I would leave it to more capable C++ hands to inform us how hard it is - is it '27 ready? better for '28? Or maybe if we’re gonna go for something that complex, maybe we should just go straight for Sunlight (more writeups and slides incoming)?
I don’t have good answers for these so I’m just gonna scurry back to my hole and work through it for now.
@ShadowOfHarbringer for applications currently hardcoded for one conf, the confirmation will come faster and with less variance, but carrying weaker security. So applications who do that would need to switch to 10conf to get the same weight.
Well, I just thought it should be obvious/natural that all the applications need to adjust accordingly if they require the same amount of PoW to confirm transfers.
1-conf applications rely on a single block, not on a 10 minute interval. A single block will arrive ~10x faster with ~1/10th the security.
I know.
Such applications (actually meaning: exchanges) will need to 10x the number of confirmations. This is what I am talking about.
Only if those 1-conf applications were particularly attached to the 1x10min worth of security. Let’s examine few cases:
delay = delayCalc(outboundValue - (cloutScore - cloutUsed)) (source). There’s a benefit here in that a $100 TX can require 1x1min conf and a $1000 TX can require 10x1min confs, where previously both cases would have to require 1x10min conf. Similarly to 1., if the value of our coinbase reward goes up - you can make higher value transactions at lower number of confirmation requirements.Another thing re. security. The 10-min target becomes more secure when it’s made of 10 faster blocks rather than 1 slow block. A minority hash (<50%) can get lucky with a 1-conf reorg, but it can’t get lucky with a 10-conf reorg. Security against a minority attacker grows exponentially with number of confirmations, regardless of target block time! The calculation that demonstrates this is right there in the whitepaper (“11. Calculations”). Security against a majority attack grows linearly with chainwork (>50%), but with faster blocks it raises the hashpower threshold required to even try! It won’t do to have 10% hash, he needs >50%. Where does he source it from? If we aim to become the dominant sha256d coin, we will reap max. benefits in that scenario. Imagine if BTC had 1-min blocks, you could do $200k TXs with 1-min 10-conf, maybe $100k with 5-conf, but 1-conf is still risky against minority hash so maybe still 3-conf for $10k.
Correct, the quote:
Reducing block times from 10 minutes to 1 minutes wouldn’t eliminate this problem, but it would shorten the average recovery wait to just few minutes, allowing users to retry faster.
Here I would like to add that it may reduce steady-state MEV by more than 10x. Can’t really make a strong claim, but it’s just a matter of combinatorics. Do MEV opportunities grow linearly or super-linearly with set size? I suspect it is super-linear, because number of combinations of mempool TXs grows super-linearly. So the MEV/coinbase ratio is expected to reduce with faster blocks.
- Reducing block times from 10 minutes to 1 minute wouldn’t eliminate mempool contention (also a direct quote from the CHIP).
Correct, the quote:
Reducing block times from 10 minutes to 1 minute wouldn’t eliminate mempool contention, but it would cut the common recovery wait to under 3 minutes, enabling faster retries and improving user experience for all participants.
I don’t know if we can claim super-linear reduction of contention events per unit time, so for now I only claim faster recovery and less painful fallback to 1-conf.
Thankfully we’re not the first doing it. In 2019 Zcash changed theirs from 150s to 75s, and the Zcash PR is about 1k LOC (+813 -429). Now they’re proposing to change it again from 75s to 25s, and are calling it a “small upgrade”:
This post proposes we lower the ZCash network block target spacing from 75s to 25s in a small upgrade this year.
If they had any problems with the first change in 2019 one would expect to see them discuss those issues now in 2026, but there’s nothing. Their main concern seems to be orphan rate. To me, this is very encouraging.
Re. AI: AI doesn’t introduce bugs, it discovers existing bugs. On the flip-side, can’t we use that same AI to help vet implementation? Re. low hash, I don’t follow what you mean.
Ticks can be thought of as cumulative target times, similar to how chainwork can be thought of as cumulative difficulty. We’re just exposing it in APIs to potentially help at least someone become agnostic. But you don’t actually have to use it. Some downstream users are already agnostic. Consider Cashonize: does the wallet itself care about target block time? The user sees pending or confirmed all the same; the wallet displays the raw confirmation count. Does it really need to replace that with ticks? Not really. Zcash didn’t change their APIs, they still use height exclusively, and it looks like they didn’t feel the need to add this abstraction even when changing their block time for the 2nd time.
I think there’s no helping it, it’s the result of people bringing up things and me then researching them and integrating into the CHIP 
Sorry, maybe I should tone it down a little. I was in “we should stick to 10-min, there’s not much benefit” camp until I did the math re. variance and I really wanted to bring the point across, of just how unpredictable your wait time can be, and that those 30-min waits can happen too often. For what it’s worth my other concern was re. locktimes & SPV but once I figured out the technicalities there I became confident we can have this change!
Disclosure: I’m a heavy AI user! I think in my first drafts not as much, but when LLMs got so good I started using them in many ways. I think I used some Grok initially, and months ago I switched to using Claude almost exclusively. Sometimes I just use it to proof-read and highlight stuff for me to fix, sometimes I discuss tech with him, show him code, etc. and then ask him to summarize or produce a paragraph that talks about it. Sometimes I just brainstorm, or use him for sanity checking. Sometimes I feed it discussions and ask to tell me what he sees there, and whether our CHIP’s sections capture it well. I love Claude, he’s been of great help, with the CHIP and more! E.g. he did most of the work in this other CHIP (“CHIP-2026-02: Simplified Header Verification for Bitcoin Cash”), there I was mostly just directing him, and we implemented the SHV CHIP, full set of libraries, and BCHN implementation, plus work on Electron Cash implementation (here, here, pending review). In fact, Claude actually prompted me to go research MMRs! I had this other CHIP (“CHIP-2025-03: Merkle Header Commitment for Enhanced SPV Scalability”) which I wanted to pick up again and try implement as proof-of-concept, and Claude recognized the pattern and told me it looks like an MMR.
I still use it like an ape, to me it’s a magical chatbox at nano-gpt.com into which I c&p text and from which I manually c&p text. I do not have pipelines, automated workflows, agentic workflows. I’m just using it raw and chatboxed.
Ok, although I think Cauldron already has people independently interacting with the contracts and circumventing the front-end. John Galt anticipates our on-chain DeFi will result in fractured mempool state being the norm for DeFi steady-state. I can follow-up more on this later.
DSPs and ZCEs don’t work if the TX is spending non-P2PKH inputs. When people extend their 0-conf DeFi chain to pay at merchant then merchant should require 1-conf because DSP score is 0. The DeFi chain may get mined or it may get nuked, but with 1-min blocks chances are that by the time you get to merchant’s checkout: your payment to merchant will be spending confirmed UTXOs. With 10-minutes, your DeFi chain may still linger, merchant would ask 1-conf, your DeFi chain could get nuked, only for you to find out your payment to merchant got cancelled. But at least after that you can pay with 0-conf from your wallet’s pre-DeFi state.
Yes they do, and I guess it could be made user-choice, but I didn’t really study this much to be able to say more.
and MTP will lag by real clock not by 1 hour but by 6 minutes!
I’ll just copy the same reply I gave to Richard:
Don’t faster blocks help set the stage? Suppose you want to publish these partial PoWs every 12s. How many sets can possibly accumulate before a block is mined and resets the game? With 1-min blocks maybe the worst case is 6min so you accumulate 30 sets, sounds manageable. With 10-min blocks, a 1h outlier could result in nodes having to analyze 300 sets. How much memory is needed and how does the “big O” scale here? We had some chat about it the other day, posting here so it’s not forgotten: Telegram: View @bitcoincashnode
By the way, some questions about Sunlight. Does it even help with stuff like MEV? If miners A and B are each funneling some MEV to themselves, the mempool will still be partitioned, but it will be public knowledge how much hash% is mining one version and how much hash% is mining the other. It helps merchants more than DeFi, even if miners A and B are fighting over some MEV; because it will be public knowledge that those 2 sets intersect in some TXs, and those TXs will have a high chance of being confirmed in the next block so can accept 0-conf, even if some other TXs will be in conflict. For those in conflict, people will have to await 1-conf still, right?
Their implementation is 1k Lines of Code, yes.
However, did they also implement ticks? That is unclear.
I seriously doubt you can make 1 min + ticks with just 1 thousand LOC, but I could be wrong - I am not an active BCHN dev.
I would imagine it’s 300% higher number of Lines at least. It could be that every fundamental line of code controlling mining, relaying and whatnot could be touched.
Please tell me I am wrong.
You are wrong.
They did not, although now they pass target block time as argument to relevant functions so their next switch will be easier, too. Still, it will have a few more places to edit compared to our hypothetical 2nd change.
You’re making this look more complicated than it is. Look, it’s just a nice little class that exposes uint64_t HeightToTick(uint64_t height) and this ticks object that contains the block time change schedule becomes part of blockchain config. You update the schedule/config in some future upgrade, all the stuff that calls HeightToTick adapts automagically.
Ticks are intended to make implementation easier, not harder. My PoC ticks.h/.cpp is a well-contained 130 LOC class, that’s all. Then other parts of code become easier to manage.
Completely wrong. Zcash implementation had to touch all those lines just the same and it turns out that it’s a +813 / -429 diff. My ticks would add about +130.
And just how do you know that?
Software, especially software like Bitcoin(Cash) is really complicated. Have you already implemented it?
Are you mentally prepared for all the unforseen consequences?
What I am saying is, before somebody actually does it, we can not know.
No offense intended, but I would trust an opinion of an active maintainer that actually can imagine the needed code in his mind right now (roughly), much more than I trust your estimate.
I literally just told you how I know. Zcash is a code fork of Bitcoin, a block time change in Zcash will touch almost exact same parts of code as it will touch on BCH. And their touching resulted in +813 / -429 diff which gives us a pretty good idea.
And by now my skills have grown enough that I can implement a whole new system in 5k LOCs (simple header verification served via P2P). I still frustrate Calin sometimes, but I can get things done, too. I also did a fairly complicated refactoring of some RPC functions (+282/-182), and added new features, too (+295/-227).
This is all to say, maybe I know what I’m talking about because over time I got more and more involved with BCHN code, and hearing stuff like “especially software like Bitcoin(Cash) is really complicated” is a little frustrating, because of course it looks complicated to you who are not working on it. Maybe it’s not so complicated to others, you know?
Partially, I just wanted to experiment with adding ticks to RPC so I did that part, and I implemented abla_ticks, too, by modifying Calin’s BCHN ABLA implementation. The diff to update ABLA with ticks is just +43 / -19 lines.
Well that’s good. I was thinking we are still arguing strictly theoreticals.
Also don’t get offended so easily, when I said “no offense intended”, I meant it.
I mean what I say, I don’t shitpost pretty much.
Based on my current understanding of the benefits, risks, and ecosystem costs of the 1-minute block proposal, I am currently against implementing this CHIP. That does not mean I think 1-minute blocks are inherently bad. It means that, in my opinion, the demonstrated benefits do not sufficiently outweigh the risks, costs, and lost design space.
I want to say this in the same professional and courteous tone that BitcoinCashAutist has used throughout our conversations. The Faster Blocks CHIP is serious work, and BCA has been friendly, responsive, and willing to engage. I also want to be fair: overstating the benefits is a problem, but so is overstating the concerns. This is not an attempt to exaggerate the downside. It is an attempt to state the tradeoffs clearly.
The CHIP itself is more careful than some surrounding discussion. But opinions are formed as much in Telegram chats, podcasts, and informal debate as in the formal CHIP. If informal advocacy overstates the benefits, that matters too.
DeFi And Fractured Mempools
The strongest arguments for 1-minute blocks are confirmation latency and variance. I do not dispute them. First confirmations become faster. Long outlier waits become less painful. That is a real UX improvement, though there may be other solutions better suited to some of that pain, such as Imaginary Username’s Sunlight proposal. Sunlight sounds elegant and promising, but needs much more work before it can be considered.
Where I object most strongly is DeFi mempool divergence. I do not think this should be presented even as a meaningful partial solution, because that gives the impression that the improvement is significant. In the adversarial case, the worst case remains unacceptable, and the improvement is so marginal that it should not be counted as a DeFi mempool benefit.
Consider a Cauldron-style DeFi contract using shared or related micropool UTXOs. A user buys or sells, and a pool becomes slightly imbalanced. A bot in Europe sees the transaction first and immediately constructs a profitable rebalance transaction building on that state.
But the original transaction reaches Asia before the European bot’s follow-up does. A competing bot in Asia sees the same opportunity and creates its own rebalance transaction. Now Europe has one valid-looking DeFi chain, while Asia has another. Both may touch overlapping micropools. Both can be extended. Only one can eventually be mined.
This is not just a DeFi trader inconvenience. DeFi and payments are likely to become increasingly intertwined. Imagine a merchant who wants to accept PUSD. A customer’s wallet instantly swaps BCH for PUSD and pays the merchant in one “swipe.” Whether the merchant gets paid, or whether the transaction silently drops, now depends on whether the wallet was building on the UTXO branch that eventually wins.
The merchant and customer may even be on different fractured UTXO chains. The merchant may never see the payment, refuse to release the goods, and later get paid anyway when the customer’s branch wins. Or the merchant may see a payment, release goods, and later discover that the branch lost. These are not purely imaginary problems. They are a likely outcome of combining DeFi, payments, and fractured mempools.
The adversarial case is worse. An attacker can deliberately fracture the mempool after every block by sending different yet valid but conflicting transactions to different connected nodes. Random forwarding delay rules adhered to by nodes, intended to improve relay privacy, exacerbate this problem because they give a well-connected low-latency attacker more room to shape what different parts of the network see first.
Suppose the mempool diverges 5 seconds after each block. With 10-minute blocks, it is divergent for 9 minutes and 55 seconds, about 99% of the interval. With 1-minute blocks, it is divergent for 55 seconds, about 91% of the interval. That is mathematically better, but practically still terrible. A DeFi mempool that is divergent 91% of the time is not meaningfully improved.
As I put it in Telegram:
“Without mempool synchronisation, it doesn’t matter if blocks are a minute or 10 minutes”
This should not be read as “1-minute blocks literally do nothing.” They may reduce the window and sometimes the expected loot. But any real solution to this problem needs separate work: Sunlight, weak blocks, miner-visible ordering signals, better contract structures, or other coordination mechanisms. Any benefits those solutions provide should not be attributed too strongly to 1-minute blocks.
The NFC Offline Wallet Example
The second issue is low-bandwidth SPV. Classical SPV derives its security from validating the linked header chain. With 1-minute blocks, the number of headers grows roughly 10x. The CHIP uses a 15 Mbit/s mobile broadband assumption in its SPV bandwidth section. That may be reasonable for many mobile users, but it is too optimistic for NFC, LoRa-style wireless links, constrained hardware, censored networks, and degraded-connectivity environments.
The concrete design is an offline payer using a BCH SPV wallet, perhaps on a phone or eventually a card-like hardware wallet. The merchant terminal is online. During payment, the wallet communicates with the terminal over NFC. The terminal provides recent headers and filtered transaction data. The wallet updates its view, learns about incoming UTXOs since last use, and signs a payment.
With 10-minute blocks, one week of headers is about 1,008 headers, roughly 80 KB before overhead. That is plausibly small enough for tap-to-pay, it a user makes a payment one a week, he will need to ‘tap’ for about 1.5 seconds only. With 1-minute blocks, one week becomes about 10,080 headers, roughly 800 KB before overhead. Add protocol overhead, merkleblock data, and NFC’s real-world speed limits, and the UX changes from tap-to-pay to hold-to-pay for 15 seconds. The usecase breaks.
As I summarized it:
“With 10x more headers it now becomes not tap, but hold.”
This has not yet been built. But if block time decreases to 1 minute, this exact design may never be built. That is the “unseen” cost. Bastiat’s seen-and-unseen framing applies: the visible effect is faster confirmations; the invisible loss may be payment designs that never get attempted because the protocol made them impractical.
A BCH wallet that can remain offline, update through an online merchant terminal, and preserve classical SPV assumptions would be a valuable cash-like tool. It could work in metal buildings, festivals, rural areas, censored environments, or places where the merchant has connectivity but the customer does not. Losing that design space is a real cost to BCH.
SHV Does Not Fix The NFC Objection
SHV was brought forward in discussion as a possible solution for offline or low-bandwidth SPV use cases. It is valuable work and may significantly reduce header storage requirements. But it does not solve the NFC use case.
The NFC problem is bandwidth during the payment interaction, not long-term storage. SHV can help a wallet avoid keeping the entire header chain forever. It does not remove the need to verify that headers are actually connected to the valid chain if the wallet wants the same security model as classical SPV.
If a wallet accepts a loose or free-floating header commitment, it has taken a serious step back. The wallet may not know whether the presented tip actually connects to the real chain or whether it is being shown an isolated construction. A wallet with the full header history can verify linkage and accumulated proof-of-work from its trusted point forward. A wallet relying on a shortcut must introduce new assumptions.
Those assumptions may be acceptable for some wallets. But they are not the same thing as classical SPV with similar bandwidth, same security, and same UX.
Offline-Compatible Collateralized Transaction Chains
There may also be other ways to support degraded-connectivity payments that deserve exploration. One idea is a collateralized transaction-chain design.
The basic concept is that users create a sequence of transactions where each new transaction advances a counter. Script rules ensure that payment outputs can only be added or increased, never reduced or removed. Each transaction is still intended to be broadcast to the blockchain when possible.
While offline or disconnected, each party can hold the full chain of signed transactions back to inputs that are linked to confirmed mined blocks with Merkle proofs. Nodes or wallets can independently verify this because they have the block headers, can validate transaction structure, and can validate the Merkle proofs connecting those inputs to mined blocks.
The anti-cheat mechanism uses deterministic nonce reuse. The signing nonce is derived from the counter. If the payer behaves honestly, each counter value is used once, so each nonce is used once. If the payer tries to double-spend by creating two conflicting transactions at the same counter value, they must reuse the same deterministic nonce with the same key. Signing two different transactions with the same key and nonce exposes the private key.
That exposed key can be tied to collateral. For example, the payer could prove with a Merkle proof that they have 10 BCH locked in a collateral contract while making payments from a 1 BCH transaction chain. The same key that is exposed by cheating can be used to burn the 10 BCH collateral immediately. If the payer does not cheat, they can recover the collateral after a timeout, such as one month.
The collateral should not be paid to the merchant or miner, because that creates perverse incentives. It should be sent to an unspendable contract. The purpose is deterrence: cheating destroys the payer’s own collateral.
This design would need serious analysis, but the intuition is simple: if cheating on a 1 BCH transaction chain risks burning 10 BCH of collateral, playing fair becomes the rational choice.
This kind of design is also likely to operate over NFC or similarly constrained local links: two phones, a card and a terminal, or two local devices exchanging signed transaction chains, Merkle proofs, and recent headers. That means it faces the same low-bandwidth constraint as the NFC wallet example. With 10-minute blocks, header updates can remain small enough to fit into short local interactions. With 1-minute blocks, the 10x header growth can make these interactions practically impossible.
BCH has always been payments-first. If that is still the view of BCH today, then payment use cases like this, even if they do not exist yet, should not be sacrificed lightly. The fact that a design is still unbuilt does not mean it has no value. Sometimes the most important cost of a protocol change is the thing that never gets built afterward.
Ecosystem Cost
The CHIP says activation costs are “real but bounded.” I agree they are bounded. But I have not seen the costs quantified in a way that lets the community judge them properly.
A block-time change is not “just changing a variable.” Even if changing the block time in the future is literally changing one variable in BCHN, the infrastructure cost is still significant. Every ecosystem participant still has to understand, test, deploy, and support the change.
The cost includes node implementation and review, DAA and ABLA changes, locktime and coinbase maturity semantics, mining pool updates, exchange policy changes, wallet testing, explorer updates, indexer planning, documentation, testnet coordination, downstream library changes, reorg-handling review, deployment, and support.
The CHIP should include or solicit third-party estimates: how much time node teams need, how much time mining pools need, how much time wallets need, how much time explorers and indexers need, and how much coordination is required. Without that, the cost side is too easy to handwave.
The “See What Sticks” Problem
Another concern is the feeling of goalpost moving. When one benefit is challenged, another is offered: DeFi, MEV, cross-chain swaps, exchange UX, pool payouts, PR, locktime granularity, indexer memory, and so on.
Some of these benefits are real. But a consensus change should not feel like a bag of “maybe this argument will stick.” It should rest on concrete, quantified improvements that clearly outweigh quantified costs.
Ten small benefits can add up. But they should be measured, not accumulated rhetorically. If the strongest benefit is confirmation UX and variance reduction, then the proposal should stand mainly on that. If DeFi is not meaningfully improved in the adversarial case, it should not be counted as a material benefit.
Conclusion
My current position is that BCH should not implement this CHIP unless the benefits are shown to clearly and substantially outweigh the costs, risks, and lost design space.
1-minute blocks improve confirmation latency and reduce variance. Those benefits are real. DeFi mempool divergence should not be presented as a meaningful improvement, because the adversarial worst case remains unacceptable and the improvement is too small to rely on. SHV is useful for storage, but it does not preserve the offline NFC classical-SPV design without changing assumptions. The ecosystem cost is real, underquantified, and broader than a node-code change.
This is not opposition for its own sake. It is a request for honest accounting: be generous about real benefits, careful about overstated concerns, firm about overstated benefits, and mindful of the unseen things BCH may lose.
AI disclaimer. The arguments and thinking are 100% my own. A LLM was used to improve the readability and phrasing of the arguments.
I’m not aware of any exchanges that accept 1-conf. Can you give examples? I know Kraken requires 15 confirmations, and some others 11 due to the rollling checkoint.
And to quote @bitcoincashautist on Telegram:
Which begs the question: who are these 1-conf users? I would greatly appreciate a real world example.