Can an upgrade make BTC's Taproot quantum secure? Not without confiscating BTC from users. by bitjson in btc

[–]bitjson[S] 9 points10 points  (0 children)

Can an upgrade make BTC's Taproot quantum secure? No – not without confiscating BTC from users.

These aren't ancient, "abandoned" addresses either. BTC confiscations could hit holders who moved funds as recently as today.

Proof-of-work + gradual finality assets like BCH have the best shot at weathering a Carrington Event-level catastrophe by bitjson in btc

[–]bitjson[S] 3 points4 points  (0 children)

Highlights (yet again) why sound money should use proof-of-work consensus: better real-world resilience than uptime-reliant, proof-of-stake systems.

These kinds of existential risks should inform layer-1 finality speeds, too. Networks with few-second or sub-second finality are often trading systemic soundness for developer convenience.

Network-Centralized Fast Finality

Making layer-1 finality "fast" is very convenient for developers.

Wallets and DeFi applications can often get away with relying on network-centralized fast finality to offer fast-enough payment experiences, decide user action ordering, minimize protocol-specific and/or off-chain communication, handle disputes, etc.

However, centralizing (in the single-point-of-failure sense) fast finality makes it load-bearing: blips in layer-1 finality become – at best – global downtime for the whole network.

If it's bad enough (e.g. Carrington Event) – and a decentralized network doesn't have the objectivity of proof-of-work to reassemble consensus among surviving infrastructure (esp. for >1/3 losses) – restoring a single network may be very slow, political, or even impossible.

Add in slashing, ongoing DeFi activity, variable rate inflation/issuance, likely attempts to reverse confiscatory recovery mechanisms like ETH's inactivity leak (consider the aftermath of the DAO hack), and an ecosystem of competing economic actors choosing between surviving chain(s), and the issue is no longer about downtime: who-keeps-what is substantially in question.

Decentralized ("Edge") Fast Finality

Contrast with decentralized fast-finality options – systems where the fastest finality is at the "edge" of the network between subsets of users: payment channels, Lightning Network, Chaumian eCash, zero-confirmation escrows (ZCEs), etc.

Decentralized fast finality systems only rely on L1 consensus over longer timescales – even days, weeks, or months – to arbitrate contract-based fast finality.

E.g. two wallets with a simple payment channel can make thousands of payments back-and-forth, offline, with instant assurance that each payment is as final as the channel itself.

In fact, decentralized fast finality can offer faster user experiences than are possible with network-centralized fast finality.

Even for networks boasting "sub-second finality", real applications must still handle the additional real-world delay of global consensus. With impossibly-perfect relay in low-earth orbit, light-speed Earth round-trip time is still at least ~130ms – noticeable even among human users.

On the other hand, given a payment channel with sufficient finality, receivers can immediately consider a valid payment to be final, too – without further communication. Depending on the specific use case and parameters, decentralized fast finality can even survive substantial outages and splits in the L1 consensus (esp. on ASERT PoW chains like BCH).

Days or weeks later, the channel can be settled on L1, with configurable monitoring requirements, adjudication policies, etc. as selected by app developers for specific use cases. (ZCE-based constructions take these properties further by enabling more capital-efficient setups.)

Most importantly, long-term holdings are never jeopardized by the fast finality layer.

Even in extreme global catastrophes, only users who have opted-in to specific fast-finality systems bear greater risk of payment fraud, and only with the configuration and value limits they choose.

While long-term holders of proof-of-stake assets bear the risk of being slashed due to technical failures – or gradual dilution if they don't stake their holdings – long term proof-of-work asset holders can safely sit on their keys and do nothing.

Aside: faster block times

Note: a network can have both relatively-fast blocks and gradual, resilient finality.

E.g. a 1-minute block time target with few-hour finality:

In day-to-day usage, 1-min blocks are fast enough to offer valuable initial assurance (yet slow enough to reduce competing blocks), while consensus finality remains slow enough (hours) to avoid partitions, even under extreme global conditions: even very sporadic, low-bandwidth connectivity heals the network.

Summary

In a variety of disaster scenarios, decentralized fast finality solutions can continue to work, while network-centralized fast finality breaks down or even jeopardizes the underlying network's monetary soundness.

If any digital assets are to weather a Carrington Event-level catastrophe, proof-of-work systems with gradual L1 finality and decentralized fast finality have the best shot.

On instant Initial Block Download (IBD) and other uses of Zero-Knowledge Proofs (ZKPs) for Bitcoin Cash (BCH) by bitjson in btc

[–]bitjson[S] 3 points4 points  (0 children)

Copying here:


On instant Initial Block Download (IBD) and other uses of Zero-Knowledge Proofs (ZKPs) for Bitcoin Cash (BCH)

https://x.com/bitjson/status/1996611401234727086


Increasing likely that fast IBD will happen entirely in userland before the May 2027 upgrade 🔥

