That’s true when you look at it as a vote of confidence in a given block time. My perspective was also: as we dial up the storm, which blockchains will still be operating properly/sustainably assuming the storm is drawn out.
2 Likes
If the storm is drawn out, which blockchains come out the better has far less to do with their block time or any other technical merit, than with their community’s ability to socially re-coordinate under the particular conditions of the storm.
Ie the BCH community with the CHIP process and with a general high concentration of good actors would theoretically outperform Litecoin, but underperform ZEC if their centralised dev team was fine (everyone would just reorg under the main Foundation team) and massively overperform it if the ZEC main guys were inaccessible due to the storm (it would be complete chaos).
So block time isn’t really the deciding factor there. The better thing is to make the social layer as decentralised and well-practiced at coordinating as possible, and likewise distribute the technical infrastructure (in terms of experienced devs, mining hardware, nodes, major infrastructure providers like wallet teams) as dispersed as possible too.
5 Likes
Yes, if relevant people are available we can coordinate a raise of the block time in such a storm. I agree, a decentralized BCH community used to delivering changes helps resiliency, and with ticks it is a less risky change. For somewhat smaller storms (say 15s block propagation) then some miners will lose business, but other businesses like payment processors may be against a raise of the block time. If the change is contentious that may favor a drawn out status quo.
2 Likes
It’s also worth remembering, that in a persistent storm, a chain split isn’t actually that big of an issue. Blockchains are default resilient to that in large measure.
If 85% of people are on Chain A and 15% of people who are in their own little echo chamber fork off to Chain B, they can continue transacting and you just have two chains running. For all transactions that aren’t double spends and are just occurring among the 15% - those transactions can be replayed (and nobody is harmed, even for children of children of children transactions afaik) onto the 85% main chain once connection is reestablished.
If the two groups are silo’d, then there isn’t a lot of double spends or overlap that will create problems, and reconciliation will be fairly easy once you re-establish connection. The exact block the transaction is included in will change obviously, but the transactions themselves don’t - since they flow from the same previously unspent UTXOs or the related isolated children.
If the two groups have intermittent connection, then you do have more chance of overlapping problems but also you get more frequent chances to reconcile everyone up to the same state.
So either way the blockchain is fairly resilient to it, and usually able to reconcile nicely for good actors even with significant disruption.
4 Likes
Faster blocks and covenant-settled applications: evidence from DeFi, ZK, and privacy
I work on CashNotes (formerly BCH Cloak), a private note transfer protocol for Bitcoin Cash. Comparing its settlement model with Zcash highlighted where block time matters for covenant applications.
This is not an argument about payment UX generally. It is specifically about applications whose state transitions depend on confirmed covenant spends.
1. Covenant spends don’t get the usual zero-conf protections
BCH payments can often be accepted quickly because nodes relay double-spend proofs when conflicting spends appear. Bitgree, for example, waits four seconds for a proof before accepting.
But DSProof only covers transactions whose inputs are P2PKH with SIGHASH_ALL. The proposed ZCE has the same P2PKH-only constraint.
Covenant spends therefore sit outside that protection: AMM swaps, contracts that verify proofs, private note transfers, and other contract state transitions. For those cases, the DSProof specification’s guidance is to “wait for confirmation”.
The issue compounds when applications chain transactions, where each stage spends the output of the previous stage. If an earlier transaction is replaced, later stages disappear with it.
| Block interval | 1 confirmation: typical | 1 in 20 waits longer than | 3 chained confirmations: typical | 1 in 20 waits longer than |
|---|---|---|---|---|
| BCH today, 10 min | 6.9 min | 30 min | 27 min | 63 min |
| BCH at 1 min | 42 s | 3.0 min | 2.7 min | 6.3 min |
| Zcash today, 75 s | 52 s | 3.7 min | one transaction | one transaction |
| Zcash NU7, 25 s | 17 s | 75 s | one transaction | one transaction |
For covenant applications, the practical rule is roughly:
settlement latency ≈ number of sequential confirmed stages × block interval
There is an important distinction between confirmation count and accumulated work. The CHIP’s security analysis specifies one tenth the chainwork per block while preserving approximately the same chainwork accumulation per unit time. Ten one-minute blocks therefore accumulate approximately the work of one current ten-minute block.
That means one-minute blocks provide earlier, smaller increments of confirmation rather than making ten minutes of accumulated proof of work arrive sooner.
Effect of 1-minute blocks: strongly helpful when an application benefits from earlier confirmations; neutral where it requires the same accumulated chainwork as today.
2. Zero-knowledge applications
ZK applications can require multiple covenant transactions because verification and subsequent state transitions must fit BCH transaction and unlocking script limits.
There are two ways to reduce that latency:
- reduce the number of required transactions;
- reduce the time between confirmations.
New opcodes could eventually reduce transaction count, but CHIP-2025-05 covers secp256k1 arithmetic and leaves pairing and STARK verification to separate proposals.
Until then, block interval directly limits sequential covenant state transitions. A state machine that requires each parent to confirm can advance about six times per hour at ten-minute blocks versus about sixty times per hour at one-minute blocks.
The main concern is orphan rate. The CHIP estimates 0.41–1.94% at one-minute blocks.
Zcash offers a useful comparison. Zakura reported roughly 30% orphan rates during testing with 25-second blocks because proofs were being verified twice. After reusing mempool verification results, the rate fell to about 3.6% (Zakura 1.2.0).
BCH Node already caches script validation results from mempool admission and reuses cached results during block validation.
The remaining case I would like to see tested is blocks containing expensive transactions that verify proofs and that nodes have not already validated through their mempools. The CHIP considers this attack surface and argues that BCH’s VM limits and signature check limits bound worst case validation cost. It also scales maximum block size from 32 MB to 3.2 MB along with the shorter interval.
Those are useful analytical arguments, but Chipnet could provide empirical evidence that validation and propagation behave as expected when blocks contain significant amounts of proof verification.
Effect of 1-minute blocks: helpful for ZK applications because they reduce sequential settlement latency. Whether transactions requiring expensive proof verification impose a meaningful validation penalty at the shorter interval is a specific question that can be tested.
3. Proving time
Faster blocks do not make zero-knowledge proofs faster. They only reduce the confirmation delay after proving.
Zcash wallet developers report shielded proving times of roughly 142–550 ms on phones.
That distinction matters:
- if proving completes well within a minute, block time dominates user visible settlement latency;
- if proving or batching takes several minutes, reducing block time has less impact.
For a BCH application that proves quickly, a typical one confirmation wait falls from about 6.9 minutes to 42 seconds.
Effect of 1-minute blocks: helpful when proving is already fast; increasingly neutral as proving or batching becomes the dominant source of latency.
4. Competitive position versus Zcash
Zcash currently uses 75-second blocks, giving a typical one block wait of about 52 seconds.
NU7 moves to 25-second blocks and has been live on public testnet since 5 October 2026, with mainnet targeted for 5 November.
Its proposed Project Tachyon would allow block producers to aggregate shielded transactions without user coordination.
CashNotes uses a related model without a consensus change: users prove locally, then permissionless aggregators batch proofs and settle them through covenants. The difference is where aggregation occurs:
- Zcash aggregation can settle within block production;
- BCH aggregation may require multiple sequential covenant transactions.
For a three-stage BCH settlement:
- 10-minute blocks: ~27 minutes typical;
- 1-minute blocks: ~2.7 minutes typical.
That does not match a one block Zcash settlement, but it moves BCH from an order of magnitude disadvantage toward a difference of minutes.
Effect of 1-minute blocks: clearly helpful competitively. They do not erase Zcash’s latency advantage, especially at 25-second blocks, but they substantially narrow it for covenant privacy and proof applications.
Conclusion
For conventional BCH payments, faster blocks are less important because zero confirmation mechanisms already provide useful payment UX.
For covenant applications, the situation is different. DSProof and proposed ZCE protections do not cover covenant spends, and many applications require sequential confirmed state transitions. In those systems, block interval becomes application latency.
Moving from ten-minute to one-minute blocks would:
- reduce a typical confirmation from about 6.9 minutes to 42 seconds;
- reduce three sequential confirmations from about 27 minutes to 2.7 minutes;
- increase confirmation dependent state update capacity from roughly 6 to 60 updates per hour;
- substantially narrow BCH’s latency disadvantage for covenant privacy, DeFi, and ZK applications.
The security tradeoff is narrower than simply saying that faster blocks provide less security. The CHIP preserves approximately the same chainwork accumulation per unit time while dividing it into ten smaller increments: one tenth the chainwork per block and one tenth the maximum block size.
Its security analysis argues that most relevant properties scale with those changes. It also identifies effects that do not scale perfectly, particularly fixed network latency and the resulting propagation races.
That is the part I would like to see examined adversarially and tested on Chipnet. The question is not whether ten one-minute blocks contain roughly the same accumulated work as one ten-minute block; they do. The question is whether dividing block production into smaller, more frequent increments introduces practically significant behavior that the current analysis or assumptions do not capture.
Position: neutral, but strongly interested in being convinced
My incentives as an application developer point strongly toward one-minute blocks.
My goal with CashNotes is to make private payments and applications using cryptographic proofs on BCH competitive with what can be built on any chain. From that perspective, reducing settlement that depends on confirmations from tens of minutes to minutes or seconds would be a significant improvement.
What keeps me neutral today is narrower: I want stronger evidence that the change in block cadence and chainwork per block does not introduce a meaningful security disadvantage that outweighs those benefits.
The CHIP provides a substantial analytical case that security per unit time is preserved and it bounds several specific attack vectors. I would like to see that analysis subjected to adversarial review and, where possible, empirical testing, particularly around propagation, orphan behavior, and blocks containing transactions that require expensive proof verification.
If that evidence supports the CHIP’s security analysis, my position would move from neutral to strongly in favor. The application benefits are already clear to me; the remaining question is whether the security assumptions continue to hold under adversarial conditions and workloads involving substantial proof verification.
Sources are linked inline. The waiting times are closed form calculations from exponential and Erlang distributions, and I’m happy to share the script.
Disclosure: I drafted this with AI assistance, then reviewed, edited, and verified the arguments and figures against the sources linked above.
3 Likes
Side note, there’s an important distinction between minority and majority (or supermajority) attacker, see here for some follow-up discussion: CHIP-2025-03 Faster Blocks for Bitcoin Cash - #210 by bitcoincashautist
Above, @joemar_taganna independently replicated many of the CHIP’s claims, which actually made him flip to support: CHIP-2025-03 Faster Blocks: gathering statements of support (and dissent) - #70 by joemar_taganna
Today, @bitjson independently discovered an error in my specification, and posted about it literally ~50 minutes after I had pushed the fixing commit. I didn’t know he had found it, nor that he was about to post about it. That actually gives me confidence:
- Other people are watching / reviewing, and they would actually catch something I may have missed.
- The only issue found so far is one I had already closed, and it was a two-line fix.
And I caught it because producing reference implementation and test vectors is part of the CHIP process, as is people reviewing it, and it all worked as it should.
He’s also preparing to support us by launching a “tempnet” as soon as code-build is ready, so we will have opportunity to do some testing even before forking chipnet.
On the chainwork distinction — you’ve stated it exactly as the CHIP does, and there’s a section that works through the consequence: Confirmation Count vs Tick Thresholds. The short version is that height-mode locktime and sequence are normalized to 600-tick units, so a contract asking for “+1” gets ten 1-minute blocks rather than one 10-minute block — the same wall-clock delay with more underlying confirmations, hence more statistical finality against a minority attacker, not less.
For the accumulated-work case specifically, parking and finalization are tick-scaled, so their wall-clock thresholds don’t move: parking lock-in stays at 2,400 ticks (~40 min) and finalization at ~120 min. An application that needs that depth waits the same either way; one that only needs a few confirmations gets the 10× improvement.
On expensive proof verification: the analytical answer is that both the per-block limits and the block size scale 10× with the interval, so worst-case validation time as a fraction of the interval is invariant; the only non-scaling term is fixed network latency, which is already the dominant term in the orphan model. So there’s a predicted answer, not just an open question — the orphan rate should land in the modeled 0.4–1.9% band at 60 s. Chipnet (and @bitjson’s tempnet) will produce the measurement.
On the Zcash orphan data — that’s a stronger corroboration than it may look. 3.6% at 25 s with cached verification implies an effective propagation time of ~0.92 s, which sits inside the CHIP’s modeled band (0.25–1.18 s) and better than the CHIP’s pessimistic 1.94% case, which assumes zero mempool overlap. Zcash’s 30% → 3.6% before/after caching is the CHIP’s “100% missing” vs “synced” distinction measured on a live chain. I also hopped on their forum, shared some notes, and predicted they could get 4.26% network orphan rate with their 25 s blocks: Zcash Block Time Reduction Appears Safe for NU7 w/ Zebra Only Devnet - #4 by bitcoincashautist - Zebra - Zcash Community Forum — that prediction implies ~1.09 s propagation, within ~8% of the CHIP’s own pessimistic 1.18 s assumption, derived independently for a different chain.
3 Likes
Hi,
This is my first post, I don’t know how to reply properly.
I support faster blocks, I have been struggling a lot with 1h30’ waitings for gettin 1 single conf,… it its frustrating.
I know there is a lot of fear with this one but I trust the devs and OGs that also supported this inititative.
We need it. Newcomers who come from blockchains that gets 1 conf with 1-3 secs can’t come to bch make a cross chain swap and wait 2 hours, that’s lame, that’s horrible, feels like a scam. It causes real pain. This issue must be addressed. “hey, but 0-conf blablabla” yeah, nothing works with 0-conf and 0-conf can still be a thing, we are not eliminating that, thank you for your useless opinion.
Even bch defi needs 1 conf to solve some conflicts. Cauldron uses 1 conf to solve when 2 swaps happen at the same time. ParyonUSD uses 12 conf to blabla… people who think that can ignore conf time make me think that they are not actively using bch… well I am, and I can’t stand 1h’30m waits for 1 conf. let’s go with it. I SUPPORT faster blocks.
6 Likes
Welcome to BCH research! You can highlight a section of text and then click “quote” to quote it when writing your responses. It’s not the most intuitive system.
“thank you for your useless opinion”. 
Not the most diplomatic way of saying it, but you’re absolutely right, all this “what about 0 conf” is a completely pointless red herring since nothing is changing with 0 conf for anyone who is satisfied with 0-conf in any and all circumstances.
3 Likes
Yup, Faster blocks are much overdue. I honestly think we would have significantly higher adoption by now if we put in faster blocks a few years ago. It could have gone in along side the ABLA upgrade back in 2023 or even before.
5 Likes
Historical nit: ABLA went live in 2024, not 2023.
But yeah you can see how much work is going in to convince everyone of this idea even today. No way we would have been able to get everybody to agree to it at the same time as CashTokens or ABLA (which themselves were big and impactful changes which took a ton of work), especially when the community back then was far more traumatised and fragile having just had 3x chainsplits and CoinFlex meltdown in recent memory.
So 1 minute blocks is coming at just the right time. But if we have to delay a whole extra year that is going to be a real loss of momentum.
4 Likes
For ParyonUSD we’ve written a new blogpost: Why We Support 1-Minute Blocks
ParyonUSD supports the CHIP by @bitcoincashautist to activate 1-Minute Blocks on Bitcoin Cash. We’ve called faster blocks likely the biggest win for DeFi on Bitcoin Cash, and we still think so.
Faster confirmations#
The main reason we think 1-minute blocks are the biggest win for DeFi is race conditions. When several users act on the same contract at the same time, only one of their transactions can go through, and until the next block nobody knows for sure which one it was. With 1-minute blocks, that uncertainty clears in about a minute instead of ten.
With 10-minute blocks, waiting more than half an hour for a confirmation is not uncommon: 5% of waits take that long. After the upgrade, the same 5% take more than 3 minutes, and a half-hour wait practically never happens.
We also included a specific section on how our smart contracts with timelocks are impacted
What it means for redemptions#
Every ParyonUSD redemption waits 12 blocks before it can be finalized. Assuming steady hashrate, 90% of redemptions today take between about 1 and 3 hours. After the upgrade, those 12 blocks become 120 one-minute blocks (more on that below), and 90% land within about 20 minutes of the 2-hour mark.
The bigger gain is what happens during that wait. Redemptions go to the loan with the lowest interest rate, and the wait gives a borrower who pays a proper rate the time to have a wrongly targeted redemption moved to the right loan. That only works if their transaction gets mined, so what protects borrowers is how many different miners find a block in that time. With 120 blocks instead of 12, nearly every sizable mining pool gets a turn, which makes it much harder to keep a transaction out.
Read our full reasoning and support statement here:
10 Likes
I have not done a lot of in depth studying of the subject, so it may have already been covered. But, your example points to another issue that also needs to be resolved, that issue is having more accurate block times / block adjustment.
My example is that Litecoin has 2.5 min block times, so it is already faster that BCH, but it’s equally frustrating when those blocks take 5, 10 or 20 minutes, and it will be equally frustrating for BCH when 1 min turns into 5 or 10 min, and that can happen for several blocks in a row, forcing you to wait 20 or 30 min for 6 blocks when you were planning only 6 min.
2 Likes
Since mining is a Poisson process, probabilities for exceeding a factor of target time are left unchanged:
| Factor | Probability | Approximate Odds |
|---|---|---|
| 1 | 36.79% | 1 in 3 |
| 2 | 13.53% | 1 in 7 |
| 3 | 4.98% | 1 in 20 |
| 4 | 1.83% | 1 in 55 |
| 5 | 0.67% | 1 in 148 |
| 6 | 0.25% | 1 in 403 |
| 7 | 0.09% | 1 in 1,097 |
| 8 | 0.03% | 1 in 2,981 |
| 9 | 0.0123% | 1 in 8,130 |
| 10 | 0.0045% | 1 in 22,222 |
With 1-minute target we will average 1440 blocks in a day, meaning the 8x tail case (8 minute wait) should happen about once in 2 days, the 9x once in 5 days, and the 10x (10 minute wait) once in 15 days.
Variance is lowered with number of confirmations, e.g. for 6x1min case there’s only 0.01% probability of the total wait exceeding 20 minutes, 0.1% probability of exceeding 16 minutes, and 1% probability of exceeding 13 minutes.
“Tempnet” stats page is up thanks to @Rufitnes, stats look good!
3 Likes
One-minute blocks? Not yet.
CHIP-2025-03 proposes lowering Bitcoin Cash’s block interval from ten minutes to one. The problems it cites are real, but the change doesn’t eliminate them; it rescales them. In exchange, it modifies a foundational constant, adds a permanent abstraction, and shifts costs nobody has quantified yet.
What I’m asking for is concrete: that it not lock in on November 15 and that it be discussed again for a future upgrade. It is not a “never”: it is a “not yet.”
Thank you for the thorough review, I love the interactive charts for wait time probabilities you put in!
And thank you @BitcoinCashPodcast for a great response/rebuttal, which addresses the details well.
That leaves me just with addressing the headline and main request 
What is to gain by postponing? What would that buy us? Which part of the problem space is not explored and understood well enough by the CHIP? Studies are meant for things that need further understanding — what part of it needs further understanding that would justify further delay? How I see it, it’s already been delayed for 11 years (first proposed by Gavin Andresen in 2015!):
Jeepers creepers, I can’t have a half-baked opinion on ANYTHING anymore, can I?
I do think 1-minute blocks would pass a cost/benefit analysis; benefits would be less variance in confirmations-for-whatever-level-of-security (e.g. wait 60 1-minute confirmations has much lower variance than wait 6 10-minute confirmations).
I think it would probably encourage mining decentralization. Easier to solo mine if you’re competing for 1.25 BTC 1-minute block instead of a 12.5 BTC 10-minute block.
… that might not be true, would have to run the numbers for disadvantage due to higher orphan rates…
I have no opinion on whether or not the adjust-difficulty-every-2-weeks should be changed if the block time was changed, but that’s something else to think about.
Disadvantage is that SPV nodes would have to download more headers, but that’s not a huge disadvantage and I think the benefits of an SPV node finding out about a re-org / double-spend quicker probably outweigh them.
One minute is not fast enough for real-time payments, so that’s neither an advantage or disadvantage.
Whether or not to change the 10-minute block time is a separate issue (with its own pros and cons) from whether or not the max block size should change. Status-quo with a faster block time would be 100K max blocks, each with one-tenth the current mining reward.
Worth closing the loop on that quote: Gavin named the exact three questions still open in 2015 — does it pass cost/benefit, are the orphan rates tolerable (“would have to run the numbers”), and does the DAA need rethinking — and the CHIP is those numbers. It also goes after a cost he accepted rather than disputed: SPV header growth, which he wrote off as “not a huge disadvantage,” is being removed instead of tolerated, via CHIP-2026-02 SHV.
And that mitigation is further along than the debate assumes. Header merkle proofs for Electron Cash are already implemented and awaiting review; Jonathan has SHV working in his library stack; and XO already ships it — “SPV for payments and SHV for headers, providing independent verification across Bitcoin Cash networks.”
What is to lose by postponing? We’d pay at least 1 year of opportunity cost and of burdening everyone’s attention for at least 1 year more (and stealing attention from other CHIPs), and with risk of postponing it indefinitely, for what gain? Everything is almost perfectly aligned for '27 activation. If not now, then when?
My request is concrete: that CHIP-2025-03 not lock in on November 15, 2026, and that it be discussed again for a future upgrade, once the alternatives have been exhausted. To activate a change like this, the benefits should clearly outweigh the sum of the costs.
Why should that be a requirement? Exhausting the alternatives first has a tremendous cost and a speculative benefit. Such a requirement places 1-minute blocks as a last resort change, whereas CHIP argues it’s a first resort change – a change from which everything downstream benefits, even the alternatives.
And CHIP’s whole thesis is that benefits do outweigh the costs, and it shows how costs are mostly well contained, while potential benefits are unbounded. Existing users benefit first, the other day I suffered the same “surprise, your 0-conf has just become 1-conf” UX as @9500 did:
the other day, prompt cash went down for nanogpt and I had my 0conf deposit surprisingly become 1conf with their fallback provider - and it had that annoying 30min thing and of course the block happened to be “lucky” and I had to open support ticket
So the first benefit is immediate improvement to the UX of all existing BCH users. With 1-min blocks, that checkout would’ve cleared in 3 minutes.
Secondary immediate benefit is gaining crypto mind-share for which we compete with all other cryptocurrencies.
Third is the potential to capture more users from multi-coin service conversion pipelines, e.g. Trust Wallet has 50M+ Android downloads, but to them BCH is a 10-min coin since multi-coin wallets prefer not to implement 0-conf — it makes engineering more complex for them. It’s a self-custodial wallet but they won’t even show you an incoming TX until it gains 1-conf! After 10-min BCH UX, will their users look for a better wallet or for a better coin?
2 Likes
Ian from BCH Argentina added his support. Ian 🇦🇷 on X: "I support CHIP-2025-03 (Faster Blocks) for November! BCH must keep evolving. Moving from 10-minute to 1-minute blocks will improve UX and unlock new possibilities. Lock-in in November, activation in May 2027. https://t.co/A93XzrJ4hJ @ConsensusCash" / X
3 Likes
As a habitual gambler, I can tell you that your statistics do not win a game. Random is something that is next to impossible for a human to imagine. A coin toss with 1:1 odds could have a streak of heads for 100 flips. But statistics aside, my example of Litecoin would account for the reduced wait times, but it’s not about the time it takes, it’s about the expectation. If you plan to meet someone at 1 PM and they don’t show until 1:30, but you scheduled another appointment for 2 PM and need 30 min to travel, then it doesn’t matter that they were “only” 30 minutes late. What matters is that your expectations were not met. The shorter time differential you mention is valid, but in the crypto world where 0.5 second blocks exist, 1 minute is an eternity, unless that is the expectation. Really, the same can be true of 10 min, but that depends on the use case.
If, as the BCH Podcast likes to tout, BCH is the ‘world’s reserve currency’, it really needs to be reliably functional using primitive electronic transmission such as shortwave, where 10 min would likely be necessary. Maybe faster blocks could be brought on as an extension block, or sidechain? I sometimes wonder, if the timing of technology allowed, that the blocksize war could have been solved with the same, for BTC.
1 Like
Several of us brought up the topic of resilience in the other thread. There is a section about it in the CHIP: System Rigidity and Catastrophic Resilience
For a HAM radio situation specifically, I think the main challenge would be the bandwidth, not the latency. Bandwidth and data usage is driven by network transactions per second. For latency, you can simply wait a few more confirmations.
For example, faster blocks could actually help you in a low bandwidth situation because security converges faster for a minority attacker scenario. Lets say you need 6 confirmations + 1 hour of network hash time to be safe. Well, with 10 minute blocks that could potentially take twice as much time and bandwidth to get those 6 confirmations + hash time whereas with 1 minute blocks it would be exactly 1 hour.
4 Likes
No it doesn’t. That’s nice if it is, but it’s cutting off our nose to spite our face to optimise for some kind of disaster-scenario apocalypse technosurvivability when doing so would hinder our ability to win in any other non-apocalypse (ie. reality). Some preppers build a perfect bunker in their house and die having never lived. Does the existing USD global financial system run on short ham radio? Of course it doesn’t. Be the winner in the real world, the 99.999% likely to occur world, rather than trading away your odds in that race to be the paranoid winner of a reality that is almost certainly not going to occur (and even if it does, we’ll all have far bigger problems).
https://bitcoincashpodcast.com/faqs/Other/what-if-the-internet-goes-out
Yes, 1 minute blocks is slow compared to many coins in crypto. But the real world has a diminishing returns floor. Between about 0 and 3 seconds, everyone sees things as “instant”. For that we have 0 conf. 1 minute is the best we can do on the confirmation requiring use cases (… for now), and the ticks system means we can trivially upgrade that in future as it becomes feasible.
2 Likes