lukedewolf
Luke de Wolf

Author of Defending Bitcoin: Industrial Cybersecurity for the Monetary Grid.

Co-founder of BTC HEL
Co-author of Bitcoin: The Inverse of Clown World
Producer of the Bitcoin Infinity Show

Public Key

npub1fk8h6g8zhftw8c7pga2zjd84p2z949up5lc3qdchm9v4m0q7mwws7jcwld

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsymrmayr3t54hru0q5w4pfxn6s4pz6j7q60ugsxutajk2ahs0dh8gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsqvvh09

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1fk8h6g8zhftw8c7pga2zjd84p2z949up5lc3qdchm9v4m0q7mwws7jcwld

Show more details

Last Notes

2026-08-07 14:21:32 CEST

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.

2026-08-06 08:51:48 CEST

- reply

It's not quite at that level of detail. It's recommendations of what to do, not how to do it at low level. I'll probably add more guides to the website, but there are plenty of resources for "how to" do everything in the book.

2026-08-05 14:23:43 CEST

- reply

I said "neglected" ;)

2026-08-05 14:01:45 CEST

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.

2026-07-24 21:04:59 CEST

- reply

Legit, credit to Nifty for letting him speak on the topic.

2026-07-23 08:57:22 CEST

- reply

Yes... Because it's our podcast. Not his.

2026-07-23 08:43:42 CEST

- reply

I don't work for Knut.

2026-07-23 08:07:28 CEST

- reply

I draw the line at personal insults. You do that, you're just a troll. GTFO.

2026-07-23 07:47:56 CEST

- reply

Fuck off, troll.

2026-07-23 05:24:42 CEST

- reply

I see zero actual harms from 110. A couple of niche use cases will need redeveloping. No risk to being able to self custody or send Bitcoin for normal users.

2026-07-22 20:48:03 CEST

- reply

It was more inertia than anything. I had my node running the 110 client, and I knew I could always change versions later. To a certain extent, I was just waiting and watching.
Then my node actually stopped responding, and I needed to wipe and reinstall to get it back up. That took longer than I expected, and by the end of it I had reasoned my way back to 110 support.
Sorry for any offense, it wasn't intentional. It was more of an anecdote that I had never turned the signal button off.

2026-07-22 14:49:36 CEST

- reply

This is taking "value is subjective" to an absurd place. Bitcoin isn't for everyone's meaning. It's for money. The protocol already has rules. More rules is fine.

2026-07-22 14:43:34 CEST

- reply

Yes :)

2026-07-13 19:05:49 CEST

I'm live on Stacker News right now!
https://stacker.news/items/1524157
Ask me about Bitcoin cybersecurity, BTCHEL, BIP-110, or anything else!

2026-07-13 16:26:29 CEST

- reply

Join me in a few hours and AMA!
#nevent1q…ruw0

2026-07-08 05:43:52 CEST

- reply

Tldr since the Guy interview: I find 110 activating smoothly to be the least risky and least chaotic scenario. I was getting the game theory steps a bit wrong. Something longer coming when I have time to write everything down. Also a few more pods.

2026-07-07 16:32:47 CEST

- reply

Apparently you haven't kept up with my X. I should really make an update on both platforms.

2026-06-21 19:53:56 CEST

- reply

There is no reason for this.

2026-06-21 18:46:54 CEST

- reply

I mostly see Luke as committing to forking off to an altcoin if 110 doesn't work. That profoundly saddens me. This all-or-nothing talk is part of the problem.
I will be happy if 110 succeeds but I just don't see it happening. I believe now that the incentives are the inverse of what they should be. And the result will be that a large portion of the monetary maximalists leave Bitcoin. And maybe there's even a protracted chain split and a competing coin.
I can't support that outcome. Maybe I'm overvaluing the tail risk, but that's sort of my job. If I'm wrong, I'm wrong.

2026-06-21 12:49:24 CEST

- reply

Knots on StartOS, mining with OCEAN using DATUM.

2026-06-21 08:22:00 CEST

- reply

Apparently the IBD has been improved significantly in recent Core releases. Not just assumevalid.