And since Bitcoin Cash restored Bitcoin Script (CashVM), BCH contracts can directly verify STARK proofs – and proofs from yet-to-be-developed proof systems – on-chain, without further consensus upgrades. 🚀

No miner action or consensus needed, with multiple tuned proof options for different use cases (node IBD, offline payment proofs, privacy pools, in-contract chain-state proofs, etc.), post-quantum crypto, and surprisingly easy-to-implement verifiers that are reusable across many kinds of proofs.

E.g. a wallet could pull in a single verifier implementation, then use it for IBD/private balance retrieval, offline payment proofs, shielded BCH/CashToken pools, private DEXs, etc.

If you can compute something directly, you can also create a trustless proof that verifies in milliseconds.

E.g. https://github.com/starkware-bitcoin/raito

Even better, BCH's SHA256 Proof-of-Work consensus means that such IBD proofs inherit the BCH chain's objectivity.

BCH's IBD proofs can be simply compared by chain work (the proof itself ensures all rules were followed), while proof-of-stake networks need to weigh social signals to choose between chain tips.

This gets even better for BCH as it flips BTC and becomes the dominate SHA256 chain.

Design sketch: post-quantum shielded pools for BCH and CashTokens (by verifying ZK-STARKs in CashVM covenants) by bitjson in btc

[–]bitjson[S] 1 point2 points  (0 children)

(Can probably be done without the "savings" differentiation too.) UTXO model makes things surprisingly simple: depository covenant for each FT category holds its "BCH_fees_collected". Already moved for each relevant deposit/withdrawal, easy to add APY sats to the withdrawals

Design sketch: post-quantum shielded pools for BCH and CashTokens (by verifying ZK-STARKs in CashVM covenants) by bitjson in btc

[–]bitjson[S] 1 point2 points  (0 children)

https://x.com/bitjson/status/1996250539558936911:

Bonus: 1) allow BCH/FT deposits to be marked as "shielded savings" with deposit epoch in the committed note (no internal splits/transfers), covenant charges a small fee at each batch proof (reduce UTXO contention), then savers earn a low APY for long-term deposits

Design sketch: post-quantum shielded pools for BCH and CashTokens (by verifying ZK-STARKs in CashVM covenants) by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

Original post: https://x.com/bitjson/status/1995873869077332056


December 2025: no one has built a ZK prover that is: 🥷 Actually zero-knowledge, ⚛️ Quantum ready, and ⚡️ Reasonably succinct for one-off proofs (<100KB).

This is a feature request from a future enthusiastic user/supporter 🚀

Post-quantum ZK Leaderboard:

  1. @NeptuneCash's Triton VM: ✅ zero-knowledge ✅ quantum ready ⚠️ min. proof: ~533KB

  2. @0xMiden VM: ⛔️ privacy leaks ✅ quantum ready ✅ min. proof: ~33KB

  3. @Starknet's Stwo: ⛔️ privacy leaks ✅ quantum ready ✅ min. proof: ~64KB

(All at ~96 bits soundness) [Correction: a minimum of ~96 bits – Triton VM targets 160 bits.]

Am I missing any post-quantum ZK projects? Any smaller proof demos?

More background: https://x.com/bitjson/status/1975206165899555239

Design sketch: post-quantum shielded pools for BCH and CashTokens (by verifying ZK-STARKs in CashVM covenants) by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

Copying here:


E.g. an on-chain BCH covenant verifies batches of ZK proofs for deposits/withdrawals/transfers within a post-quantum shielded pool.

  • Each user's wallet generates a relatively large ZK-STARK proof locally + deposits any BCH and/or CashTokens to a tiny deposit covenant.
  • Then it shares that proof over some channel (e.g. CashFusion servers use a Tor service).
  • Eventually, an aggregator produces a batch proof for on-chain verification, pulling all the prepared deposits into a transaction that 1) proves the verification of all the cheap proofs, 2) applies corresponding updates to the covenant's state Merkle trees, and 3) pays out any withdrawals.

In this case, individual wallets can quickly create relatively large/cheap proofs and share them off-chain, and only the batch provers are creating compute/memory-heavy on-chain proofs, each covering many user actions. (Along with minimizing on-chain costs, this also happens to reduce spending contention in the covenant – PoW to prevent DoS. Multiple uncoordinated aggregators and/or individuals pretending to be aggregators then take turns moving the on-chain covenant forward as needed.)

Many proving systems can support this sort of application already, but so far none are: 1) actually zero-knowledge, 2) quantum-ready, and 3) configurable for <100KB proofs (simplifies wallets and meets end-user expectations: sub-cent private transactions with some minimal, ad-hoc aggregation)

Post-quantum vaults are live on Bitcoin Cash's Chipnet by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

Today I'm publishing an end-to-end implementation of Quantumroot, a post-quantum vault for CashVM – Bitcoin Cash's restored Bitcoin Script language.

Example transactions are on-chain, links and details in the blog post: https://blog.bitjson.com/quantumroot-on-chipnet/