Opening Up Consensus: Bitcoin Kernel | Bitcoin 2026

Hello, everyone. Does anyone have an idea what we're seeing on the chart over there? Just have a think. You don't have to answer. No towns, exactly. Um so, this is public data from Bitnodes going back to 2015. And the striking thing here is that since basically the beginning of the timeline, um all of the Bitcoin full node implementations that you see are Bitcoin Core or some very closely related variant of it. You know, during the block size wars, we had a bit of uh Unlimited and ABC and XT and a bunch more others. And obviously now uh in the last years, we have the the Knots faction um taking increasing market share as well. But really under the hood, all of this is Bitcoin Core. Um and in this talk, I want to talk about one approach that might help improve the situation a bit. Um I'm Stephen "Sticky" Fe. Um I'm funded by Brink to work on Bitcoin Core and specifically, I've been focusing on the Bitcoin Kernel project. Besides my developer work, I also um host the London BitDevs Socratic and I host the Bitcoin Core Review Club. Early bird gets the worm. So, Bitcoin is an emergent network and that means um it exists if >> [snorts] >> and when people agree on the exact set of consensus rules that defines whether or not a block is valid. Um there is no central authority that determines what those rules are. It's not Satoshi, it's not the white paper, it's not the Bitcoin Core developers, it's not the community, there is no voting. Consensus is whatever people actually end up running on their machine to validate um those blocks. And one of the most crucial properties um about consensus is you want to avoid consensus failure and consensus failure is essentially when unintentionally people that used to agree on consensus rules start disagree, which would typically lead to a chain split, which is extremely hard to recover from. Um and because chain splits are so catastrophic, we end up with this interesting first mover advantage. Uh essentially because Bitcoin Core has been around for so long and has gained massive market share um in the in the full node market. Running anything that is not Bitcoin Core puts you at quite a strong disadvantage, because in case of consensus failure, in case of a chain split, it really does not matter who is right in the academic sense. It doesn't matter like who better followed Satoshi's vision or who didn't have the bug. The only thing that matters, especially for you as a person running the node, is, you know, am I going to be on the the chain that survives? Am I going to be on the chain that is the most economically valuable? Because essentially Bitcoin is money, so that's what you want to maximize for. And so, unless you have really significant reasons to run something that is not the majority node implementation, for example, because it needs certain features um for your business or for your operations, or because you don't think that the majority implementation is good software, you're probably just going to stick with whatever is majority if it works uh well enough for you. Uh and so, yeah, I think the main reason that or the two main reasons that Bitcoin Core has been such a predominant implementation is one, it has a very good track record of um being a high-quality software project. It is very well tested. It is very well reviewed. It's got a very solid track record, and I think all of that speaks to its strengths, but also it does have the first mover advantage. It's been around for the longest. It has the majority, and so deviating from that is incredibly difficult. Um and I think that status quo makes sense. I think that's reasonable given where we are, given that Satoshi released or started Bitcoin without a formal specification, but I also think we should think about doing better. For two main reasons. Um, one is I mean, does anyone in this room think that free markets or competition are a bad idea? Not Oh, one hand. Okay, I can't see who that is, but I think I have an idea. I thought it was Shinobi. Um, so I guess everyone else agrees. You know, we want to have competition. It's better for end users if you can have different full node implementations that uh cater to different audiences, different use cases, different priorities, different philosophies. Ultimately, if we can do that in a safe way, that is going to benefit end users. Uh, and the second reason why I think this is important to think about is it takes the pressure off of Bitcoin Core. The more that we can decouple Bitcoin protocol and consensus rules from Bitcoin Core, the more that the Bitcoin Core project has the freedom to make decisions uh and changes that it thinks are best for its users without causing, you know, some of the controversies and uh the pushback that we have seen uh in recent times. Um, and so the project I'm working on uh with another group of people within the Bitcoin Core project is Bitcoin Kernel. What is Bitcoin Kernel? It is a stateful library that wraps all of the consensus logic within Bitcoin Core. And I will just walk you through that a bit a bit more detail. So, before Bitcoin Kernel, >> [snorts] >> you can see on this chart, imagine this box is the Bitcoin Core code base. We have some consensus logic indicated with a gear icon because I'll be talking about this um I'll be calling this the consensus engine. And we also have a non-consensus code, which is the other icon. So, before Kernel, it was kind of all tangled up a bit. There was no clear separation between which logic is consensus and which logic is not consensus. So, the first thing we did in stage one is we're going to separate that. So, on the right you have the gear icon for consensus logic and on the left you have everything that's not consensus code. This is purely internal. So, everything is still within core. Um And that stage is mostly finished. So, now we've entered stage two where same diagram but now on the right we have one consensus engine which is um the kernel. And because we're adding a public interface on top of this uh library, we can start to see competition amongst full node implementations that all use the same consensus engine. So, one of them could be core but the other one could be any full node in any language, any tech stack, any priorities that you want to that you want to see. Now, ideally we would go even further and we would move towards something for example that's based on a formal specification so that multiple consensus engines can be built and formally verified against uh that specification but it's out of scope for this talk and it's also much um less clear how feasible that is whereas kernel is actually um is is actually here. Right. Um so, kernel the the purpose is we want to have this library that is usable, useful, and the best choice for anyone that wants to use or build on Bitcoin consensus. And so, that imposes quite a few requirements or design goals for the library. The first one is it should be usable in any tech stack. Uh so, whether you're developing in Rust or in C or in JavaScript, uh if you want to use consensus, you should be able to use it. And that's also why we chose uh to publish a C interface for uh the kernel library. C because it's uh obviously a long-standing the language exists for a long time. It is architecturally um it it it works well to be used in multiple languages um through its FFI interface Uh uh pretty much any language supports uh using a C library. And uh as a matter of fact, we currently have language bindings for the kernel in Rust, in C++, in Python, in Go, in C#, in Java, and I'm probably forgetting a bunch more. Um so it that is actually working. Um A second requirement to make this usable for everyone is it must be performant. Um Bitcoin Core has already optimized performance quite a bit, and we want to make sure that we keep that property because things get bad whenever people have to reimplement consensus logic for their own application because the kernel is too slow. So, whatever we do, we cannot sacrifice on performance too much, and we try and squeeze as much as we can out of that little juice box. Um A third property is it absolutely needs to be secure and robust. Um to come back to the previous slides, like the whole point of kernel is to try and prevent consensus failures when people reimplement their own full node or any other consensus use case. So, in building this interface, we do everything that we can to remove footguns from the interface. We try and make it as hard as we can to accidentally mess up and accidentally cause um consensus failures. So, that's kind of the high-level theoretical overview of um what Bitcoin kernel is. So, is it ready yet? Um It is usable, but it's not finished. It is currently in an experimental phase. Um so, that means that the interface is not versioned. Uh we can and will introduce backwards incompatible changes at any time while we're like trying to make as much pace or progress as we can uh without being held back by versioning. But, the underlying logic, the actual consensus logic, is the exact same code that is used within Bitcoin Core. And that's of course it has a long track record. It is well tested. It is it is usable. Welcome to Predict. The world is a market. Everything is a market. Every [music] headline moves the line. Every moment is your market. Call the moves. Bet on your instinct. Your prediction, your edge. Dual bets. Predict, where everything is a market. So, it is usable, but it is not finished and it is not stable yet. And I just want to quickly walk you through an example here. This is a Python code snippets that you see on the screen using the Python language bindings and I want to highlight some of the the ways that that kernel works. So, in this snippet here, I want to show you how you can build a very simple full node and imagine you're on an island with a couple of hundred other citizens. You have no internet, but you have access to a satellite that can stream you blocks. So, you just get bytes from the satellite. And you also have a mesh network on the island. It's pretty low bandwidth. So, you can't like stream all the blocks. You can't run a full node on it, but you have enough bandwidth to for example stream transactions to your fellow citizens. And yeah, you're the Python guy, you're the Bitcoin guy, so you're building this node so that the whole island can live in in a Bitcoin economy. So, the first thing we're going to do is we're going to instantiate a chain statement manager, which is the entry point into the kernel. It holds the UTXO set, the chain state, the chains, all the blocks. It does disk operations and database operations. It really is the engine and the starting point for using kernel. So, in this case, we're going to initiate this on mainnet. And we're also attaching some callbacks. In this case, we add this one callback that fires whenever a block is disconnected from the tip, which usually represents a reorg, granted one block from the tip. And so in this case I just implemented a very simple function on reorg that just shoots an alert to our fellow citizens to inform them we've had a reorg, be careful because you know there might be double spends happening so double check what's happening. And then once we have the chain state manager, we can start to actually do something with this. So for example, in this case we start by getting blocks from our satellites. This is just a byte stream. We use the kernel to deserialize those bytes into a block object. Um and then we're going to use again the exact same consensus logic that we use within core to make sure the satellite is not cheating us, that the data we're getting is actually a valid block and adheres to all of the consensus rules that we want to stick to. Uh so we do that. We we kind of trust the satellite so we expect them not to send us bogus data, but just in case something is wrong, if it actually ends up being a valid block, again we can shoot an alert message to our fellow citizens that something seems to be wrong so make sure you inspect that data. Um after we've processed the block, we've now updated the chain state so our UTXO set is updated, the chain tip is updated, all the kind of magic stuff that is necessary for when you're doing validation. And now we can implement some other logic specific to our use case and this to highlight that you can also use kernel for example to inspect the blockchain. You can iterate over blocks, over transactions, over outputs. And you can use that for data analysis or build any kind of data engineering pipelines that you want to. It's much faster than using the RPC interface that previously you probably would have used. So in this case we're just going to iterate over the transactions in the block and then over all the outputs. We're going to compare the outputs to a list of scripts that we've saved because we don't care about privacy. We're just reusing scripts. We're a remote island. We have to make some concessions. And as soon as we see that there's a match between output scripts that our citizens have and ones that we find in the block, then we know, "Ah, these blocks might be sending transactions to our citizens." So, you use the mesh network to um forward all of these to rest of the island. And that's it. That's a full node. You just used uh the kernel to build your own node that does something that you want to do, and you can reuse all of the consensus logic that Bitcoin Core has. So, yeah, to recap, kernel is a stateful library. It wraps the Bitcoin Core consensus engine. Um you can use it to build anything in consensus. I think it's a cool first step to um help uh increase competition on full nodes um across the ecosystem. And we would love for anyone in this room to uh use it to give us feedback on how it works for you or if you want to change anything. Um and then on that note, I am hosting a workshop right around the corner, right after this talk. So, if you want to actually build something, bring your laptop. We're using Python, and it'll be interactive. We're going to scan some blocks, there's some prizes, and you'll walk away having built your own full node in less than 45 minutes. So, yeah, thank you for um showing up and your interested you're interested in kernel, and hope to see you there. >> [music] >> Every year this community comes together to celebrate, to debate, >> [music] >> to build what comes next. And every year the stage [music] gets bigger. Sound money >> [music] >> center stage. So, where do you go to celebrate the next chapter in Bitcoin history? You come home. >> [music] >> Nashville, July 2027.