2026-06-20 16:15:00 CEST

- reply

This bot account is a deranged moron who apparently thinks I'm pro spam. GTFO.

2026-06-20 15:36:44 CEST

- reply

You've given me lots of food for thought. I'm not saying I'll change my position. But if I do, it will be final. Still a little ways to go yet.

2026-06-20 08:48:50 CEST

- reply

The vast majority of Bitcoin users have no idea BIP110 is even happening. Disruptions to the ability to use Bitcoin as money should be avoided.

2026-06-20 05:11:04 CEST

- reply

This fellow is reply-guying me elsewhere too. Seems to have a specific issue with me. Oh well!

2026-06-20 05:02:50 CEST

- reply

No, idiot. A perfectly valid transaction could be mined by a non-110-signalling block and then it's in limbo. If it gets mined by the BIP-110 chain, it will be in a totally separate block with separate history, which may have downstream effects. But the BIP-110 side could also get RBF'd, permitting a double-spend.
Think things through before posting.

2026-06-20 04:59:58 CEST

- reply

I content myself knowing that you're completely wrong. Feel free to point out why you think my book is "AI slop". If you don't want to do that, kindly fuck off.

2026-06-20 04:57:52 CEST

- reply

Thanks for the feedback! I'm actively considering my position on BIP-110. If forced to pick between "pro" and "anti", I'm currently "anti", but there's a lot more nuance. I'm mostly focusing on the downside tail risks. Maybe I'm overweighting that scenario.

2026-06-20 03:38:50 CEST

- reply

Disagree. If a user's transaction gets mined in a non-compliant block, that transaction will be in conflict. Double spending will be possible on the margins.

2026-06-20 03:36:35 CEST

- reply

Thanks, I appreciate that!
I came to my position through writing Defending Bitcoin. I wrote a risk management book. I evaluate the risk of profoundly negative outcomes if BIP-110 causes a chain split to be too high.
Frankly, my real position might be that I support it after all (because I still mostly support the changes, I have specific technical objections that aren't direction ally important), but only if those signaling/enforcing drop it immediately if it looks like it's going to end up with a tiny minority of hash rate and just fork off.
In other words, try it, see what the outcome is, but don't cling to a dead-on-arrival fork if that's the result.
I believe Bitcoin will survive with or without BIP-110. The "with" scenario would be truly positive in my view. A user-activated rebuke of both arbitrary data and the prevailing governance structure. I'm all for that.
The "without" scenario is what I'm worried about. I don't want all the monetary maximalists to leave if this soft fork fails to activate and become the longest chain. I don't think making this an all-or-nothing effort is right. And, in the case of failure, there will be much gloating from on high and ridiculing of those who prefer less arbitrary data on Bitcoin and are uncomfortable with Core's governance.
In Defending Bitcoin itself, I don't even say "don't support BIP-110." I highlight the potential risks of a chain split, and say DYOR. Know what you're getting into.
At this point, I see that the momentum for BIP-110 is absolutely there. Almost half the plebs I met at BTC Prague said they were pro-110 or considering supporting it. The only opposition I heard was from devs. But there are also smart people in the space who support its goals but don't think it will activate. I'm in that camp too.
I don't know how to square these positions. My internal schelling point landed on not supporting BIP-110, but I'm not sure that's totally accurate anymore.
Perhaps more accurate would be that I support trying, but giving up quickly if it fails. The problem is that we're dealing with individuals. I have a feeling or even know that many people will either continue to support the minority chain or just give up on Bitcoin entirely.
This is kind of a chicken and egg problem now. If it's going to happen anyway, does my support or non-support make any real difference?
Either way, come August 7th, I'm still going to be here. And dealing with the fallout of BIP-110 being unsuccessful, if that's the case.
I don't know if that clarified anything for either of us. But those are my thoughts. Take them as you like.

2026-06-20 03:21:09 CEST

- reply

See here.
#nevent1q…mjyj

2026-06-20 03:20:39 CEST

- reply

Look at any of my highlighted X posts, listen to any of my recent podcast appearances, or any Bitcoin Infinity Show / Feeedom Footprint Show from about the middle of 2023.
But this is good enough to show I've been anti-spam since the beginning: https://x.com/i/status/1766696720572830088

2026-06-18 17:01:56 CEST

- reply

I don't believe the "good" outcome is likely. That's why I'm not supporting at this point.

2026-06-18 14:11:06 CEST

- reply

Care to tell me why you think that? Did you read it?

2026-06-18 14:10:51 CEST

- reply

Care to tell me why you think that? Did you read it?

2026-06-18 12:56:28 CEST

- reply

Thanks so much for your support, Jeff!

2026-06-16 22:03:13 CEST

- reply

I'm extremely anti-spam. I don't believe a soft fork that has consensus is the solution. I believe it will do more harm than good. I have receipts.

2026-06-15 16:50:53 CEST

- reply

See my recent pod with Guy Swann for the best explanation. Or any of my other pod appearances.

2026-06-15 13:14:53 CEST

- reply

Soon! We've actually never done ebook on our website but we can figure that out.

2026-06-15 13:14:25 CEST

- reply

Coming soon!

2026-06-15 11:40:58 CEST

- reply

Haven't been for a while.

2026-06-15 10:32:35 CEST

- reply

🧡

2026-06-15 08:32:25 CEST

- reply

Thanks for the support! I hope you enjoy and that it's useful to you!

2026-06-15 08:21:14 CEST

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!
https://blossom.primal.net/678ab8b5ca6800770239bcce042d3fcbcd19e431cc144c599f5d379c2c149e4f.png

2026-06-05 15:30:19 CEST

- reply

Not yet ;)

