Luke de Wolf

I've taken a bit of a step back since BIP-110 activation day, both to collect my thoughts and to just take a break after an exhausting few months. Here's an update on me and many of my thoughts.

TL;DR: I'm taking a bit of a step back. I'm not forking off.

BIP-110

It's done now. I'm not moving to the new fork. Enough said about that.

My support was almost entirely around avoiding chaos, uncertainty, and fracturing the community. I'm sad to see many bitcoiners I respect losing faith in the project.

I have to admit, I've had to rethink a few things about how Bitcoin works.

One thing we definitely learned is that the popular narrative about 2017 was wrong. The UASF provided enough leverage to push SegWit over the line. It wasn't a minority of plebs forcing a change on their own. Those who insisted that 110 would play out the same was as 2017 were categorically wrong.

I also want to note, for the record, that I doubted that things would play out the way Luke, Mechanic, and others predicted, and I have receipts. Hindsight is 20/20. I chose to push for the possibility that wouldn't result in a hard fork away. It didn't play out like that.

I now understand that the "economic weight" metric is completely real. That's the only way a node actually plays any direct role on the network. At the same time, running a node is still important for you. Your node enables your self-sovereignty. Nothing is lost by a minority of nodes being unable to force changes through on the network.

At the same time, I truly believe that 110 wasn't a sybil attack, at least not entirely. Real users had and have real grievances over Bitcoin's development. I don't excuse the choices that Core have made, nor the behavior of many on the 110 opposition side. There were opportunities to compromise, lower the temperature, and keep the community from fracturing. Then again, Luke also refused opportunities to compromise. It takes two. Maybe a hard fork was inevitable.

My position was mine. My own. The whole time. I was not mislead. I wasn't duped into anything. I listened to people saying very different things, and I made my own choices. I'll live with them.

Where I Go From Here

