Control-Plane Capital's avatar
Control-Plane Capital
.
npub1x9hg...6rta
Truth seeker
Control-Plane Capital's avatar
buckyfonds 7 months ago
I wonder how many Bitcoiners have a good understanding of who holds the actual power and who sets the rules. And this is a topic I'll have to write about but I already alluded to it in ( ). And namely, governance activations show who sets the rules. 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. So power concentrates among aligned institutional actors. Net effect: - Technical ideals matter less than coordination leverage. - Future upgrades will likely follow similar political dynamics. 1) 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. 2) 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. 3) 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. 4) 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. 5) 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. States would like to keep their monopoly on money issuance and aren't fond of permissionless money. Bitcoin's survival and adoption, as censorship-resistant money, depend on whether its most committed users can detect, coordinate, and counter inevitable policy, market, and social attacks. This is tough to do if you're oblivious to what's happening. It doesn't help that Bitcoin mining is awfully centralized ( ). The solution of course is a more vigilant community and more decentralization everywhere: - miner-selected templates (DATUM/Stratum V2), - more viable client implementations, - privacy and self-custody defaults and better non-custodial payments UX, - routing around perimeters (App-store independence, Cloud independence, ISP resilience, etc), - routine, verifiable Proof-of-Reserves across custodians (anti-Paperization).
Control-Plane Capital's avatar
buckyfonds 7 months ago
Started doing more research on how Bitcoin Core's developers have been attacking its sovereign/Medium-of-Exchange use a while back and it's wild. The post became too long for email just from covering: 1. SegWit (BIP141): The “Witness Discount” and Block-Weight Accounting 2. Taproot (BIP340–342): Easier Complex Scripts and Data Embedding 3. Liberalized Data-Carrier Policies (OP_RETURN and “Standardness”) 4. Replace-By-Fee (RBF): From Opt-In to Broad Default 5. Relay and Mempool Settings that favor Large Players 6. Legal-Risk Externalities shifted to Node Operators 7. Increased Block Weight → Centralization Pressure 8. Convenience Defaults: Assumevalid, Pruning, and Checkpoints 9. Deprecation of Non-Standard Scripts 10. Fee-Market “Purism” — No Priority for Payments 11. Lightning Network Bias — L1 as Settlement Only 12. Governance Activations Show Who Sets the Rules 13. Quiet Merchant De-Feature: BIP70 Payment Protocol Deprecation 14. Removal of “Priority by Coin Age” & Free Relay (historical) 15. Dust Limits & MinRelayFee Floors as Gatekeepers 16. Core v30: OP_RETURN/data-carrier expansion (policy) 17. Core v30: RBF ergonomics tilt further to replaceability (wallet/API surface) 18. Core v30: Multiple OP_RETURNs per tx Have written this in as simple as possible terms for non-developers. Will post later when done. image
Control-Plane Capital's avatar
buckyfonds 7 months ago
Bitcoin Core's attack on Bitcoin's user base is fascinating. As a programmer, one of the first things you'll learn is to create useful abstractions and not leak implementation details onto your user base. This is crucial if most of your user base is non-technical. TL;DR - What happens when implementation details leak to a non-technical crowd When core developers narrate mempool policy, witness discounts, inscription paths, version bits, OP_RETURN limits, and soft-fork mechanics to a mostly non-technical user base, governance "leaks" without ceding control. Users inherit responsibility (anxiety, vigilance costs) but not power (they don't run code audits, write policy clients, or operate pools). In a low Gross Consent Product world, this leak is useful to the Controllers and intermediaries because it: - Expands the social attack surface (narratives, panic, brigading) while concentrating technical leverage (maintainers, pools, relay policy, app-store distribution). - Raises the "cost of being sovereign" (time, knowledge, operational burden), pushing the median user toward paperization (ETFs, custodians, on-ramp wallets). - Creates manufactured "consent cycles" — public comment drama around esoterica (v30 defaults, policy limits) that legitimize changes after the audience tires out. Leaking implementation details to the masses doesn't democratize Bitcoin; it socializes worry and privatizes control. In a low Gross Consent Product regime, that's a feature: it nudges users toward policy-safe defaults while maintaining the narrative of openness. Expect rising paper share, falling realized volatility, steerable settlement via pools/relays, and Medium-of-Exchange throttled in favor of stablecoins/CBDCs. It goes much deeper and I'll cover this in more detail later.
Control-Plane Capital's avatar
buckyfonds 7 months ago
I wrote on article on whether Bitcoin is decentralized and secure or is allowed to look decentralized and secure. Feel free to debunk it. TL;DR Bitcoin is permissionless in code but permissioned in practice by choke-points that governments and large intermediaries either directly control or can cheaply coerce. It’s allowed to look decentralized/secure so long as it functions primarily as a supervised store of value and speculative asset, not a mass medium of exchange outside compliance rails. Bitcoin’s design is decentralized in protocol, but the real-world control surface has shifted into layers above consensus: pools, clouds, app stores, and custody perimeters. These are the quiet levers that steer usage without changing the code.
Control-Plane Capital's avatar
buckyfonds 7 months ago
The question that sent me down the rabbit hole a few months ago: - Is Bitcoin decentralized and secure, or is it allowed to look decentralized and secure? TL;DR Bitcoin is permissionless in code but permissioned in practice by choke-points that governments and large intermediaries either directly control or can cheaply coerce. It's allowed to look decentralized/secure so long as it functions primarily as a supervised store of value and speculative asset, not a mass medium of exchange outside compliance rails.
Control-Plane Capital's avatar
buckyfonds 7 months ago
Something interesting to Game Theory. What would happen in the unlikely scenario that the plebs try to un-capture Bitcoin now that it's so entrenched into the financial system. It's a bit late in the game for it to get the full Monero treatment. Assume a materially higher Bitcoin Community Vigilance & Coordination (CVC): client diversity rises, mempool policy hardens, mining/pool governance decentralizes, anti-paperization/Proof-of-Reserve norms spread, and the community routes around choke points. Things that would be interesting to cover: - What "Operation Un-Capture" looks like in practice - Likely state/industry reaction - Likely outcomes - Price/vol & adoption dynamics - What would work for the plebs (and what backfires) My quick read is that the most likely outcome is a two-tier Bitcoin. - Tier 1 (Compliant BTC): ETF/custodial flows, payment gateways, regulated L2s. Clean UTXO sets fetch slight premium, fast merchant acceptance, low frictions — but full surveillance. - Tier 2 (Sovereign BTC): self-custody, privacy-hardened clients, peer channels; on/off-ramp friction rises, spreads widen, but actual censorship resistance improves.
Control-Plane Capital's avatar
buckyfonds 7 months ago
Most of Bitcoin's success rides on the Community: Suggested Improvements If you consume Bitcoin content, most of what's discussed are protocol-level truths. However, based on my research, Bitcoin's survival and adoption depend on whether its most committed users can detect, coordinate, and counter inevitable policy, market, and social attacks. The Drivers of Success - TL;DR - Community Vigilance and Coordination (CVC): 50% How quickly and effectively the core community mobilizes around threats — through client diversity, mempool policy control, mining/pool governance, anti-paperization norms, Proof-of-Reserves (PoR) culture, and censorship-resistance operations. - Policy-Perimeter Exposure (PPE): 25% The network’s exposure to choke-points such as app stores, banks, cloud providers, internet service providers, custodians, and exchanges — and its ability to route around them. - Economic and Game-Theory Design (EGT): 15% The soundness of incentive structures: fee and issuance security budgets, validator or miner incentives, and containment of Maximal Extractable Value (MEV). - Protocol and Infrastructure Quality (PIQ): 10% The technical foundation: client maturity, developer tooling, code audits, and use of formal verification methods. I've written about this and suggested improvements here: https://controlplanecapital.com/p/most-of-bitcoins-success-rides-on
Control-Plane Capital's avatar
buckyfonds 7 months ago
Bitcoin's development process has been broken for a long time and Bitcoin's developers have failed the community. Developers have to start treating Bitcoin's users as stakeholders, not an audience they have contempt for. I wrote the first Bitcoin Development Governance Proposal (BDGP-1). This is a rough draft. If someone wants to work on it further/take the idea and write a better proposal, feel free to. https://controlplanecapital.com/p/bitcoin-development-governance-proposal
Control-Plane Capital's avatar
buckyfonds 7 months ago
How Bitcoin's developers have failed the community This will not be a technical post, I can eventually write one on the specifics of how Bitcoin's developers have weakened Bitcoin’s sovereign / monetary (MoE) use. In this post, I'll cover the predictable chaos that developer have caused. 99% of users should have never had to know what OP_RETURN is — and the fact they do means Bitcoin's developers have failed the community. The fact that non-technical users have had to learn about these details is a massive failure on the part of the developers. Now you have users taking sides on a soft-fork debate purely based on their blind faith in influencers without understanding the technicalities. When UX abstraction fails, politics invades the base layer: - Money that requires protocol literacy isn't money yet. If non-technical holders must parse mempool policy, witness discounts, inscription hacks, or soft-fork signaling to judge existential risk, you've leaked governance from experts to the masses without giving them power — just anxiety. - Abstraction debt. Bitcoin's developers are no longer shipping "safe defaults". That created a vacuum where influencers do protocol comms, and users pick tribes by vibes. - Legitimacy hazard. The minute regulars think "the rules can shift under me", your store-of-value narrative becomes contingent on whoever writes/merges code, not on time. That's a reputational tax that compounds. In the Bitcoin ecosystem (developers, miners/pools, exchanges/custodians, state/regulators), no actor with power is optimizing for "simple, sovereign Medium-of-Exchange for the masses". They optimize for revenue, deniability, and policy compatibility. All of this chaos and retail anxiety caused by developers will lead more people to ETFs/custody adoption and will lessen self-custody and MoE use. If node policy changes keep enabling more and easier illegal payloads, pressure lands on runners/miners first. Captured developers is the most asymmetric attack vector - it hits sovereign users hardest, while leaving institutional wrappers unaffected. Developers have to start treating Bitcoin's users as stakeholders, not an audience they have contempt for. The only way out of this is for the users to start working on a rough draft of constraints that should be imposed on the developers. I might write a very rough version eventually.