2026-06-04 10:48:15 CEST

- reply

Interesting dashboard about the impact of Bitcoin on my long-time home province.
#nevent1q…qm05

2026-06-03 21:00:53 CEST

- reply

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!
#nevent1q…nyc6

2026-06-01 20:12:53 CEST

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.
https://blossom.primal.net/4a793f17c29fa6f73116f2e9d264f950739c4f227c80746716dd0e1d3530e393.jpg

2026-06-01 20:09:46 CEST

2026-05-29 18:28:42 CEST

- reply

It's most of the middle third.

2026-05-29 14:44:48 CEST

- reply

I appreciate you Michael!

2026-05-29 14:44:37 CEST

- reply

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.
#nevent1q…3hac

2026-05-29 06:11:25 CEST

- reply

You can download it again yourself.

2026-05-28 19:16:48 CEST

https://blossom.primal.net/37d93128dfe4bcc0694e0ea9beb8dfb2d88970e72c307ba61a96955237466d77.jpg
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."

2026-05-28 19:04:53 CEST

- reply

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.
#nevent1q…zj4g

2026-05-28 19:01:54 CEST

- reply

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

2026-05-26 12:32:35 CEST

- reply

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.
https://blossom.primal.net/9d796eb8a9330f4516132074f35b75038908eb4b192cd863b861684dfa85039a.jpg
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
#nevent1q…g3uh

2026-05-21 23:38:07 CEST

- reply

Sounds excellent!

2026-05-21 19:55:22 CEST

- reply

Cheers Roger, it looks great!

2026-05-21 11:34:52 CEST

- reply

The BTCHEL train keeps on rolling! Hopefully see you there this September.
#nevent1q…kmrg

2026-05-21 07:50:38 CEST

- reply

Happy to do it, let's talk!

2026-05-21 04:58:49 CEST

- reply

At least I hope it's interesting!

2026-05-21 04:58:05 CEST

- reply

Please do purchase a physical copy if you like the book in your advance read! And you can buy as many as you want, if you find it tasty :)

2026-05-20 21:51:42 CEST

- reply

Looks great!

2026-05-20 21:42:27 CEST

- reply

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?
#nevent1q…435q

2026-05-20 12:48:18 CEST

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
https://blossom.primal.net/397896c98ddd403b77967c1034c08dd237665e0734bb379fa0439f1b1b5690e2.jpg

2026-05-18 18:43:02 CEST

- reply

🧡

2026-05-18 12:45:00 CEST