I'm taking a step back from many of my Bitcoin activities, partially but not entirely because my second child is due next month. I'm also hard at work pulling the final details together for BTCHEL (which I might not even get to attend, depending on my coming baby's world-entry preferences!). I'm excited to see many of my friends in the community in my home city one more time.

Then, I'm still confirmed to speak at the Plan B Forum in Lugano in October. After that, I have no plans to attend conferences for the foreseeable future.

Similarly, I've also officially stepped away from the Bitcoin Infinity Show. I'm no longer editing or producing episodes. I'm still going to help Knut and team maintain continuity and advising on future direction, but I'm not involved in the show itself anymore. We still have the Bitcoin Infinity Store and help friends in the space to publish books. I still enjoy that work, and I'm happy to do it.

I'm happy with what I was able to produce with Defending Bitcoin. I'm glad to make that Bitcoin cybersecurity resource available for free, and I appreciate any support by buying a physical copy. That book, unfortunately, is already quite out of date. That's what happens in fast-moving fields. I'll aim to carve out some time to update key chapters, especially relating to the effects of AI. I might make some quick changes to certain recommendations on the web version. In any case, I hope the book is still helpful to those who want to learn more about Bitcoin cybersecurity.

I largely plan to stay out of debates about Bitcoin's governance and future. It would be too strong to say that I don't care at all about those things, but I'll largely leave those things to the development community. Things like covenants are totally fine by me, in principle. BIP-54 is probably OK too, although it contains a similar edge confiscation risk as 110. If standards were applied consistently, BIP-54 would need to resolve that confiscation risk. But, I'm not going to play the contrarian and stand in opposition. I hope nobody wants to touch the 21 million cap any time soon. I'll lose interest if that ever happens, to put it mildly.

I'm happy for those who contribute to Bitcoin in their own way to continue to do so. I'm saddened by any personal conflicts that have arisen over the last months and years. I'm willing to put those issues behind me. Toxicity doesn't suit me. I'll leave that to others.

I would be lying if I said my enthusiasm for Bitcoin is as high as it was a few months ago. I'm definitely rethinking the effort I'm putting into the space. We'll see how long this break turns out to be. For the next months, at least, I'm focusing on my family. When I've regained some energy, maybe I'll put my focus back towards contributing more to the Bitcoin security space, and on adoption and education in general. I'll still be around, here on X. But I likely won't be so active for the foreseeable future.

I'm still excited to see everyone coming to Helsinki! We just finished the schedule, and I'm just as excited as last year. Maybe even more! At the same time, I'm looking forward to getting to the other side, and finally taking a break.

See you all out there. Take care.

My final thoughts on BIP-110:

TL;DR: I believe BIP-110 activating smoothly is preferable to and less disruptive than a hard fork away from the network. I hope 110 activates smoothly in the coming days, but I will not follow a hard fork away from Bitcoin if it fails. I will remove BIP-110 from my handle, admit I was wrong, and move on.

I also advise everyone not to submit transactions that are likely to be mined in the blocks immediately after activation to minimize the potential for disruption or undesired outcomes.

I went from supporting 110 to opposing it, back to supporting again. Here's why:

I've always seen something wrong with arbitrary data on Bitcoin, and I've been intuitively against the need to grow adoption through new use cases. At the same time, I really felt that Bitcoin Core overstepped their mandate by changing the OP_RETURN default in v30, and I largely agree with Hodlonaut's assessment of that saga in his article series on the topic.

BIP-110 felt like a real way to influence the network back towards one that repudiates arbitrary data and doesn't leave node developers free reign to make changes to the protocol as long as there is no change to consensus code. I was involved in early discussions on the soft fork, and started running the client when it became available on Start9.

Still, I never felt that 110 was perfect. I thought it was incongruous for every limit to be set at 256 bytes except for OP_RETURN itself, and that it would be more consistent to apply a 256 byte limit there, also. Banning OP_IF and therefore breaking some functionalities of Miniscript also never seemed ideal, and I would have preferred finding a way to avoid that. Still, a fix to avoid OP_IF in Tapscript has been produced, so it's completely possible to avoid that disruption. Compromise and attempting to better achieve consensus would have been preferable to me.

I had conversations with many people, supporters and opponents, for months. I realized that much of my position came from my industrial cybersecurity experience, and the idea for my Bitcoin cybersecurity book, Defending Bitcoin, was born. I spent 6 months writing that book, and I'm proud of it. I just released it for free as a response to the Coldcard hack. I firmly believe in the importance of Bitcoin security education, and I hope my contribution is valuable to the space. For me, no matter what happens, this book was born from 110, and I'm glad it exists.

In the process of writing Defending Bitcoin, I evaluated the consequences of forks and chain splits on Bitcoin, and what these events look like from a risk perspective. These events are chaotic, messy, and potentially disruptive. Avoiding a chain split at all costs became my overriding position.

At the same time, I saw that consensus wasn't forming. Multiple groups of opposition have formed. One is technical, objecting to disruptions to applications using the restricted functions and to the limits on scriptability. Another is more philosophical, arguing that any restriction on "valid transactions" would constitute censorship. Yet another group was concerned mostly about the implications for Bitcoin's governance, what it would mean if a minority can force a change to Bitcoin.

I currently push back against all of those categories of objections, which I'll get to in a moment, but the bottom line is that I saw serious opposition emerging. Certainly not consensus. I was writing a book on risk analysis where I argue that a chain split or a fork without consensus is chaotic, messy, and risky. That's where I pulled my support for 110, and began advocating against following it. Bitcoin Mechanic said at one point that either 110 would succeed spectacularly or it would fizzle out quickly. I saw fizzling out quickly to be more likely and less disruptive than a prolonged fork scenario.

Still, my "opposition" was somewhat half-hearted. I still agreed with the goals of 110, and I disagree with many of the arguments against it. I never stopped running Knots with 110, mostly out of inertia. But, publicly, I did not support 110. I focused on finishing my book, and I got to have conversations with many 110 opponents with perhaps more clarity and willingness than if I were a 110 supporter.

After my book launched, however, I turned back towards the 110 debate and discussion. I re-evaluated the situation, and, just as there was staunch opposition, there were staunch proponents. Just as I spoke to opponents over the preceding few months, I also met many plebs who were running 110 for one reason or another. BIP-110 wasn't going anywhere, and that realization changed my thinking.

My Current Game Theory View

The entire proposition of 110 is that the miners will be compelled to signal by nodes threatening to throw away their blocks. One option involves risk of wipeout, and the other doesn't. That's the choice miners are faced with.

There also isn't any opposition in code. No URSF doesn't mean there's no opposition, or that there is consensus for 110. But it means that miners have no side saying "I'm going to reject your blocks if you signal for 110". Therefore, either the nodes enforcing 110 with the economic weight backing them is enough to convince the miners to signal and comply, or it isn't. BIP-110 will still either succeed or fail spectacularly and quickly. It will never catch up if it falls behind. Bitcoin isn't the longest chain. It's the longest chain of valid, accumulated proof-of-work. If the non-110 chain takes the lead and has majority hashrate, it's never giving it up.

Meanwhile, now there is talk of a proof-of-work change and a forced hard fork if 110 doesn't succeed in activating and becoming the longest chain. In the category of potential disruptions, I put that above all else.

Why A Hard Fork Would Be Bad

A hard fork off of Bitcoin would be terrible for the network. It would be centralizing in all possible metrics.

All nodes that follow the fork or turn off would be a loss for the Bitcoin network. That's a centralizing factor.

All plebs would had been mining and building their own blocks who choose to follow the fork or simply stop mining will no longer be mining on Bitcoin. That's a centralizing factor.

And, finally, all the monetary maximalists who believe Bitcoin's monetary properties need to be defended against use-case creep and crypto affinity scams who either follow the fork or decide to otherwise stop participating in Bitcoin would give up Bitcoin's governance to David Bailey, Michael Saylor, and the Core-industrial complex. That's a centralizing factor.

For all these reasons, I believe a hard fork is a bad outcome, and, therefore, 110's smooth activation is preferable.

Arguments Against Arguments Against 110

I said above that I disagree with most arguments against 110. I'll briefly state my counterpoints, just for the record.

First, the technical objections. Largely, these consist of opposition to "breaking" Miniscript, and opposition to limits on data embedding for scripting purposes. As mentioned, there's a fix to the Miniscript problem. Scripting limits is a more meta question and a bit of a philosophical difference.

Many of the developers I've spoken with want a large explore space to discover potential use-cases for Bitcoin. Murch recently described the situation as (light paraphrasing) "if Bitcoin is exciting to develop cool smart contracts, there has to be data embedding". In my view, and many others in the pro-110 camp, Bitcoin doesn't need to be "exciting" for developers. It needs to be functional money.

I attended Bitcoin++ in Vienna and was on a panel with Seedor Chris, Knut Svanholm, Matt Corallo, and Tiero, where we agreed that the vast majority of users just want to take their Bitcoin into self-custody and use it to pay for things. There is plenty of work to do to make taking self-custody easier, as we saw with the recent, massive Coldcard breach, and make medium-of-exchange better, as we saw with the shutdown of Boltz.

So, I don't agree that Bitcoin needs massive explore space on the base layer. Furthermore, I believe that practical limits are a positive security control to reduce attack surface and to reduce the viability of arbitrary-data embedding on Bitcoin. Ultimately, all security requires tradeoffs. It might become slightly more difficult to create "exciting smart contracts" on Bitcoin with BIP-110's rules, but those limits would serve other purposes.

Regarding the objection that BIP-110 threatens Bitcoin's censorship-resistance and permissionlessness, I believe that this is a total red herring.

BIP-110 doesn't prevent anyone from transacting, from moving UTXOs from one address to another. BIP-110 also does not introduce a third party you ask permission from in order to transact. In fact, Bitcoin's permissionlessness is a bit misleading. While it's true that you don't ask permission of anyone to transact on the network, you absolutely ask permission of the nodes to accept your transaction, and you ask permission of the miners to include your transaction in a valid block. In other words, you always have to follow the rules of the protocol. And, if the network chooses to adjust those rules so that certain transaction patterns aren't allowed, you need to follow those rules in the future.

There's also a security angle here. If Bitcoin cannot roll back or restrict any "currently valid" transaction type, Bitcoin will eventually be killed by the unforeseen consequences of some future upgrade. Taproot has been in place for over 5 years, and its negative consequences were apparently after less than 2 years. More than 99% of Taproot outputs are dust. The outcome of Taproot is clear: it's primarily being used for data embedding activity that has nothing to do with Bitcoin's monetary purpose. Rolling back some of the unrestricted data embedding capability of Taproot is a perfectly valid security response, especially after multiple years.

Finally, addressing the governance question: this is the objection that convinced me the most in preceding months. Voices like Giacomo Zucco and Samson Mow have argued that the precedent set by BIP-110 would be bad for Bitcoin in the long term. That a minority being able to change the network without widespread consensus would be viewed negatively. My response and pushback here is that users are running software. If some minority percentage of nodes running new software is enough to convince the miners to signal and comply with the new rules, then that's Bitcoin's consensus mechanism working as designed. The precedent might not seem nice, but it was entirely within the realm of possibility.

Put another way, if BIP-110 succeeds, we'll learn that there is some threshold of nodes with some amount of economic weight that is enough to get miners to comply with their new rules. If there are future soft-fork proposals that portions of the network disagree with, they'll need to object in code and run a URSF.

What If 110 Fails?

I fully acknowledge that it's possible for the miners to simply not signal. BIP-110 will be dead in the water if it maintains the current signaling past the activation point.

A large part of the argument that 110 will succeed is based on the precedent from the block size wars, where BIP-148 succeeded in compelling miners to activate SegWit. But, if 110 doesn't succeed, we will have learned that the lesson from 2017 was something different. In 2017, the miners tried to force a block size increase on the nodes, agreeing to adopt SegWit, but only if paired with a 2x block increase. The nodes, through BIP-148, rejected that increase, and insisted on SegWit's activation regardless. SegWit has broad consensus at that point, even with miners. Later, Bitcoin Cash implemented the block size increase and forked off from Bitcoin. The nodes rejected the change, they didn't necessarily force a change themselves.

If 110 fails, it will be because the miners can reject a change proposed by a minority of nodes. 110 proponents will need to similarly conduct their own hard fork and form a new chain if they want to enforce their rules into the future.

Bitcoin will have proven its resistance to change, again. And that, I believe, is the only silver lining here.

However, I won't be happy to see many bitcoiners I respect choosing to abandon Bitcoin and follow a hard fork off the network. Many of them say that it's the rest of the chain forking off. I reject that framing. A minority changing the rules to get rid of the proof-of-work algorithm and reject all the ASICs currently mining Bitcoin is a new chain. They can say that it's more true to Bitcoin's purpose, but it won't be the canonical Bitcoin. I don't think there's any value in pretending that the outside world will view the fork as Bitcoin's successor. Engage honestly with reality.

I won't be following a hard fork away from Bitcoin. I don't know that I'll have the same enthusiasm to engage with Bitcoin from that point forward, especially if many people from the space that I respect choose to leave.

This is another reason why I'm happy that I produced Defending Bitcoin when I did. I hope that contribution ends up being valuable to bitcoiners regardless of the outcome of this fork. Even if I step back from contributing to Bitcoin education or adoption, that book will be out there.

What To Do At Activation Day

My concrete advice is to avoid transacting leading up to the activation height and through until we have clarity. I don't believe that clarity will take long. Either 110 will get overwhelming, essentially unanimous support immediately, or it will maintain its current level of hashrate and be dead in the water. That's a prediction. It's possible it takes longer to resolve. But I believe it will be quick.

Then, once we know the outcome either way, move on. Transact as normal. Either BIP-110 is in effect for a year, or it isn't. I will be turning my attention 100% to BTCHEL just around the corner, and after that, who knows? BIP-110's outcome will likely have a lot to do with my plans going forward.

Regardless of anything else, I'm going to be glad for this all to be over.

As a response to the ongoing Coldcard hack and other AI-related issues going on, I've decided to make Defending Bitcoin available entirely for free on https:// defendingbitcoin.com/reader

It was always in the plan to create a sort of "reader companion", and I'll be adding more features to cross-link the contents of the book with useful information on how to improve your Bitcoin security. But, for now, the entire text of Defending Bitcoin is readable from your browser.

AND we've finally added it to the Bitcoin Infinity Store at https:// bitcoininfinitystore.com, along with Max Hillebrand's Praxeology of Privacy (also freely available on Max's website). If you want to support either of us, you can now do so with Bitcoin.

I also plan to update the chapter on AI Risks. I honestly hadn't anticipated quite how brutally AI attacks would hit, and, like most others, I certainly didn't expect one of the most widely-recommended hardware wallet manufacturers had simply neglected to implement such a fundamental feature as secure seed generation. In hindsight, I should have emphasized the risk of AI attack capabilities more strongly.

I hope Defending Bitcoin can be useful to anyone looking to improve their Bitcoin security. Let me know what you think, and stay secure out there.

I'm live on Stacker News right now!

https://stacker.news/items/1524157

Ask me about Bitcoin cybersecurity, BTCHEL, BIP-110, or anything else!

Join me in a few hours and AMA!

Defending Bitcoin is out!

It's available now on Amazon in paperback, hardcover, and ebook editions. Pick up your copy today!

This is Bitcoin cybersecurity through the industrial lens I've spent the last decade working in. Defense for your Bitcoin and defense for the network. From custodial failures to quantum computing, the full threat landscape is here.

Huge thank you to everyone who helped with this massive project. I couldn't have done it without you!

Interesting dashboard about the impact of Bitcoin on my long-time home province.

Check out my latest podcast appearance on The Bitcoin Way podcast. These guys are on the front line of Bitcoin security, and I thoroughly enjoyed our conversation!

Chapter 4 of Defending Bitcoin - Industrial Control Systems and Securing Critical Infrastructure.

This one is from my career defending the industrial systems that keep the world running.

Industrial control systems are the computer and network layers running physical processes. Power plants. Water treatment facilities. Pipelines. Factory floors. When one of these systems gets hit, it's not a website that goes down, it's a real-world process that stops or fails in a way that can hurt people.

Defending these systems is a different job from defending a website. The IT side of cybersecurity can usually patch on a schedule and tolerate a few minutes of downtime. The operational side often can't, because the plant has to keep running, and any unplanned stop has real consequences. The two sides optimize for opposite things.

Chapter 4 walks through the architecture, the controls, and the culture of this critical infrastructure security. How a plant gets organized into network zones so a single compromise stays contained. How we organize security controls into categories, and use security levels to scale them up to resist a determined nation-state. How the IT and OT mindsets converge when you have to defend something that absolutely cannot fail.

This is the framework the rest of the book uses. Every threat chapter in Part II uses the ideas and vocabulary from Chapter 4. Next, we see how it all connects and applies to Bitcoin.

Chapter 4 of Defending Bitcoin - Industrial Control Systems and Securing Critical Infrastructure.

This one is from my career defending the industrial systems that keep the world running.

Industrial control systems are the computer and network layers running physical processes. Power plants. Water treatment facilities. Pipelines. Factory floors. When one of these systems gets hit, it's not a website that goes down, it's a real-world process that stops or fails in a way that can hurt people.

Defending these systems is a different job from defending a website. The IT side of cybersecurity can usually patch on a schedule and tolerate a few minutes of downtime. The operational side often can't, because the plant has to keep running, and any unplanned stop has real consequences. The two sides optimize for opposite things.

Chapter 4 walks through the architecture, the controls, and the culture of this critical infrastructure security. How a plant gets organized into network zones so a single compromise stays contained. How we organize security controls into categories, and use security levels to scale them up to resist a determined nation-state. How the IT and OT mindsets converge when you have to defend something that absolutely cannot fail.

This is the framework the rest of the book uses. Every threat chapter in Part II uses the ideas and vocabulary from Chapter 4. Next, we see how it all connects and applies to Bitcoin.

I had a great time telling Daniel all about Defending Bitcoin. Give it a listen to find out more about the book! We also cover the BIP-110 situation in quite a bit of deal, with my current reasoning made abundantly clear.

This is where the cybersecurity side of the book starts. Chapter 3 walks the core concepts the rest of the book runs on, in plain language.

It opens with the CIA triad (just a coincidence, I promise!), the three properties cybersecurity defends in every system. Confidentiality keeps information from anyone who shouldn't have it, integrity keeps it from being altered without authorization, and availability keeps it reachable for the people who need it. Every threat in Part II maps back to one of those three.

From there it gets into threat modeling, which is a structured discipline rather than a vibes-check. Before you defend anything, you ask who the adversary is, what the asset is, where the attack surface lies, and what the mitigation looks like. Run that formally and some threats turn out to be less important, while others turn out larger than you'd expect.

Then comes defense in depth, which is just the principle that you never lean on a single control. You layer them so each one stands on its own, and a failure in one doesn't cascade through the rest. The chapter walks how to design those layers so the whole system doesn't unwind from a single point.

We also formally define the concept of risk, measured as likelihood times impact. A threat that's devastating but unlikely calls for different controls than one that's common but survivable, and that matrix is how Part II keeps everything in proportion. Without it, the threat chapters that follow would read like a long list instead of a prioritized map.

By the end, you've got the cybersecurity vocabulary that the rest of the book depends on, and the bridge from "I hold Bitcoin" to "I'm responsible for defending a system I have a stake in."

Write a review on Amazon if you've read and liked Max's book! It helps the algorithm and gets this book in front of more eyes. Fiat bullshit and all that, but it works.

Max's book is seriously excellent, check it out if you haven't already!

Chapter 2 of Defending Bitcoin. Bitcoin — The Hardest Money Ever Made.

This chapter walks the case from first principles. Scarcity that can't be debased. Verifiability without trust. Ownership without anyone's permission. A supply schedule fixed in code and enforced by every node.

It's my distillation of Bitcoin's monetary principles. This chapter will be familiar reading for most bitcoiners, but it gets us all up to speed. For the technical reader who is approaching Bitcoin for the first time through this book, it's an introduction to Bitcoin as money.

If you want to read Defending Bitcoin right now, sign up for an advance copy below. All I ask is that you leave a review after the book launches:

https://defendingbitcoin.com/advance-copy

The BTCHEL train keeps on rolling! Hopefully see you there this September.

I want to talk about Defending Bitcoin on as many podcasts as possible and get the word out. Who would you recommend I talk to? Any Bitcoin podcasters here who would like to have me on?

Defending Bitcoin lands on June 15th, in just under a month. Between now and then, I'm going to preview what's inside, one chapter at a time.

Chapter 1, Bitcoin: The Decentralized Protocol.

I had to make a choice with the opening chapter. Start with the monetary features, or start with the protocol. I went with the latter, because I figure that technical non-Bitcoiners (such as those who might read a cybersecurity book) might be more comfortable with the technical side of things.

So, Chapter 1 walks the protocol from first principles. Nodes, miners, the mempool, the difficulty adjustment. The architecture of decentralization. Building up the how before getting to the why.

Bitcoiners get a refresher. The dual-track approach runs the length of the book.

If you'd like to read Defending Bitcoin now, sign up to become an early reviewer on the book's website: https://defendingbitcoin.com/advance-copy

Look inside my upcoming book, Defending Bitcoin: Industrial-Grade Cybersecurity for the Monetary Grid 👇

First, the Foreword by Mikko Hyppönen. One of the most widely-respected figures in cybersecurity with his own take on Bitcoin. I'm grateful that he agreed to contribute his view to the Defending Bitcoin!

Next the Introduction. My story of how I started in the Industrial Controls sector, then found Bitcoin, and merged the two worlds. Also goes over the format of Defending Bitcoin.

Part I is the introduction to Bitcoin and Cybersecurity, forming a basis of vocabulary for readers familiar with either or neither subject.

Chapter 1. Bitcoin — The Decentralized Protocol

All about Bitcoin the technology, written for technically-minded readers who don't know about how Bitcoin works.

Chapter 2. Bitcoin — The Hardest Money Ever Made

All about Bitcoin the money. What makes Bitcoin's monetary properties different from every other money in history.

Chapter 3. Cybersecurity Fundamentals — The Universal Shield

The vocabulary of cybersecurity based on industry best practices. What is risk, what are threats, vulnerabilities, controls. Everything we need for the rest of the book.

Chapter 4. Industrial Control Systems and Securing Critical Infrastructure

How critical infrastructure is defended differently from traditional cybersecurity. Includes a primer on industrial control systems and critical infrastructure so my the comparison to Bitcoin makes sense.

Chapter 5. Bitcoin as Critical Infrastructure — The Monetary Grid

The core thesis, that Bitcoin is the first decentralized critical infrastructure for money and should be defended the same way we protect power grids, pipelines, and factories.

Part II is the Bitcoin Threat Landscape. 10 chapters of threats on an individual and network level, and what we can do about them.

Chapter 6. Exchange and Custodial Failures

From Mt. Gox to FTX, why custodial Bitcoin keeps blowing up, and what that means for your stack.

Hint: the answer is to get your Bitcoin off the exchanges and into self-custody.

Chapter 7. Securing Your Bitcoin: Personal Defense of the Private Key

The full personal custody chapter, covering hardware wallets, multisig, seed phrase handling, and inheritance. You have the responsibility to secure your Bitcoin. Learn how here.

Chapter 8. Privacy, Physical Security, and Staying Safe

Privacy on-chain, OPSEC off-chain, and maintaining your physical security when people know you own Bitcoin.

Huge shoutout to the excellent Praxeology of Privacy by

, read that after this chapter.

Chapter 9. 51% Attacks and the Decentralization of Mining

What a 51% attack would actually look like, why mining concentration is important, and how decentralized the hashrate really is. Includes practical steps to do something about it, as always.

Chapter 10. Node-Level Threats and Client-Side Defenses

Everything to do with the security of your node, including all the work being done to secure Bitcoin node software, and what they defend against.

Run a node, stay secure while you do.

Chapter 11. Arbitrary Data and Witness Abuse

An overview of ordinals, inscriptions, and arbitrary data. You may not think these are a problem. I lay out why it's a cybersecurity issue and makes Bitcoin worse as money.

Chapter 12. Governance Risks.

An honest examination of the risks Bitcoin faces from development centralization, and what can be done about it. It's not one-sided, though. I also cover the risk of changing Bitcoin, especially without wide consensus.

Chapter 13. Political and Regulatory Threats

Bans, surveillance, KYC, and mining restrictions, plus the realistic ways Bitcoin survives state-level pressure.

Chapter 14. Grid and Network Failures: Keeping Bitcoin Alive Offline

What happens when the grid goes down or the internet gets cut, and how Bitcoin stays alive offline through mesh networks, radio, and satellite.

Chapter 15. Emerging Threats: Quantum and AI

Full coverage of the latest developments of Bitcoin and Quantum. No FUD, but it's not something we should ignore.

Also includes coverage of AI as it affects everyone more and more these days.

Conclusion

We end summarizing everything together, and it's optimistic! Defending Bitcoin isn't about doom and gloom. It's about knowing what's out there, and finding out what you can do about it. There's always something you can do. Always.

Appendices

Included in the print book are glossaries of cybersecurity and Bitcoin terms, and a section of recommended reading across all topics.

Further resources are available on defendingbitcoin.com, including a threat model worksheet where you can find out how the threats in Defending Bitcoin apply to you. No data collection, I promise!

You can see more about the book at the Look Inside page, including the full foreword, introduction, and previews from two chapters.

https://defendingbitcoin.com/read

Reminder, Defending Bitcoin will be available on Amazon and bitcoininfinitystore.com from June 15th, and the first physical copies will be available at

- come see me there and get a signed copy!

The new edition of Max's book is really quite excellent, I highly encourage picking up a physical copy.

As he mentioned, Bitcoin payment option coming soon, but it's available on Amazon for now.

ddb27840508b49ff60e1d696d42263cc142b767d8fda133391cd2378fd7ad0ce

Max's excellent Praxeology of Privacy is out in physical form soon. Follow along here as he publishes a chapter per day!

GM Nostr!