Kernel Session (Bitcoin Core Dev Tech, May 2026)

An open discussion (no presentation) on the direction and scope of the kernel. The central architectural tension is between a kernel that uses no system resources and one with high-level functional entry points like ProcessBlock/ProcessTransaction. Participants favored moving toward pure, functional validation but judged it far off, largely because of the existing threading model — script-verification threads, UTXO-set mutation, and caches that are unique per transaction — plus years of accreted optimization debt.

Ideas raised included a "sans-IO" libvalidation that could validate a transaction or block from its inputs without owning I/O or threads, removing recursive mutexes in the block tree/manager as easy wins, and specifying what the implementation should do (rather than freezing today's implementation) to gain freedom to change internals without breaking clients. A libmempool was floated (with Braidpool cited as wanting to apply policy as consensus rules over its DAG). A repeated principle: if Core itself does not use the library, the library is doomed, so the library must be the one Core actually uses.