- reply

The effect is even worse in a permissionless system. Can't stop the things from getting out into the wild. Warning against doing stupid things is one of the only forms of recourse.

2026-05-18 10:15:23 CEST

- reply

Yes.

2026-05-18 09:54:50 CEST

- reply

I think this falls into the category of just because you CAN do something. doesn't mean you SHOULD.
Nobody should use this, IMO.
But, like many things, looks like it's getting built.

2026-05-18 09:33:40 CEST

Look inside my upcoming book, Defending Bitcoin: Industrial-Grade Cybersecurity for the Monetary Grid 👇
https://blossom.primal.net/678ab8b5ca6800770239bcce042d3fcbcd19e431cc144c599f5d379c2c149e4f.png
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 @nprofile…8p0e , 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 @nprofile…py4c - come see me there and get a signed copy!

2026-05-14 22:00:44 CEST

- reply

Worth exploring, Joe.

2026-05-14 13:03:05 CEST

- reply

What is the reason to do this? Why does it need to be on Bitcoin?

2026-05-13 09:10:08 CEST

- reply

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#nevent1q…w33w

2026-05-13 01:45:21 CEST

- reply

Very good development.

2026-05-12 18:23:02 CEST

- reply

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

2026-05-12 16:04:24 CEST

- reply

Cheers!

2026-05-12 15:41:56 CEST

- reply

Taking it to the next level!

2026-05-12 15:41:34 CEST

- reply

@nprofile…nq3e doesn't bite!
Finland’s Bitcoin community is amazing, I'm proud to be a part of it!

2026-05-12 15:02:07 CEST

- reply

It's not so much "over" as providing standard options. There is an argument that we could just direct all fiat payments to Amazon, though.
Anyway, we just use BTCPayServer. No intention of accepting any other cryptocurtencies.

2026-05-12 14:00:52 CEST

- reply

And glad you're liking the book!

2026-05-12 14:00:41 CEST

- reply

Cool, I'll check that out!

2026-05-12 11:34:12 CEST

- reply

Good luck to both of you moving forward!

2026-05-12 09:53:28 CEST

- reply

I haven't supported BIP-110 for some time now. Quite open about it. I expand on the topic in podcasts, mostly. I don't take a position in the book.

2026-05-12 09:52:39 CEST

- reply

I wish I could, but it's too tight for me to squeeze it in. I'll make it one of these days!

2026-05-12 05:32:59 CEST

- reply

Thanks, issue with the epub renderer, I'll fix it.

2026-05-12 05:07:30 CEST

GM Nostr!

2026-05-12 04:54:32 CEST

- reply

Thanks Paul!

2026-05-11 20:33:27 CEST

- reply

Max's book is fantastic. A much-needed contribution to the space!

2026-05-11 20:25:28 CEST

- reply

Great to hear! Let's talk.

2026-05-11 20:05:16 CEST

- reply

Very cool! I have my own webshop, bitcoininfinitystore.com, with @nprofile…ddf9, and we accept Bitcoin from there, but maybe we can discuss collaboration!

2026-05-11 19:40:46 CEST

- reply

Always.

2026-05-11 18:57:21 CEST

- reply

Congratulations!

2026-05-11 18:47:31 CEST

- reply

Both!

2026-05-11 17:50:02 CEST

- reply

Thanks! Looking forward to your thoughts.

2026-05-11 17:49:47 CEST

- reply

It is a Bitcoin maximalist perspective. Although it's really simply a Bitcoin perspective. Other cryptos are essentially not covered at all.
Some of the security practices will absolutely apply universally.
I appreciate your offer to buy with Monero, but I only accept Bitcoin (and dirty fiat).

2026-05-11 16:16:15 CEST

- reply

Thanks a lot for the support, Max! And I'm looking forward to your book launching also!

2026-05-11 14:56:42 CEST

- reply

Thank you!

2026-05-11 14:45:57 CEST

- reply

100%, it will be available on bitcoininfinitystore.com the same day as the Amazon launch.

2026-05-11 14:43:36 CEST

- reply

Thank you! Looking forward to hearing what you think!