Bitcoin will fail as mass, non-custodial Medium-of-Exchange
When we look at the past 5-10 years, Bitcoin’s trajectory is quite clear. Capture goes up, freedom goes down.
In this article I’ll explain why Bitcoin will fail as mass, non-custodial Medium-of-Exchange and will propose a better mental model.
This article was inspired by a relatively good discussion between Simon Dixon and Steve Patterson in which they spent the better part of 2 hours indirectly talking about the Coordination Tax.
Simon Dixon’s view is broadly: “Well, Bitcoin isn’t perfect but it’s the best we’ve got“.
And in many, not all, aspects it is the best we’ve got. The question, however, is: is Bitcoin good enough? Because it can be the best we’ve got and still fail as mass, non-custodial Medium-of-Exchange.
When we look at the past 5-10 years, Bitcoin’s trajectory is quite clear. Capture goes up, freedom goes down.
Unless you clearly define why that is (the Coordination Tax), nothing will change for the better.
Otherwise, we’ll be stuck in an infinite loop of blocksize wars, spam vs “art” wars, post-Quantum upgrade wars, taint wars, etc.
For more context on why/how Bitcoin is captured, feel free to read any of the following articles:
Is Bitcoin decentralized & secure or is it allowed to look that way
Bitcoin’s mining centralization problem (Hashrate ≠ Freedom)
How Bitcoin’s developers are attacking its Sovereign/Monetary use
To understand why Bitcoin will fail as mass, non-custodial Medium-of-Exchange, we have to understand the Coordination Tax.
The Coordination Tax
Three Stacked Systems
S₀ Protocol: consensus rules, Proof-of-Work, supply.
S₁ Policy: relay/mempool defaults, mining templates, wallet behaviors.
S₂ Perimeter: banks, clouds, app stores, ISPs, payment networks, tax law, PR.
Security: S₀ is math; S₁/S₂ are sociotechnical.
Tax: recurring human + legal + distribution cost to keep S₁/S₂ aligned with S₀’s ideals.
Attacker asymmetry: One cheap perimeter tweak (Acceptable Use Policy line, bank heuristic, pool template) can shift millions. Defenders must hold all fronts, all the time.
Why S₀ Protocol strength can’t save S₁ Policy/S₂ Perimeter
Local vs global coordination: Miners, relay nodes, wallets, exchanges, banks, clouds, app stores, telcos, and tax authorities don’t share one incentive. A single perimeter actor flipping a switch (bank heuristic, pool template, app-store rule) moves millions of users in a day. Defenders must hold every front forever; attackers need one decisive lever once.
Defaults beat ideals: Users take the path of least friction. If default wallets rank KYC UTXOs, if exchanges block “tainted” coins, if pools adopt filtering templates, S₁ (Policy) drifts away from S₀ (Protocol) without a hard fork — just through configuration and distribution.
Paperization gravity: ETFs, futures, custodial wallets, and stablecoin rails give the appearance of BTC exposure with zero S₀ (Protocol) habits (keys, fees, coin control). Capital migrates there automatically: cheaper compliance, fewer CFO headaches, friendlier UX. Result: price discovery migrates off self-custody.
Concrete choke points (how it actually gets steered)
S₁ — Policy layer
Relay/mempool policy: default size/weight filters, non-standard script flags, pinning/replace-by-fee knobs — tiny changes reprice whole classes of transactions; spam becomes “policy”.
Mining templates & pool policy: OFAC-style blocklists, template clients, or “ethical mining” scorecards throttle certain flows; hash is centralizing in a few pool coordinators.
Wallet behaviors: coin selection/labeling, change address treatment, default payjoin support (or lack thereof), fee estimator biases. Default UX narrows what the network effectively allows.
S₂ — Perimeter
App stores: one policy change can bury non-KYC wallets from discovery; “enterprise build” isn’t a mass-market workaround.
Banks & payment networks: Suspicious Activity Report (SAR) heuristics, de-banking of off-ramps, ACH/wire throttles.
Clouds/ISPs: ToS enforcement on archival nodes, block explorers, lightning relays; DPI throttles on known ports.
Tax/law: lot-tracking burdens, micro-tx taxation, reporting forms, travel rule on custodians; courts treat non-provenanced coins as higher risk collateral.
PR & narrative: “Safety”, “child protection”, “ransomware” frames ratchet Overton windows. Users self-censor.
Why the attacker’s job is easier
Asymmetric cost function: Changing one default (e.g., “marketplaces must list only travel-rule compatible wallets”) costs a ministry one memo; defending requires thousands of open-source maintainers + wallet teams + exchanges + educators to respond coherently.
Short feedback loops: Acceptable Use Policies and risk memos push behavior this quarter. Protocol governance moves in years.
The Five Fronts (where defenders burn out)
Work: review/patch clients, police mempool, ship spam-resistant knobs without censorship handles, audit pull requests, maintain forks, steward BIP norms.
Why hard: deep expertise, zero comp, reputational crossfire.
Attack edge: one permissive relay/template outsources cost to the network.
Work: template diversity, resist filtering, monitor policy clients, non-custodial payouts, decentralize hash.
Why hard: legal pressure, business incentives; hash follows cheap energy + friendly jurisdiction.
Wallet & UX Sovereignty
Work: default-private, default-self-custody, node-aware wallets; app-store survival; inheritance/backup UX.
Why hard: legal/compliance + distribution negotiation; users prefer custodial ease; app stores can throttle.
Legal/Policy Perimeter
Work: litigate node liability, transmitter claims; comment on rules; push Medium-of-Exchange tax relief; defend Lightning/channel treatment.
Why hard: years-long fights, donor fatigue, low immediate payoff.
Social Consensus & Comms
Work: norms around soft forks, spam policy, inscriptions, fee defaults, client choice; counter coordinated media/legal campaigns; fund devs without capture.
Why hard: tribal splits, reputational warfare, infinite time sink.
Result: Offense needs one hole; defense must hold all five.
Cheap Perimeter Switches (why control scales)
App-store levers: throttle updates, scary prompts, ranking friction for non-KYC wallets → most new users default to custodial.
Bank heuristics: auto-flags on coinjoin/Lightning ramps; delays; Enhanced Due Diligence (EDD) → “ETF easy, self-custody hard”.
Pool policy clients: insurer/utility guidance → template convergence; steerable settlement without declarations.
Tax/reporting defaults: self-custody = paperwork/audits, custody = simple → behavior at scale.
Cloud/CDN throttles: ToS/rate-limits on wallet servers/RPC → degraded sovereign UX.
Content liability blending: “node = distributor” narratives chill public nodes.
Each is policy-cheap and mass-effective; court challenges are slow.
Concrete examples of the Tax
Spam-vector economics: cheap witness/OP_RETURN bloat; defenders must craft nuanced policy; attackers call it “market choice”.
Template monoculture: big pools converge on similar policy clients; transaction selection becomes policy-sensitive.
App-store soft bans: non-KYC wallet updates lag/fail; user migration to custodial by default.
Bank heuristics: “coinjoin = Enhanced Due Diligence” — users abandon coin control.
Where this equilibrates
Price corridor: cyclically positive, blow-offs capped, floors defended when convenient.
Usage: Store-of-Value inside custody; Medium-of-Exchange in niches; sovereignty survives as a minority practice.
Settlement: increasingly steerable (pool templates + AML analytics + KYC routing).
Narrative cadence: “Regulatory clarity” pumps → new controls ratchet → paper share rises → realized volatility grinds down → repeat.
How do you minimize the Coordination Tax?
You can only win by making S₁ (Policy)/S₂ (Perimeter) so thin, boring, and hard to steer that the Coordination tax collapses.
So: design the system so that:
There are fewer knobs to twist at S₁ (Policy).
There are fewer viable choke-points at S₂ (Perimeter).
The path of least friction for normal humans is already Protocol S₀-aligned (self-custody, private, fungible).
Any attempt at partial capture quickly degenerates into “ban everything or tolerate everything”, instead of “just KYC this subset”.
Below is how I’d go about designing that.
1. Re-framing the design goal
I defined:
Coordination Tax = recurring human + legal + distribution cost to keep S₁ (Policy)/S₂ (Perimeter) aligned with S₀’s (Protocol) ideals.
So the design target isn’t “max decentralization” in the abstract; it’s:
Minimize the surface where humans must coordinate forever.
Concretely:
Minimize policy degrees of freedom at S₁ (relay, mempool, templates, wallet defaults).
Minimize reliance on chokable S₂ (banks, app stores, clouds, ISPs, Virtual Asset Service Providers).
Maximize situations where any partial control == obviously full control, so users can cleanly adapt (go fully grey) instead of dying by 1,000 paper cuts.
Call that Coordination-Tax-Optimized Digital Cash (CTO-DC).
2. Threat model
Attack vectors on any digital cash:
Policy clients: big relay/mining/validator nodes converge on censoring templates.
Wallet defaults: KYC wallets/wallet SDKs adopt “travel-rule compliant”, taint-aware behavior.
Perimeter levers: app stores, banks, telcos, clouds, tax code, Suspicious Activity Reports (SAR) heuristics.
Paperization gravity: ETFs, custodial wallets, synthetic exposure, stablecoin wrappers.
Narrative levers: “child exploitation”, “terrorism”, “sanctions”, “ransomware”.
Goal: design so that even if those levers are used, they don’t change the effective asset very much. Either they fully ban it (overt war) or they inadvertently empower the grey zone. No long, high-friction middle.
3. High-level design principles
Think in principles before primitives.
P1 — Privacy & fungibility by construction, not by habit
If surveillance can reliably distinguish “good” vs “bad” coins, S₁ (Policy)/S₂ (Perimeter) will always drift to “good only”.
So: all transactions must look like each other:
No transparent subset as “legacy mode”.
No visible amounts or script opcodes per tx.
No address types that reveal more metadata.
This collapses the main control trick: “we only KYC or de-bank these flows”.
Make the policy choice binary: ban the entire asset, or accept that everything is indistinguishable.
That kills a huge portion of the ongoing Coordination tax (no taint wars, no heuristic creeping).
P2 — Thin, deterministic S₁
Where Bitcoin leans on:
configurable mempool policies,
open-ended script,
many “non-standard” vs “standard” knobs,
you want:
minimal scripting, ideally fixed templates.
no relay-policy discretion beyond a single, mechanical rule (“valid + fee ≥ f(size)” gets gossiped).
no on/off flags for weird tx types (e.g. no OP_RETURN garbage).
The question to ask for every S₁ (Policy) toggle:
“Will humans have to argue about this knob every two years while regulators push from behind?”
If yes → push it into S₀ Protocol (formal rule) or kill it.
P3 — Default self-custody, not heroic self-custody
Most people follow defaults:
If custodial/KYC rails are dramatically easier, capital and usage migrate there.
Then S₁ (Policy)/S₂ (Perimeter) capture those rails, and the nominally “uncensorable” core is a museum piece.
So:
The easiest UX path (first wallet, first payment, inheritance, backup) must be non-custodial.
Custody should be harder: more friction, risk, complexity vs a good self-custody baseline.
That flips the “path of least resistance” gradient.
P4 — Minimize S₂ (Perimeter) dependencies: many weak perimeters > few strong ones
You won’t fully escape S₂ (Perimeter), but you can choose:
many small, messy perimeters (mesh, sideload, web, SMS, LoRa, cheap boxes, etc.),
instead ofa handful of clean, chokable perimeters (just iOS/Android app stores + 5 banks + 3 clouds).
Design for organic diversity of access so that no single policy switch moves “millions in a day” in the way I previously described.
P5 — Make paperization structurally unattractive
If base-layer usage is:
slow,
expensive,
UX-hostile,
then:
paper wrappers (ETFs, custodial lightning, yield accounts) win by default.
So design Coordination-Tax-Optimized Digital Cash such that:
day-to-day Medium-Of-Exchange is actually viable at the non-custodial edge,
and large, passive “exposure” demand is explicitly discouraged.
Default: “hold keys or GTFO” at the design level.
4. Concrete blueprint: Coordination-Tax-Optimized Digital Cash v0.1
I’ll walk layer by layer with specific choices.
4.1 S₀: Core protocol
4.1.1 Consensus / base architecture
Still Proof-of-Work or some very simple Sybil-resistance.
PoS makes S₁/S₂ capture easier (regulated staking pools, whitelisted validators, bond confiscation).
Keep block size + interval in the “low-resource, globally replicable” zone:
E.g. 1–2 MB equivalent but with aggregated proofs (see below).
Target: low-end hardware can stay fully validating with modest bandwidth.
The wins:
Anyone can run a full node at home → S₁ (Policy)/S₂ (Perimeter) need more perimeter work to choke.
Attackers can’t simply centralize validation in a few cloud clusters without users noticing.
4.1.2 Transaction model & privacy
You want Monero-style privacy. Mandatory and simplified:
UTXO-like model with:
stealth addresses,
one-time output keys,
ring signatures or ZK proving that:
inputs exist,
sums balance,
no double spend,
no linkage between specific inputs and outputs.
No transparent pool at all. There is no “view the ledger” mode for outsiders beyond total supply and some aggregate stats.
Amounts are hidden (Pedersen commitments), fees are the only cleartext scalar per tx.
Trade-off: you sacrifice on-chain “auditability” in exchange for collapsing the taint/heuristics game. That’s exactly the point.
Now S₂ (Perimeter) actors face a brutal binary:
Either declare the entire asset as toxic,
or accept that they cannot distinguish “good” vs “bad” flows and must fall back to blunt KYC at the fiat edge only.
That nukes a massive chunk of the Coordination tax battlefield.
4.1.3 Script / programmability
Script is deliberately crippled:
basic timelocks, multisig, maybe simple covenants for channel constructs,
but no Turing-complete stuff, no arbitrary data, no NFTs, no embedded blobs.
No OP_RETURN-style arbitrary data. If you want data, you put it:
on a separate, opt-in data chain, or
out-of-band (IPFS, Nostr-like, etc.) and only commit hashes minimally.
Reason: every “expressive” feature becomes:
one more mempool policy knob,
one more court case (“this protocol hosts illegal content”),
one more Coordination tax sink.
Coordination-Tax-Optimized Digital Cash is money only. No DeFi, no JPEGs. You’re trying to minimize S₁ Policy surface.
4.1.4 Block template & inclusion incentives
You can’t force miners to include any given tx, but you can:
Make inclusion incentives as mechanical as possible:
simple fee per byte,
no weird flags,
no prioritizing special tx classes.
Make censorship-visible cheaply:
The protocol can include a “censorship proof” mechanism:
anyone can submit a compact proof that a valid, fee-paying tx has been broadcast for T blocks with no inclusion.
Nodes gossip these proofs; wallets show them in UI.
This doesn’t stop censorship, but it makes it globally obvious, lowering the mental cost for users to:
change pools,
change relays,
or move to grey-market connectivity.
This doesn’t magically fix S₁ (Policy), but it compresses the defender cost: you don’t need 1,000 devs arguing about mempool flags if censorship is a binary event you can diagnose in-protocol.
4.2 S₁: Policy layer design
Goal: make S₁ (Policy) as “dumb mechanical plumbing” as possible.
4.2.1 Relay / mempool
Exact mempool policy is part of the spec, not “node-configurable culture”:
gossip rule = “accept and relay any valid tx with fee ≥ f(weight)” where f is a simple fixed curve baked into consensus.
No per-node invented “standard vs non-standard” categories.
Nodes refuse to run if the mempool policy deviates from spec (you can hash the code path or config; clients could verify).
Attackers can still fork a policy-variant client, but then:
they must visibly fork (different client ID, different network magic),
which is much easier to socially route around than “everyone silently runs a weird patch”.
4.2.2 Client diversity, but spec monoculture
Encourage independent implementations, but require:
formal conformance tests for:
mempool behavior,
tx parsing,
block assembling,
so S₁ (Policy) behavior is behaviorally identical across major clients.
This is the opposite of “policy competition”; you want policy monoculture at the protocol level so that S₁ defenders aren’t in a permanent BIP war.
4.2.3 Wallet norms baked into the protocol spec
You can’t force wallet UX, but you can:
Publish a canonical reference wallet behavior as part of the spec:
coin selection: randomization within privacy-aware constraints,
always use privacy features,
default to full-anonymity tx form, there is no “simple mode” that leaks metadata.
Provide a standard wallet SDK that is:
open-source,
auditable,
optimized,
and implements all the privacy / self-custody defaults.
Then:
If a KYC exchange/wallet wants to deviate, they have to fork and patch.
The path of least resistance for ordinary devs is aligned with S₀ (Protocol) ideals.
That’s the “defaults beat ideals” problem inverted.
4.3 S₂: Perimeter strategy
You can’t redesign the banks or app stores, but you can design how the system expects to be accessed.
4.3.1 Multi-transport networking from day one
Instead of “Bitcoin on TCP/8333 and then maybe Tor if you care”, you do:
Core protocol defined at the message level, not bound to transport.
Reference implementations support at least:
TCP (random ports),
Tor,
I2P or similar,
Nostr-like relays,
email-like store-and-forward (for extreme cases).
And:
Wallets come with built-in multi-transport, not “download Tor and tweak”.
Default = “use everything that works”, automatically.
That way:
If an ISP starts Deep-Packet-Inspection-blocking one pattern, traffic quietly routes via others.
You don’t need a global campaign to teach people how to set up Tor bridges; UI does it.
Coordination tax saving: the “Client & Policy Defense” front automatically has more redundancy; fewer manuals, fewer blog posts screaming “run Tor now”.
4.3.2 App-store avoidance as a first-class citizen
Assume:
iOS/Android will eventually soft-ban non-KYC wallets.
So design like this:
Browser-based light wallets:
All cryptography client-side,
server only relays messages,
installable as PWA (progressive web app).
Sideloadable packages + F-Droid-like ecosystems.
Cheap single-purpose hardware wallets that speak Coordination-Tax-Optimized Digital Cash over Bluetooth/USB, with open firmware and reproducible builds.
The default messaging to users:
“You don’t need the app store. This is a website / file / device.”
So when the inevitable app-store clamp happens, the migration path is pre-baked, not invented under fire.
4.3.3 Grey-market cash ↔ Coordination-Tax-Optimized Digital Cash bridges
To cut bank/AML rails out of normal usage as much as possible:
Protocol itself doesn’t touch fiat, obviously.
But the ecosystem norm is:
P2P cash ↔ Coordination-Tax-Optimized Digital Cash swaps,
local in-person meetups,
OTC tables in markets,
not “exchange on Coinbase”.
You can even hard-code some tooling:
Standardized atomic swap templates for:
different chains,
stablecoins,
etc.,
so people can move in/out via uncentralized venues (DEX, cross-chain Hashed Time-Locked Contract, etc.) instead of bank wires.
Again, you don’t abolish S₂ (Perimeter), but you push most volume away from a handful of chokable Virtual Asset Service Providers.
4.4 Anti-paperization design
You want to stop “Coordination-Tax-Optimized Digital Cash ETF + custody” from becoming 90% of exposure.
Several levers:
4.4.1 Protocol level: make it easy to self-custody at institutional scale
Ironically, if it’s too hard for serious holders to manage keys safely, they must delegate to custodians.
So:
Provide first-class multisig patterns (e.g. ≥2-of-3 with hardware wallets, or Shamir splitting), deeply integrated in the spec and tooling.
Make auditing of self-custody setups easier than auditing a custodian:
deterministic address derivation,
standard policies for rotating devices.
If a pension fund can credibly say “we self-custody Coordination-Tax-Optimized Digital Cash with a standard 3-hardware-wallet scheme and yearly ceremonies”, that reduces demand for “BlackRock Coordination-Tax-Optimized Digital Cash Trust” products.
You’re explicitly trying to commoditize custody for large holders so ETFs are less necessary.
4.4.2 Economic narrative: “ETF = paper gold 2.0”
You can’t control narratives fully, but you can bake in memes:
Official docs/examples constantly call out:
Great Taking / paperization risk,
ETF-style wrappers as second-class, likely to be:
rehypothecated,
cash-settled in stress,
frozen in AML freakouts.
You’re pushing people toward the correct mental bin:
“Coordination-Tax-Optimized Digital Cash ETF” == GLD, not physical bars.
That’s social layer design, not protocol, but it’s part of real Coordination tax minimization: you reduce the future need for education campaigns during crises.
5. Mapping back to the “five fronts”
Let’s explicitly check how Coordination-Tax-Optimized Digital Cash reduces the burn on the five defense fronts:
1. Client & Policy Defense
Mempool policy hard-specified; no perpetual BIP fights about standardness.
One primary tx form; no zoo of script types.
No OP_RETURN spam; data stuff moved off-chain → fewer policy debates.
Censorship proofs built-in → easier to detect and route around captured relays.
2. Mining/Pool Governance
You still have pool centralization risk, but:
Mandatory privacy makes filtered mining less precise (they can only censor by heuristics on fee size or reuse patterns, which is weaker).
Censorship visibility tools raise the reputational & social cost of being the “OFAC-template pool”.
A simpler fee market (no weird tx classes) makes it harder to justify “ethical templates” that just happen to exclude private flows.
The cost of maintaining “clean” policy clients goes up (more complexity for less effect), so the steady-state pressure against S₀ (Protocol) ideals is lower.
3. Wallet & UX Sovereignty
Spec includes canonical privacy-default wallet behavior; SDK makes it trivial to ship non-custodial, private wallets.
That flips the usual gradient: “hard” path is building a KYC, taint-respecting wallet; “easy” path is shipping something S₀ (Protocol)-aligned.
App-store independence is designed in; people don’t have to learn that under fire.
This saves Coordination tax: you don’t need permanent campaigns against every new non-private “beginner wallet”; the spec already enforces privacy shapes, and the major SDK leads by example.
4. Legal/Policy Perimeter
By making on-chain flows indistinguishable:
You deprive S₂ (Perimeter) of its favorite cheap lever: “only these flows are problematic”.
Everything going through a KYC exchange looks as suspect as everything else on-chain.
Result:
Either they outright ban Coordination-Tax-Optimized Digital Cash (which is a clear, visible line in the sand),
or they accept that KYC at the fiat edge is the only realistic tool and give up on selective taint blacklisting.
That’s a huge Coordination tax saving: no travel-rule tweaking, no endless “coinjoin = Suspicious Activity Report” heuristics. They either kill it or live with it.
5. Social Consensus & Comms
You drastically reduce:
the number of knobs that require social norm fights (no inscriptions, no OP_RETURN wars, no spam vs “art” debates);
the number of “features” that can be wedge-narratives (NFTs, DeFi hacks, etc.).
Coordination-Tax-Optimized Digital Cash’s pitch is boring and narrow:
“This is just money, and you either like private commodity-money or you don’t.”
Fewer narrative fronts = less Coordination tax spent on PR, education, and damage control.
Coordination-Tax-Optimized Digital Cash is a grey-market digital bearer cash for:
local trade,
cross-border value smuggling,
regime-uncorrelated savings outside the custody stack.
The Controllers’ incentives:
They probably tolerate a small Coordination-Tax-Optimized Digital Cash ecosystem as:
relief valve,
intelligence honeypot,
bargaining chip vs other blocs.
If it becomes big enough to matter, the binary choice kicks in:
full ban → visible, hard-line move that has legitimacy cost;
limited choke → mostly ineffective because of privacy and multi-transport design.
That’s exactly the design you’d want: no comfortable middle ground where they can gradually strangulate S₁ (Policy)/S₂ (Perimeter) while pretending it’s about “only the bad guys”.
6. Hard limits (places you can’t eliminate the Coordination tax)
There’s no free lunch. Even with this design:
Human devs still need to maintain reference clients and wallets.
S₂ (Perimeter) law can still outlaw running a node, building wallets, or accepting Coordination-Tax-Optimized Digital Cash for payment.
Network access can still be throttled; multi-transport helps, but low-IQ censorship is always possible (“any encrypted traffic = suspect”).
Narrative warfare can still matter (“privacy = crime”, “only terrorists need this”).
What you achieve, if you follow this blueprint, is:
Most of the ongoing, granular S₁ (Policy)/S₂ (Perimeter) battles (taint flags, “standard tx” vs not, spam vs “art”) simply don’t exist.
The Controllers’ main levers become coarse (ban vs tolerate), so:
Defenders aren’t forced into infinite whack-a-mole,
The Coordination tax is paid in occasional big fights, not continuous trench warfare.
The path of least resistance for normal users is already:
self-custody,
private,
fungible,
which means the ideology doesn’t have to fight its own UX.
That’s about as close as you can get to Coordination-tax-minimized digital cash.
With this design, the ongoing tax is low and the lines of conflict are clean, instead of living forever in the muddled, leverage-friendly S₁ (Policy)/S₂ (Perimeter) capture zone Bitcoin drifted into.
Ignoring the Coordination tax doesn’t make it go away.
After ~17 years of Bitcoin development, the government would much rather you use Bitcoin as a Medium-of-Exchange, in most cases, than Gold foil notes (Goldbacks).
That’s embarrassing.
But how is that even possible?
Bitcoin’s Medium-of-Exchange properties have only deteriorated over the years.
Bitcoin did a great job of sedating the brightest, state-misaligned actors with fiat gains until the Controllers have built the AI governance, CBDC, Digital ID prison system.
Where does Bitcoin as a mass, non-custodial Medium-of-Exchange go from here? My best guess is nowhere.
R.I.P digital cash, long live digital gold.
In its current state, Bitcoin is not viable as digital cash. Bitcoin is at best a Great Taking hedge and a Store-of-Value with regulatory overhang.
7. Here are my predictions for the next Bitcoin wars:
Taint, “clean UTXOs” & compliant-Bitcoin vs grey-Bitcoin
Blockspace & “digital cash vs data chain” (the rematch)
8. Bitcoin vs Goldbacks
I described Coordination-Tax-Optimized Digital Cash (CTO-DC) as:
mandatory privacy & fungibility,
thin deterministic S₁ (Policy),
minimal S₂ (Perimeter) dependencies,
default self-custody,
structurally hostile to paperization.
Under that spec:
Bitcoin (today) fails:
P1 (privacy/fungibility) → transparent chain, opt-in privacy, taint games.
P3 (default self-custody) → custodial/KYC by default.
P5 (anti-paperization) → ETFs + futures + custodial wrappers by design.
You’d need a different protocol (Monero-ish base, mandatory privacy, hardened networking, app-store-independent UX) plus very different S₂ (Perimeter) to approach Coordination-Tax-Optimized Digital Cash.
Goldbacks, ironically, match a lot of the spirit at an analog, local scale:
Privacy/fungibility: every note looks like any other; no transaction graph.
Thin S₁ (Policy): no mempool, no templates, no opcodes.
Minimal S₂ (Perimeter): you only need physical meetups and social trust, not banks or app stores.
Anti-paperization: the “wrapper” is literally the metal; you can’t create paper claims on a Goldback without stepping back into the dematerialized system.
The big costs:
Goldbacks don’t scale to high-value remote transactions (shipping, weight, risk).
They’re tied to gold’s volatility vs fiat in people’s heads.
They’re hard to integrate with digital commerce.
So if the goal is “real-world Coordination-Tax-Optimized Digital Cash cash for ordinary people under a hostile regime”, then:
For global reach and digital commerce, you’d want a Monero-ish protocol.
For local daily trade, a Goldback-like instrument is much closer to the ideal: low coordination tax, low digital capture surface, high expropriation resistance.
More context: