“Government agents are not active in Bitcoin developer and influencer circles.”
– Government Agents, probably
As the war for global monetary supremacy wages on, you have to assume that the state is actively operating information warfare. This means that the state is operating and acting in order to preserve and expand it’s own power. For that reason, it is sane and reasonable to assume that state operators are in the trenches of Bitcoin attempting to influence public perception, developer activity, and overall bitcoin adoption. If you think this is not happening then you are naive or you’re incentivized to act against bitcoin in a different way. The sabotage of Bitcoin is not some tin foil hat conspiracy, the sabotage of Bitcoin is actively playing out in real time, but the big question is where the sabotage is taking place and what can you do to identify and act to counter the sabotage?
So let’s zoom into Bitcoin of today, where conversation is happening around the future of Bitcoin in regards to dealing with Ordinals, or spam (if you are part of that camp)1. The rise of Ordinals last year and the pressure they have caused on blockspace demand has surfaced new rivalries within the bitcoin maximalist community as memetic warfare is waged on what bitcoin is and how it should be used. The purpose of this article is not to make a political stand in this fight, but to point out places in Bitcoin that are prone to sabotage and where active sabotage campaigns might be actively waged. Seeing this division in a once undivided front is enough to make one pause and consider what external forces are at work.
Bitcoin’s Power Balance
As we consider the infighting happening within Bitcoin, it is important to understand the different parties within bitcoin and how each of the powers balance each other out. In 2019, Nic Carter illustrated Bitcoin’s Power Balance Model. This model shows the key roles in Bitcoin and the relationship between each one. You can see the circular feedback loop between Miners -> Devs -> Economic Nodes. In a vacuum these three roles would perpetually pump each other with nothing to keep them in check. At the heart of the model are the Users who keep Devs and Economic nodes in check.
The one factor in the power model that touches each of the player in the model is the software of code. The software touches each of the roles in one way or another and this is probably the largest threat vector to all of Bitcoin. The simple activity of running code is how Bitcoin is eating the monetary world, so it is probably worth understanding the development process.
Bitcoin Development Process
Let’s now dig into the Bitcoin development process. As you know, making changes to Bitcoin is a slow and deliberate process. This is a big change from the “move fast and break things” mentality of Silicon Valley. Many argue that this slow methodical process is actually one of Bitcoin’s greatest strengths. In 2011, Gwern published “Bitcoin Is Worse Is Better” where he says “However, in an example of ‘Worse is Better’, the ugly inefficient prototype of Bitcoin successfully created a secure decentralized digital currency, which can wait indefinitely for success, and this was enough to eventually lead to adoption, improvement, and growth into a secure global digital currency.” This ugly inefficient code has gotten us here today, 15 years later, and in that time the slow methodical approach to Bitcoin development has been and will probably continue to be a part of the developer ethos.
The development process has even been formally documented in BIP 2 (Bitcoin Improvement Proposal). Here are the general steps in the BIP activation process:
- Drafting the BIP: The first step is to draft a BIP following the template outlined in BIP2. This includes writing a detailed document or white paper that outlines the proposed changes. The BIP should be comprehensive, covering motivation, technical specifications, and rationale.
- Discussion and Feedback: Once the BIP is drafted, it’s shared with the Bitcoin community for discussion and feedback and usually happens on platforms like the Bitcoin Dev mailing list, GitHub, and even Twitter. The purpose is to solicit feedback, refine the proposal, and begin to build consensus around it.
- Assigning a BIP Number: If the BIP is deemed to have potential and is unique, it’s assigned a BIP number by a BIP editor. This is a formal acknowledgment that the BIP is under consideration.
- Formal Review: After the BIP is assigned a number, it enters a formal review phase. During this time, the BIP is scrutinized for technical soundness, feasibility, and compatibility with the Bitcoin protocol. This is where the devs try to break the bip and poke holes in the proposal.
- Revisions: Based on feedback and review, the BIP may undergo several revisions.
- Implementation: Once consensus is reached, the BIP is implemented in the Bitcoin Core codebase. This step involves actual coding and rigorous testing to ensure that the changes work as intended without introducing new vulnerabilities.
- Reaching Consensus: For a BIP to move forward, it needs to reach consensus among the Bitcoin development community. This is often the most challenging part, as Bitcoin’s decentralized nature means that a wide range of stakeholders (developers, miners, users, etc.) need to agree on the change.
- Deployment: After implementation & consensus, the new version of Bitcoin Core including the BIP is released. Depending on the nature of the BIP, it might require a majority of miners or nodes to upgrade to the new version for the changes to take full effect.
- Activation: Finally, once the required threshold of network participants has adopted the new version, the changes proposed in the BIP are activated on the Bitcoin network.
Reading through this is incredibly helpful in understanding how change happens to Bitcoin. The problem I see is where are the single point of failures in this process and who the gatekeepers2 are for each step. Conversations happening in channels now are surfacing weak points or non documented parts of the development cycle. For example, Bitcoin Inquisition. This is the in space between steps 2 and 3.
Bitcoin Inquisition
Bitcoin Inquisition is a non-documented part of the Bitcoin development process. It was proposed by and administered by AJ Towns in 2022. Here is a very brief summary of why and what it is.
“I think the weakest link in that [bitcoin development] loop is the first one: what if we did activate soft forks on the default signet prior to the code being merged into core? To that end, I’m proposing a fork of core that I’m calling “bitcoin-inquisition”, with the idea that it branches from stable releases of core and adds support for proposed changes to consensus (CTV, ANYPREVOUT, TLUV, OP_CAT, etc…) and potentially also relay policy (relay changes are often implied by consensus changes, but also potentially things like package relay).”
– AJ Towns on Bitcoin Inquisition
The reality is that the Bitcoin Inquisition is live and well. AJ runs a special separate fork of Bitcoin core and acts as the sole admin for testing BIP’s. This is not documented in BIP-2, but has just been accepted as process by core devs. This is a curious development of how tribal devs can make changes how they see fit, without documentation.
The Bitcoin Sabotage
At this point we’ve run through the roles in Bitcoin, the steps in the development process, and even identified a glaring hole in the development process. Let’s now dig into what is sabotage.
Sabotage. (noun) /ˈsæb.ə.tɑːʒ/
Definition: The deliberate destruction, damage, or obstruction of something, typically for political or military advantage. Sabotage is often carried out covertly and with the intention of hindering operations, activities, or plans of an opponent or competitor.
Verb Form: Sabotage (sabotaging, sabotaged)
Usage in a Sentence: “The bridge collapse was found to be the result of sabotage by enemy agents.”
For purpose of this article, let’s frame sabotage specifically in relation to Bitcoin Sabotage. Bitcoin Sabotage is the deliberate destruction of Bitcoin, or obstruction of Bitcoin development or adoption, for political advantage. This is the frame. This is what we are up against. With that in mind let’s now dig into how sabotage is waged. Conveniently our very own CIA is masters at sabotage and have been waging sabotage tactics in warfare for over a century.
Simple Sabotage Field Manual
In the 1940’s, the CIA shipped a field manual called Simple Sabotage Field Manual. The purpose of this was to distribute to operators a practical manual on how to conduct sabotage operations behind enemy lines. While this manual is 80 years old, it reveals some classical tactics in the art of sabotage.
This “Simple Sabotage” is a unique look at how sly the military is when it comes to unconventional warfare. This manual was developed in the 1940’s and you have to wonder how many more hours and resources have gone into modernizing this same document and other classified operators manuals. For purpose of this article, we will examine the Specific Suggestions for Sabotage sections focused on Organizations and Conferences & Managers and Supervisors.
- Organizations and Conferences
- Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions.
- Make “speeches,” Talk as frequently as possible and at great length., Illustrate your points by long anecdotes and accounts of personal experiences. Never hesitate to make a few appropriate patriotic” comments.
- When possible, refer all matters to committees, for “further study and consideration.” Attempt to make the committees as large as possible – never less than five.
- Bring up irrelevant issues as frequently as possible.
- Haggle over precise wordings of communications, minutes, resolutions.
- Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision.
- Advocate “caution.” Be unreasonable” and urge your fellow-conferees to be “reasonable” and avoid haste which might result in embarrassments or difficulties later on.
- Be worried about the propriety of any decision – raise the question of whether such action as is contemplated Hes within the jurisdiction of the group 01’whether it might conflict with the policy of some higher echelon.
When I read Section A. Organizations and Conferences, I can’t help but think that Bitcoin development is being sabotaged, but I am a naive outsider. I am also a noticer. If I was going to sabotage Bitcoin, this field manual could easily be deployed from within developer circles. If you were a state operator with developing skills, it is reasonable to believe you could begin participating in code review process and make in roads and start having authority in matters.
Let’s outline sabotage tactics state operators could be executing:
- Miners – in the great blocksize wars, some large mining pools signaled with the Big Blockers. This was an attack on Bitcoin, but it demonstrates a specific action that Mining Pool operators could carry out in order to sabotage Bitcoin. While this DID NOT work in breaking Bitcoin, we learned that Users are at the heart of Bitcoin. A bigger problem could be if large pool operators were acting in coordination with other roles.
- Devs – this is perhaps the biggest vector for sabotage attack. As we see more value soaked up by Bitcoin, it will become a bigger target for state actors. That means we will have state operators submitting pull requests and participating in the development process. Based on the Simple Sabotage Field Manual, operators could easily carry out many of the tactics outlined above. We are already seeing very divisive positions from developers on how bitcoin should be, so you must wonder who is the operator.
- Users – since users give feedback to developers, you would assume that giving bad feedback could lead to developers building something that is not in bitcoins best interest. Or users could socially attack developers into doing certain things. Right now we are seeing meme warfare being waged within the maximalist community, and it can’t all be organic discourse. Users infighting can lead to maldevelopment. Also, what happens if a group of bad actors in the users and developers camps are aligned. Or what if users coordinate to influence certain developers?
- Economic Nodes – they choose what transactions make it to miners via the code they run. Users tell them what code to run because users spend money with them. Economic nodes could sabotage by supporting old code, or malicious sabotaged code.
In wrapping up this piece, the complex dynamics between miners, devs, users, and economic nodes within Bitcoin creates a ripe battle ground for meme warfare and Bitcoin Sabotage. The Bitcoin development process is without flaws and as outlined in the CIA’s Simple Sabotage Field Manual, there are many simple to deploy tactics that could be used to sabotage Bitcoin. This should serve as a sobering reality that Bitcoin is under attack and you should act accordingly.
The responsibility is on you, humble frog, to keep your head on a swivel. You must stay aware and call out bullshit. Whether it is combating gaslighting, carrying out ethical trolling, or reviewing code, all these actions count and help preserve our only realistic shot at a more free future. The survival and flourishing of Bitcoin depend not just on NGU and its technological robustness but equally on the collective vigilance the users. As we navigate these uncertain times, let us be guided commitment to cypherpunk ethos, critical thinking, and unwavering support for the core principles that underpin Bitcoin which is freedom. In doing this, we might have a chance at winning the game of Bitcoin Sabotage and defeating our enemy, the state.
