How Bitcoin's developers are attacking its Sovereign/Monetary use
Cheaper witness, friendlier data-paths, RBF normalization, relay policies favoring deep pockets, and node-operator liability drift tilt Bitcoin toward settlement + asset rather than sovereign cash.
I’ve already covered how Bitcoin’s developers have been attacking its user base.
In this article, I’ll go into specifics on the Layer-1 changes/policies (code and default relay/miner policies) that, in practice, have weakened Bitcoin’s sovereign / monetary (Medium-of-Exchange) use.
This article is going to be a long one because I’ll assume that you don’t know anything and are not a developer. I’ll try to explain everything in as simple terms as possible.
How Bitcoin’s Layer-1 Changes Weakened its Monetary Sovereignty
The following outlines key Layer-1 (L1) protocol updates and default policy changes that, while technically defensible (at least some of them), have gradually reduced Bitcoin’s effectiveness as sovereign money — a peer-to-peer Medium-of-Exchange operated independently of intermediaries.
1. SegWit (BIP141): The “Witness Discount” and Block-Weight Accounting
What changed:
Segregated Witness (SegWit) replaced Bitcoin’s strict 1 MB block size limit with a new 4 million weight-unit (MWU) model, where “witness” data — mostly signatures — receive a ~75% size discount.
Incentive side effect:
This made non-monetary data (NFT inscriptions, vanity scripts, arbitrary payloads) cheaper than monetary transactions.
Revealed behavior:
Miners and relays accepted these high-fee, non-payment payloads because “fees are fees”.
Net effect:
Fee market distorted — small payments are crowded out during hype waves.
Attackers or state actors can cheaply flood witness space.
Node bandwidth and validation costs rise, pushing small operators out.
In simple terms
What SegWit changed
Before SegWit, a block could be at most 1 megabyte. SegWit swapped that for “4 million weight units (MWU)” and said:Non-witness bytes (the core transaction stuff) cost 4 weight per byte.
Witness bytes (mostly signatures) cost 1 weight per byte.
Net: witness data gets a ~75% discount.
What that means in practice
If you can shove more of your payload into the witness area, you pay a lot less per byte. That’s true whether your payload is a normal payment signature or random data (images, text, vanity scripts, whatever). So stuffing data into witness became the cheapest way to occupy blockspace.
Why non-payment data exploded
People realized they could buy blockspace cheaply by packing their bytes into the witness. That’s how inscriptions and other “not-a-payment” uses took off: it’s simply cheaper per byte to cram data into the witness than to do the same thing in the non-witness part.
Why miners/relays accept it
Miners get paid fees. They don’t care if your bytes are a coffee payment or a pixel art inscription — if the fee/weight is high enough, they include it. Relays mostly forward anything that’s valid and pays its way under policy. Bottom line: fees are fees.
Net effect
SegWit’s discount made certain bytes cheap, so people filled blocks with those bytes.
That raises congestion and fees for everyone when demand spikes, because cheap bytes still take space.
It’s perfectly valid under the rules, so miners mine it and the network carries it.
Note that SegWit didn’t by itself invite arbitrary data; together with Taproot’s script-path witness design, the discounted witness became an obvious carrier for non-payment bytes.
The causal chain is “SegWit weight model” + “Taproot script path & Tapscript relaxations” ⇒ inscriptions.
2. Taproot (BIP340–342): Easier Complex Scripts and Data Embedding
What changed:
Taproot introduced key-path spending and the Tapscript system, which made complex scripts cleaner, cheaper, and more private.
Incentive side effect:
It became easier to embed arbitrary data — such as Ordinals — in witness space without tripping prior filters.
Net effect:
The unspent transaction set (UTXO) grows faster.
Mempool congestion worsens during activity spikes.
Legal risk for node operators increases as arbitrary data proliferates.
In simple terms
What Taproot actually changed
One key on the outside, anything on the inside. Taproot lets a spend look like a simple key signature (clean, private), while hiding any complex script logic unless you need to reveal it.
Tapscript relaxed/modernized script. It made scripts easier to express and cheaper to include, and all the heavy bytes live in the witness (which is fee-discounted since SegWit).
Why that made stuffing data easier
If you can put lots of bytes into the witness, you pay less per byte.
With Taproot/Tapscript you can park arbitrary data in a branch that never actually executes (e.g., “
OP_FALSE OP_IF … big blob … OP_ENDIF”). The spend still looks like a normal Taproot spend from the outside.Old filters that flagged obvious data carriers (like big
OP_RETURNs) are easier to dodge because Taproot spends blend in.
Real-world consequences
UTXO set grows faster. Many inscription/ordinal patterns spray tons of tiny outputs (“dust”) that sit unspent. Every full node has to remember those UTXOs in RAM until they’re spent.
Mempool jams during hype. Big witness blobs still consume block weight. When waves of these txs arrive, they crowd out normal payments and push fees up.
Legal surface area widens. Nodes/miners are now routinely relaying and storing non-payment content (some of it questionable). That raises “am I distributing this?” worries for operators in certain jurisdictions.
Miners don’t care what the bytes are. If the fee/weight is good, it goes in the block. Fees are fees.
Bottom line
Taproot made complex spends cheaper, cleaner, and harder to distinguish — which also made arbitrary data cheaper and stealthier. Result: more data in blocks, more UTXOs lingering, bigger mempool spikes, and more legal risk on operators — while miners happily take the fees.
3. Liberalized Data-Carrier Policies (OP_RETURN and “Standardness”)
What changed:
The OP_RETURN field, originally capped at 40 bytes, was raised to 80 bytes years ago (Core v30 recently lifted the default -datacarriersize to 100,000 bytes — a ~1200× jump vs the long-standing ~80–83 B default), and broader standardness rules allowed larger pushes in witness data.
Incentive side effect:
Lower cost for on-chain data storage encouraged non-transactional use.
Net effect:
Full nodes face higher legal and operational risks.
More congestion and larger mempools.
Hobbyist node operators face rising costs and liability risk.
In simple terms
What changed
Bigger data slots:
OP_RETURNused to allow ~40 bytes of data; it was bumped to 80 bytes.Looser “standardness” rules: Nodes (by default) became more willing to relay transactions that carry bigger data blobs in the witness (the discounted part added by SegWit).
Translation: it got easier and cheaper to stuff arbitrary data into transactions that the network will relay and miners will include.
Why that matters
Cheaper per-byte data → more non-payments. If it’s inexpensive to put bytes on-chain, people will use Bitcoin blocks for data storage (inscriptions, files, vanity stuff), not just payments.
Miners don’t filter by “purpose”. If the fee is good and the tx is valid, they include it.
Real-world effects
Bigger mempools & more congestion: Those data-heavy transactions still fill blockspace, so during waves of activity they crowd out normal payments and push fees up.
Higher operator burden: Full nodes must download, verify, and store more bytes (blocks, mempool, indexes). That means more bandwidth, CPU, RAM, and disk — especially painful for hobby setups.
UTXO pressure depends on patterns: Some data patterns also create lots of tiny outputs (“dust”), which sit in the UTXO set and raise RAM costs for every node until they’re spent.
Legal exposure goes up: If arbitrary content rides the network, some node operators worry they’re relaying/distributing material they don’t want to touch. That’s not theoretical in regulated jurisdictions.
Hobbyists get squeezed: More resource demands + legal uncertainty = fewer low-cost, at-home nodes, more reliance on cloud or custodial infra (which are easier to supervise/censor).
Bottom line
By relaxing data-carrier and standardness limits, Bitcoin made it cheaper and easier to put non-payment data on-chain. That brings more bytes, more congestion, more operator cost, and more legal risk — with miners happy to include whatever pays.
4. Replace-By-Fee (RBF): From Opt-In to Broad Default
What changed:
Replace-By-Fee (RBF) allows unconfirmed transactions to be replaced by a version with a higher fee. Some implementations have moved toward permissive defaults.
Incentive side effect:
Relays and miners prefer higher-fee replacements, undermining instant (zero-confirmation) payments.
Net effect:
On-chain instant transactions become impractical without custodians.
Pushes Medium-of-Exchange activity to centralized escrow or second layers.
In simple terms
What Replace-By-Fee (RBF) is
An unconfirmed transaction can be replaced by a new version that pays a higher fee.
Nodes/relays/miners tend to prefer the higher-fee version because… more fees.
How the defaults drifted
It started as “opt-in RBF” (only replace if the sender marked the tx as replaceable).
Over time, permissive policies spread (a.k.a. “full-RBF” at many nodes/pools), and wallets default to RBF flags.
Result: on today’s network, assume unconfirmed txs are replaceable unless you know the counter-party and settings.
Real-world incentive effect
If I pay you at a checkout and you hand over goods before a confirmation, I can broadcast a replacement that pays a bit more fee but pays you less (or pays me back).
Relays/miners prefer my higher-fee replacement. Your zero-conf payment can disappear.
What this does to “instant” Bitcoin payments
Zero-conf becomes fragile. You can’t rely on “I saw it in the mempool” anymore.
Merchants either:
Wait for confirmations (slower), or
Use a custodian/Payment-Service-Provider that fronts the risk, or
Push to L2/custodial tabs (Lightning hubs, exchanges, apps) for instant UX.
Why it centralizes Medium-of-Exchange in practice
To make instant payments work again, you lean on:
Custodians (they take double-spend risk and run risk engines), or
Hubby L2s (routing through big nodes/exchanges with policies and blacklists).
That’s centralized trust at the edges. It’s fast, but not sovereign bearer money.
Bottom line
RBF aligns miners with higher fees and makes unconfirmed payments unsafe.
Instant retail-style payments migrate to custodial or L2 rails where someone else absorbs risk and enforces rules.
On L1, treat anything unconfirmed as revocable. If you want “final”, wait for confirmations — or accept the trust trade-off of a middleman.
Core hasn’t flipped a global “full-RBF default” flag, but the ecosystem reality is that unconfirmed = replaceable.
Core still documents opt-in RBF; the ecosystem (pools/mempools/wallets) behaves closer to full-RBF in many places.
5. Relay and Mempool Settings that favor Large Players
What changed:
Tuning parameters — like ancestor/descendant limits, package relay, and minimum relay fees — determine how transactions are accepted and prioritized.
Incentive side effect:
Well-capitalized users can chain transactions or spike fees to crowd out smaller spenders.
Net effect:
Wealthier or automated actors dominate fee priority.
Small payments and sovereign users are sidelined.
In simple terms
What these knobs do
Minimum relay fee: your tx must pay at least X sats/byte or most nodes won’t even carry it.
Ancestor/descendant limits & package relay: the mempool now judges groups of linked transactions (parents/children) together. If a low-fee parent is stuck, you can attach a high-fee child to drag it in (Child-Pays-For-Parent), or replace it with a higher-fee version (Replace-By-Fee). Bigger, better-funded users can chain lots of txs and shape their own priority.
Why deep pockets win
If the mempool is crowded, a rich or automated actor can:
Outbid everyone instantly (set fees higher and refresh them).
Build packages (parents + high-fee children) to force miners to include their bundle.
Continuously rebroadcast/replace with smarter fee tactics.
Small users sending one basic transaction can’t play these games. They either overpay or wait.
Real-world result
Priority skews to wealth + tooling. Bots and exchanges dominate the front of the line; ordinary users get pushed back.
Small payments suffer. If you’re a sovereign user with a hardware wallet and no fee wizardry, you’re at the mercy of spikes and policy thresholds.
Behavior adapts: people migrate to custodians or L2 for predictability, or they batch and time their L1 usage (off-peak, lower frequency).
Bottom line
Those mempool/policy dials (min relay fee, package rules, ancestor/descendant limits) decide who gets carried and how fast. With them set the way they are, money + automation = first class, and small, sovereign L1 spenders get priced out or delayed when things heat up.
6. Legal-Risk Externalities shifted to Node Operators
What changed:
With SegWit and Taproot enabling arbitrary data, it’s easier to embed illegal or objectionable content directly in the blockchain.
Incentive side effect:
Bad actors can weaponize this by uploading illicit material, creating legal exposure for anyone running a validating node.
Net effect:
Some self-hosted nodes go offline to avoid risk.
Validation concentrates among corporate operators.
In simple terms
What changed
SegWit + Taproot made it cheap and easy to stash arbitrary data (not just payments) inside transactions, mostly in the discounted witness area.
That means someone can embed files or messages directly into the blockchain forever.
Why that creates legal risk for you
When you run a full node, you download, verify, and store block data (at least during sync; many keep it all).
If that data includes illegal or objectionable content in your country, a prosecutor could argue you’re possessing or distributing it (you relayed it to peers).
You can’t easily filter it: it’s mixed with normal tx data, often compressed/opaque; detecting/removing it is hard and risky.
The attacker’s play
Upload bad content → everyone who validates/relays carries the legal bag.
Fees are fees: miners include any valid, high-fee tx; relays pass valid bytes along.
Result: the legal risk is externalized from the uploader to everyday node operators.
Real-world effects
Chilling effect: Some hobbyists shut down nodes (“not worth the legal exposure”).
Shift to corporates/cloud: More validation moves to companies with lawyers, compliance teams, and takedown playbooks.
Centralization creep: Fewer independent nodes → more reliance on big providers (RPCs, hosted nodes, custodians) that can be regulated or pressured.
Worse privacy & resilience: With fewer sovereign validators, the network becomes easier to surveil and steer.
Bottom line
By making arbitrary data cheap to put on-chain, the legal risk got pushed onto node runners. Some exit; others centralize behind corporate/compliant infrastructure. The network still runs, but with more central points of control and less grassroots sovereignty.
7. Increased Block Weight → Centralization Pressure
What changed:
Effective block size rose from 1 MB to 4 MWU, increasing validation and bandwidth requirements during congestion.
Incentive side effect:
Only data-center-grade nodes can handle peaks consistently.
Net effect:
Home or hobbyist nodes drop off.
Validation centralizes with miners, ISPs, and clouds.
In simple terms
What changed
Before: blocks were capped at ~1 MB.
After SegWit: blocks are measured in weight (up to 4 million weight units). In busy periods, that means way more bytes moving around.
Why that matters in the real world
More data per block = heavier bursts every ~10 minutes.
Nodes must download, verify, and relay those bursts fast or they fall behind.
During fee spikes, blocks fill to the limit, so the bursts get big and constant.
Who can keep up
Data-center hardware and fat internet pipes handle it fine: high bandwidth, low latency, good peering.
A home node on consumer internet struggles: slower downloads, bufferbloat, ISP throttling, Wi-Fi hiccups.
The incentives this creates
If your node can’t keep up, you see blocks late and your view of the chain lags.
Miners and big operators optimize for propagation (co-located servers, direct peering, custom relays). They gain an edge.
Regular users conclude, “I’ll just use a hosted node/RPC or trust my exchange”.
Net effects you actually feel
Hobby nodes drop off. Running one gets harder, pricier, and less reliable during congestion.
Validation clusters in data centers (clouds, ISPs, miners).
With fewer independent nodes:
Policy nudges (relay defaults, blacklists, filters) are easier to push.
Outages or throttling at big providers hit more users at once.
Censorship pressure has fewer choke-points to target.
Bottom line
Bigger effective blocks mean heavier, bursty traffic. That filters out home nodes and pulls validation into data-center hands (miners, ISPs, clouds). The network still runs — but with more centralization pressure and fewer sovereign validators.
8. Convenience Defaults: Assumevalid, Pruning, and Checkpoints
What changed:
Modern node configurations often enable “assumevalid” or “pruning”, which skips historical validation for speed and lower storage use.
Incentive side effect:
Users accept partial trust for faster setup.
Net effect:
More nodes function like light clients.
Reliance on a few archival peers increases systemic fragility.
In simple terms
What these settings do
assumevalid: Your node skips re-checking old signatures before a known block height (it still checks Proof-of-Work and headers). Result: much faster sync, but you’re trusting that the old history wasn’t invalid.
pruning: Your node throws away old block data after validating it. Result: tiny disk use, but you can’t serve old blocks to others (you aren’t a full archival source).
checkpoints (or similar trust anchors): Hard-coded “we expect the chain to include this block”. Result: helps skip work and steer sync, but again adds assumed trust about past history.
The real incentive effect
People want quick setup and low storage, so they accept a little trust to get running fast. That’s rational for users — but it shifts load onto a small set of archival nodes that keep every block and do all the heavy lifting for the network.
What this changes in practice
More nodes behave like light clients: They validate enough to follow the tip, but depend on others for deep history and old data.
Fewer true archives: With pruning popular, only a minority can serve historical blocks to the rest.
Systemic fragility creeps in: If the few archival peers (exchanges, infra companies, universities, hobbyists with big boxes) go down, censor, throttle, or get regulated, everyone else feels it — slower syncs, patchy data, easier choke-points.
Bottom line
Convenience defaults trade some sovereignty for speed and size. You still get a working node, but the network’s backbone shrinks to those willing to keep full history. That concentration makes the system easier to pressure and more brittle when things go wrong.
9. Deprecation of Non-Standard Scripts
What changed:
Certain transaction formats, like bare multisig, were labeled “non-standard” and excluded by default relay rules — even though they’re valid by consensus.
Incentive side effect:
Users migrate to custodial multisig or hardware-managed setups.
Net effect:
Sovereign, privacy-enhancing setups are discouraged.
The network’s behavioral diversity narrows.
In simple terms
What actually happened
Some perfectly valid-by-consensus transaction types (e.g., bare multisig) were marked “non-standard”.
“Non-standard” means: most nodes won’t relay them by default, and many miners won’t include them unless they see them first (hard to get seen without relay).
Translation: the rulebook still says “legal”, but the roads are closed. If your tx can’t propagate, it’s effectively unusable unless you have a direct line to a miner.
Why users shift behavior
If your preferred script won’t relay, you either:
Wrap it into a standard form (P2SH/P2WSH/Taproot), or
Use a custodian or a wallet stack that speaks only the approved shapes, or
Try to find a miner to submit directly (not realistic for most people).
Most people pick the custodial/hardware-managed path because it “just works”.
Real-world effects
Sovereign, quirky, or privacy-enhancing setups get discouraged. If it’s not on the “standard” menu, it’s a hassle.
Network behavior converges on a few common templates. That makes chain analysis and policy nudging easier.
Power shifts to gatekeepers (popular clients, relay defaults, big pools). They decide what shapes move fast (or at all).
Bottom line
Labeling valid scripts as “non-standard” doesn’t change the law of Bitcoin — it changes the roads. If your transaction can’t travel, you’ll adapt to the sanctioned shapes or use custodians. Result: less diversity, less privacy, more central pressure, even though consensus never banned your script.
10. Fee-Market “Purism” — No Priority for Payments
What changed:
All transactions compete for block space purely by fee rate; there’s no quality-of-service distinction for payments.
Incentive side effect:
Speculative or spam traffic can easily outbid normal payments.
Net effect:
Retail payments lose predictability.
Merchants face higher costs or delays during hype cycles.
In simple terms
What actually changed
Bitcoin’s blockspace is a single auction. Every transaction — coffee payment, exchange sweep, inscription blob, bot spam — bids with a fee rate (sats per vbyte).
There’s no “payment lane”, no Quality of Service flag, no merchant priority. Just “highest fee/weight wins”.
Why that skews behavior
If hype hits (meme coin rush, inscriptions, exchange rebalancing), those actors can outbid normal users instantly.
Miners are paid by fees, so they sort by fee rate, not by purpose. Fees are fees.
Real-world effect you feel
Retail payments become unpredictable. One hour it’s cheap and fast; the next, your payment waits behind a wall of high-fee non-payments.
Merchants pay more or wait longer. To keep “instant-ish” UX, they must overpay fees, use a custodian/Payment-Service-Provider, or move to L2. Otherwise, confirmations lag during spikes.
Why there’s no easy escape on L1
You can’t tag a transaction “this is a real purchase” and jump the line; the protocol doesn’t care.
Wallet tricks (Replace-By-Fee/Child-Pays-For-Parent/package bidding) help if you can pay up. Small buyers usually can’t compete with automated, deep-pocket flows.
Bottom line
A pure fee auction maximizes miner revenue but gives zero special treatment to payments. When speculative or spammy demand surges, it prices out everyday transactions, pushing merchants and users toward custodial rails or L2s for predictable throughput.
11. Lightning Network Bias — L1 as Settlement Only
What changed:
Recent policy proposals (like Child-Pays-for-Parent carve-outs) prioritize channel management and second-layer (L2) operations.
Incentive side effect:
The base layer is increasingly treated as settlement infrastructure, not a payment network.
Net effect:
Direct L1 payments decline.
Users are nudged toward custodial Lightning or regulated on-ramps.
In simple terms
What actually changed
Mempool/relay proposals and defaults (e.g., package relay, Child-Pays-For-Parent carve-outs) are tuned so channel opens/closes, splices, and swaps can get confirmed reliably.
Wallets/exchanges lean into this: they batch L1, automate fee bumps, and treat L1 as the place to manage channels and settle, not to pay for coffee.
Why that shifts incentives
If policies make it easier for L2 ops to get through congestion (via Child-Pays-For-Parent packages, carve-outs, fee tooling), those flows win the fee auction more often.
Regular L1 payments have to compete head-to-head with automated channel ops and exchange flows that can outbid them or bundle smartly.
Real-world effects
L1 becomes “settlement plumbing”. You see more channel opens/splices, exchange rebalances, batched withdrawals — fewer direct L1 payments.
Users wanting fast, cheap payments are nudged to Lightning — often via custodial hubs (exchanges, big wallets) because they’re easy and liquid.
Merchants either integrate Lightning through a provider (custody/risk offloaded) or pay higher L1 fees/wait longer.
Why this pushes centralization at the edges
Running sovereign Lightning (self-routed, self-liquid) is harder than tapping a big hub. Most people pick custodial Lightning or regulated on-ramps that abstract it all.
Over time, payment volume clusters around large hubs and Payment-Service-Providers, while L1 is used mostly to open/adjust/close those channels.
Bottom line
Policy and tooling now favor L2 maintenance over L1 retail use. The base layer is treated like final settlement and channel management, while everyday payments slide to Lightning — often custodial or regulated — because it’s the only thing that stays fast and predictable under fee pressure.
12. Governance Activations Show Who Sets the Rules
What changed:
Past upgrade processes (e.g., BIP9, BIP8, “Speedy Trial”) revealed that miners and coordinated developers can accelerate or block changes faster than ordinary users can veto.
Incentive side effect:
Power concentrates among aligned institutional actors.
Net effect:
Technical ideals matter less than coordination leverage.
Future upgrades will likely follow similar political dynamics.
In simple terms
What actually happens in upgrades
Rule changes need coordination. To activate, you need miners to mine the new rules, big pools to signal, exchanges/custodians to accept deposits, wallet/infrastructure teams to ship updates, and users to run them.
BIP9/BIP8/“Speedy Trial” are coordination levers. They set thresholds and timers that, in practice, let miners + core devs + major infra decide when something flips on — or stalls.
Who really has leverage
Miners/pools: Control signaling and block production. If they don’t play ball, activation drags. If they coordinate, it can move very fast.
Core maintainers & lead devs: Control what’s merged, what binaries ship, and which activation method/warnings land in the “standard” client most people run.
Exchanges/custodians/Payment-Service-Providers: Control where coins flow. If they choose a side, liquidity follows them. That decides practical reality more than forum votes.
Ordinary users: Matter in aggregate, but only if they can withhold liquidity or hash in a coordinated way — which is rare.
Why this concentrates power
Coordinating thousands of small users is hard; coordinating a few dozen institutions is easy.
Activation schemes with time windows and thresholds reward actors who can move in lockstep (pools, large infra, top client maintainers).
“User veto” exists in theory (run your own rules), but without miners and exchanges you’re on a minority chain with no liquidity.
What this means in practice
Technical purity loses to coordination. The “best” design doesn’t win; the most coordinated coalition does.
Messaging is part of the game. Activation method choices (“Speedy Trial”, LOT=true/false, flag days) are politics encoded in software defaults.
Future upgrades repeat the pattern. Expect negotiations between dev leads, pools, and big venues; users mostly ratify by upgrading after the fact.
Bottom line
Bitcoin’s upgrades aren’t decided by abstract ideals — they’re decided by who can coordinate miners, code, and liquidity fastest. That’s why power tends to cluster with aligned institutional actors, and why future changes will follow the same political playbook.
13. Quiet Merchant De-Feature: BIP70 Payment Protocol Deprecation
What changed: Core (and major wallets) removed support for BIP70 (authenticated invoices/X.509 certs).
Incentive side effect: Merchant-grade UX (signed invoices, refund addresses, anti-Man-In-The-Middle) regressed to ad-hoc QR flows.
Net effect:
Enterprises leaned toward custodial processors (they provide auth/receipts) or stopped L1 acceptance.
Another nudge away from sovereign Medium-of-Exchange toward intermediated rails.
In simple terms
What actually changed
BIP70 used to give you signed payment requests (merchant identity via X.509 certs), refund addresses, and a payment receipt/ack. It was the “proper invoice” flow for on-chain payments.
Core and most major wallets removed BIP70 support. Reasons cited included cert/Public Key Infrastructure (PKI) headaches, wallet bugs, phishing risks, and maintenance burden. The result: most wallets fell back to basic BIP21 (just a QR with an address + amount).
Why that mattered
With BIP70 gone, you lost built-in merchant identity and standardized refunds. It’s back to “scan this QR / send to this address”, which is easier to spoof and harder to reconcile.
Enterprises that need signed invoices, clean refunds, receipts, and audit trails now have to bolt on their own flow — or outsource to a custodial processor that provides those features.
Real-world effects
Merchant UX regressed: fewer cryptographic guarantees, more “did you pay the right address?” support tickets, clunky refunds.
Enterprises drifted to processors (they handle identity, receipts, dispute workflows) or stopped L1 acceptance for retail flows.
Another centralizing nudge: everyday Medium-of-Exchange use moves toward intermediated rails (custodial gateways, L2 providers) where the merchant-grade features live.
Bottom line
Killing BIP70 took away the standard, signed invoice flow for on-chain payments. That pushed serious merchants toward custodial processors (or away from L1), nudging Bitcoin usage away from sovereign, direct payments and toward managed, intermediated payment stacks.
The protocol feature that made Bitcoin “invoiceable” like cards got sunset.
This happened in Core v0.19.
14. Removal of “Priority by Coin Age” & Free Relay (historical)
What changed: Early Bitcoin allowed priority/“free” relay for small, old-coin spends. That channel was removed as fee markets matured.
Incentive side effect: Micro-payments lost their relief valve.
Net effect:
Small sovereign transactions now compete head-on with whales/spam.
Every byte pays → price-sensitive retail MoE gets squeezed in spikes.
In simple terms
What changed
Early Bitcoin had a priority lane: tiny transactions spending old coins could get relayed/mined “for free” (or very cheap) if they met certain age/size rules.
As the fee market took over, that priority/free relay was removed. Now it’s just a single fee auction for all transactions.
Why that matters
That “free/priority” path acted like a relief valve for micro-payments and small, sovereign users.
Without it, a 200-sat coffee payment must outbid exchange sweeps, inscriptions, bots — everyone.
Real-world effects
Small payments get squeezed. When demand spikes, whales and automated flows crank fees and jump the line; your tiny tx waits or overpays.
Sovereign users lose predictability. No special treatment for “I’m just paying a friend”; every byte pays full freight.
Behavior shifts: people either:
move small payments to custodians/L2 for predictability, or
batch and delay L1 usage (less “everyday money”, more settlement-only).
Bottom line
Killing the old priority lane means micro-txs now fight the same fee war as the big guys. In busy periods, price-sensitive retail Medium-of-Exchange gets pushed out, and everyday payments drift to intermediated or off-chain rails.
The “let grandma pay” lane closed. Everyone pays auction price.
Good for miner fee purity; bad for grassroots MoE predictability.
15. Dust Limits & MinRelayFee Floors as Gatekeepers
What changed: Conservative dust thresholds and minrelayfee defaults.
Incentive side effect: Tiny outputs (useful for cash-like micro-flows and coin control) become uneconomic or unroutable under default policy.
Net effect:
Fewer micro-denomination patterns → less cash-like feel.
Heavier reliance on custody/aggregation to “size up” outputs.
In simple terms
What changed
Dust limits: If an output is too tiny (costs more to spend than it’s worth), nodes treat it as “dust” and won’t relay it by default.
MinRelayFee: Transactions below a certain fee-per-byte floor aren’t relayed either.
Together, these defaults act like bouncers at the door: very small coins and very cheap transactions don’t get in.
Why that matters
Micro-denominations (the “coins” you’d use for tiny, cash-like payments or precise coin control) become uneconomic or just don’t propagate.
Even if they’re valid by consensus, the network’s default policy won’t carry them, so they might as well not exist for most users.
Real-world effects
Less cash-like feel: Harder to make tiny pays, tip amounts, or dust-sized splits; you end up using bigger chunks.
Aggregation/custody rises: People lean on custodians, payment processors, or batching services to “size up” UTXOs before spending.
Coin control suffers: It’s tougher to manage small change, avoid linking, or craft privacy-friendly spends if tiny outputs are disfavored.
Fee spikes = dead zone: When fees rise, the floor effectively kills micro-flows entirely.
Bottom line
Dust limits and minrelayfee defaults are gatekeepers: they keep the network efficient, but they also price out tiny, cash-like activity. That nudges users toward bigger, aggregated outputs — often via custodial or centralized services — and away from sovereign micro-spends on L1.
Pennies aren’t welcome; bring bills.
Policy floors price out the long tail of sovereign, tiny payments.
16. Core v30: OP_RETURN/data-carrier expansion (policy)
What changed: The default data-carrier policy was widened dramatically: Core v30 raises the default -datacarriersize from the long-standing ~80–83 bytes to 100,000 bytes (≈100 KB) and, for the first time in defaults, permits multiple OP_RETURN outputs per transaction. The option itself is deprecated, signaling future removal of the knob. 100,000 bytes is a ~1200× jump vs the long-standing ~80–83 B default.
Incentive side effect: Arbitrary payloads (files, blobs, “inscriptions”) become vastly cheaper/easier to relay under default policy. Attackers/state actors can bulk-inject non-payment data that rides fee spikes to the front of the line.
Net effect:
Congestion/crowd-out: Big, cheap data blobs bid against payments during demand spikes.
Legal exposure shift: Node operators relaying/storing blocks are more exposed if illicit content is embedded.
Centralization creep: Hobby nodes face higher bandwidth/storage + legal risk → more validation concentration in compliant clouds.
Policy lock-in risk: Deprecating the knob reduces operator autonomy to push back later.
In simple terms
What Core v30 actually did (policy, not law)
Blew the door open: The default relay limit for
OP_RETURNdata jumped from ~80 bytes to ~100,000 bytes (~100 KB).Multiple data slots allowed by default: A single tx can now carry several OP_RETURNs.
Took the steering wheel away: The
-datacarriersizeknob is deprecated, hinting it may be removed later. Fewer ways for operators to clamp this down.
Think of it as: the highway now lets semitrucks full of data sail through by default, not just tiny glove-box notes.
Why that changes behavior
Cheap, easy data stuffing: If the default relays big blobs, anyone (inscriptions, file drops, bots, state actors) can pack non-payment bytes and get them propagated without special setup.
Fees are fees: In a spike, big data txs can outbid payment txs and still be relayed/mined because the defaults say “this is fine”.
What you’ll feel in the real world
Crowd-out during spikes: Large data blobs compete with your payment for blockspace. Payments wait or overpay.
Higher node burden: More bandwidth, mempool memory, and disk churn — worst when hype hits and blocks are full.
Legal risk shifts to you: If illicit content rides inside these blobs, every relaying/validating node is exposed to “you stored/distributed it”.
Centralization creep: Hobbyists look at the bandwidth + legal headache and bail to hosted/cloud nodes (or quit). More validation ends up in compliant data centers — easier to watch, throttle, or pressure.
Policy lock-in risk: Deprecating the knob means less operator autonomy later. Defaults harden into de facto rules even though consensus never required them.
Bottom line
Core v30’s defaults turned Bitcoin’s data side-door into a freight entrance and started removing the building’s light switches. Result: more non-payment data in the fast lane, more congestion and legal exposure for node runners, and a nudge toward centralized, compliant infrastructure — all without changing consensus.
Yesterday: one tiny OP_RETURN (≈80 bytes), many wallets ignored big blobs.
Today (v30 defaults): up to 100 KB per tx and more than one OP_RETURN allowed → it’s trivial to upload files at scale, and miners will include whatever pays.
If someone uploads toxic content, you download/relay/store it to stay in consensus. Good luck explaining that to a prosecutor or cloud provider.
17. Core v30: RBF ergonomics tilt further to replaceability (wallet/API surface)
What changed: v30’s wallet tooling (bumpfee, psbtbumpfee) makes full-Replace-By-Fee (RBF) style replacements easier, even when original txs didn’t signal BIP125 — mirroring the ecosystem drift toward full-RBF mempools and package-based fee bumping (LN anchor workflows). Exchanges are cautioned that unconfirmed txs can be replaced more broadly.
Incentive side effect: Miners/relays prefer higher-fee replacements; zero-conf becomes even less trustworthy for retail Medium-of-Exchange.
Net effect:
Instant L1 payments degrade: Merchants either wait confirmations, or move to custodial/L2 rails that absorb risk.
Fee games favor pros: Sophisticated replacers (exchanges, bots) win the mempool auction; small users pay up or wait.
In simple terms
What Core v30 actually did
The built-in wallet/API now makes fee bumping by replacement (RBF) easier by default (e.g.,
bumpfee,psbtbumpfee), even when the first version of the transaction didn’t opt in to BIP125.This lines up with how many mempools already behave (full-RBF and package fee bumping for Lightning channel ops): if you show up with a higher-fee replacement, the network tends to accept it.
Why that changes real-world behavior
Miners/relays follow the money. A replacement that pays more usually wins.
So an unconfirmed transaction you just received is easier to overwrite than before.
What you’ll feel as a user/merchant
Instant L1 payments get worse. If you hand over goods on “zero-conf”, the payer can replace the payment with a better-fee version that doesn’t pay you.
Your options: wait for confirmations, or use a custodian/L2 that takes the double-spend risk for you.
Pros win the fee auction. Exchanges and bots can automate replacements and package parents/children to force inclusion. Small, sovereign users either overpay or wait longer.
Bottom line
Core v30’s wallet ergonomics normalize replacement as the default tool. That pushes everyday, instant L1 payments toward “wait for confs” or custodial/L2 rails, and it tilts the fee game toward sophisticated players who can micromanage replacements — because, in the end, fees are fees.
RBF convenience is great for fee management and LN ops, but it pushes retail Medium-of-Exchange off L1 and into intermediated rails — exactly the centralizing nudge I’ve been mapping.
18. Core v30: Multiple OP_RETURNs per tx
What changed: Default policy now accepts more than one OP_RETURN output per transaction, not just a single carrier. Combined with the 100 KB cap, one tx can carry large, multi-segment payloads.
Incentive side effect: Batching of non-payment data becomes cheaper/cleaner at default policy; blob publishers can optimize fee/weight per payload.
Net effect:
Higher burstiness in block weight → tougher on home nodes; higher mempool cohesion risk (nodes diverging on what they’ll relay); cleaner pretext for policy/legal harmonization against “content-distribution nodes”.
In simple terms
What actually changed
Nodes (by default) now accept transactions with multiple OP_RETURNs, not just one.
And because the default data size per tx was lifted to ~100 KB, a single transaction can carry a big, multi-chunk blob of non-payment data.
Think: one truck can now haul several trailers of data, not just one small box.
Why that changes behavior
Cheaper batching: If you can stuff many data chunks into one tx, you pay one set of overhead and optimize fees across the whole blob.
Cleaner publisher workflow: “Blob” senders don’t need weird workarounds; they just pack it all into one tx under defaults.
What you’ll feel in the real world
Burstier blocks: When these big, multi-segment data txs hit, a block can get hefty fast. That’s harder on home nodes (bandwidth/latency) and increases the chance they fall behind during peaks.
Mempool friction/divergence: If some operators keep stricter settings while others run the new defaults, nodes can disagree on what to relay, making the network less cohesive at the edges.
Legal spotlight gets brighter: Multiple OP_RETURNs per tx make it obvious that nodes are relaying non-payment content. That’s an easier pretext for regulators to frame full nodes as content distributors, pushing toward “policy alignment” and cloud compliance.
Bottom line
Letting multiple OP_RETURNs ride in one big (~100 KB) transaction makes data publishing cheaper and tidier — and it amplifies block burstiness, strains hobby nodes, risks mempool splits, and strengthens the case to corral validation into compliant, centralized infrastructure.
Think “zip file” vs “post-it note”. v30 defaults bless the zip.
This is an accelerant on the same fire: more payload, more often, with fewer policy brakes at the edge.
Why these Core v30 moves matter specifically for sovereign/MoE use
Cheaper non-monetary bytes → fee spikes skew against small payers. The Medium-of-Exchange experience degrades exactly when retail needs predictability.
Legal-risk externality → node churn → centralization. Fewer independent validators = easier policy capture and blacklist pressure.
Replace-By-Fee ergonomics + package workflows → L1 becomes ops/settlement rail. “Pay at point-of-sale on L1” recedes; custodial/L2 hubs become the norm.
All three are revealed-preference consistent with a world that wants Bitcoin settlement-only, not sovereign cash.
Was Bitcoin Core’s v30 update a simple mistake or an attack on Bitcoin
Bitcoin Core’s v30 default-policy shift isn’t novel — it blesses a pattern we’ve already seen play out elsewhere: loosen data-carriage → someone proves the worst-case immediately → legal + infra costs migrate from the abuser to the network’s honest operators.
Default policy is destiny. Most of the network runs defaults. Moving OP_RETURN to 100 KB and allowing multiple OP_RETURNs per tx makes bulk payloads “normal”, not edge-case. You’ve converted “post-it notes” into zip-files at the mempool edge. (Core advocates say “consensus didn’t change”, but policy changes shape miner behavior and the economics of abuse.)
Batch economics favor abusers. Cheap, clean batching in a single 80–100 KB tx (or a few) dominates “spray 1,000 tiny posts” for malware, contraband blobs, or shock content. The cost/byte falls, while the operational burden on hobby nodes rises (bandwidth spikes, mempool churn, storage pressure).
Jurisdictional risk shifts to node runners. As seen in prior incidents and research, once you enable contiguous, human-interpretable payloads at default policy, you’ve simplified an attacker’s job: no steganography required. A future prosecutor/policymaker doesn’t care about “it’s only policy, not consensus”. They’ll say: your default software made it easy to store this; you propagated it. (You can already see that logic forming in public forums reacting to v30.)
Let’s look at what happened on other chains when they opened the data sluice.
Here’s the hard evidence, chain by chain.
Bitcoin SV (BSV) — “raise OP_RETURN to 100 KB, get the nightmare”
In late 2018/early 2019 BSV expanded OP_RETURN from ~80 bytes to 100,000 bytes to market the chain as a “data ledger”. Within days, child-sex-abuse material (CSAM) was reported embedded directly in BSV transactions; explorers and apps scrambled to filter content; the episode became a staple cautionary tale.
That is the closest mechanical analog to v30’s practical effect.
Once content risk is acknowledged, proposals to amend or prune ledgers appear — opening the door to “compliant Bitcoin” narratives.
Bitcoin (legacy incidents) — tiny payloads still produced big legal risk
Well before inscriptions, researchers cataloged >1,600 files already stored on Bitcoin; some items were judged potentially illegal in multiple jurisdictions, leading to the now-famous conclusion: mere possession of the blockchain can be unlawful in some countries. That was with small carrier channels. Scale them up and you scale the exposure.
Incentives > ideals; control > fairness; stability > truth
Attacker incentives (including state actors): Cheap way to manufacture a governance crisis. A single, well-timed content drop can (a) sow reputational damage; (b) justify policy clients, pruning, or licensed-node regimes; (c) fracture the network between “hardened/filtered” vs “purist” implementations. This is asymmetric warfare.
Core-maintainer incentives: Reduce UTXO pollution by pushing data into OP_RETURN; align policy with what miners already mine; improve “transparency”. But revealed preference across chains shows: when you grow the pipe, abuse finds it first.
Regulatory incentives: Use a scandal to demand operational compliance (filters, attestations, registries), framing it as “protecting the public”. Stability beats ideals in a low-consent regime.
Implications for Bitcoin if v30’s defaults stick (worst-case read)
Near-term: One or more high-salience payloads are injected post-upgrade (because why wouldn’t an adversary do the obvious?). Press cycle triggers host-level bans (cloud providers, app stores), enterprise GRC (governance, risk management and compliance) policies against running unfiltered nodes, and payment-processor derisking around non-KYC wallets.
Medium-term: Emergence of “policy clients” (filter/deny templates) blessed by exchanges, insurers, or large pools; optional pruning attestations to keep infra legal. Result: validation centralizes; “sovereign nodes” become a legal liability hobby. Settlement becomes steerable through a handful of compliant relays.
Long-term: Bitcoin remains as supervised Store-of-Value (ETFs, qualified custodians), with Medium-of-Exchange throttled (KYC, travel rule, blacklist propagation). Price cycles persist but are managed (contained rallies, capped blow-offs), while the self-custody minority bears rising friction.
That arc is not theoretical — it’s exactly what we watched elsewhere once data channels got wider and the worst actors demonstrated the edge-case.
So has Bitcoin Core been attacking Bitcoin’s sovereign/Medium-of-Exchange use? I think the answer is pretty obvious.
Opening the gates to non-monetary data has already produced illegal content incidents on other chains; it will be exploited again if it’s cheaper/easier by default.
If you care about Bitcoin’s Medium-of-Exchange path, the play is not to recite ideals — it’s to constrain the attack surface at the policy edge and refuse defaults that make adversarial economics easier.
Bitcoin Core’s removal of Bitcoin’s definition from their GitHub repository
Bitcoin Core’s developers have even decided to remove Bitcoin’s definition from their GitHub repository.
I wonder why that is. Could it be because the changes they’ve made to the protocol are misaligned with the definition of Bitcoin they previously used?
You can use the wayback machine (archive.org) to see what Bitcoin Core’s repository looked like before they removed Bitcoin’s definition.
And here is what the repository looks like after they’ve removed Bitcoin’s definition.
No mention of what Bitcoin is. So they are changing something they can’t define or won’t define because the definition most Bitcoiners agree with is misaligned with their updates to the protocol.
Bottom Line
None of these updates were sold as “anti-Medium-of-Exchange”.
But incentives quietly reshaped the network:
Cheaper witness data, more flexible scripts, Replace-By-Fee normalization, relay rules favoring capital, and mounting node-operator liability — together they nudge Bitcoin away from being sovereign peer-to-peer cash and toward being a settlement and investment asset.
That’s the revealed preference — not a bug, but a feature of the system’s current equilibrium.
Every “neutral” policy that maximizes miner revenue or network throughput has revealed outcomes: data is cheap, payments are second-class, sovereignty is costly, central points grow.
More context: