Kernel (libbitcoinkernel)

PRPriorityReviewabilityReviewsAgreementSize
(+)#32427 sedited kernel: Replace leveldb-based BlockTreeDB with WAL and .dat file based store
  • Allow external tools and indexers to read block data concurrently without stopping bitcoind
  • Remove single-process locking constraints on block tree storage
P2 · new feature
  • P2 because it unlocks concurrent read access for external tools using libbitcoinkernel
  • Resolves a long-standing architectural obstacle preventing external tools from inspecting running nodes
Author reworking
  • Hold off review because the author converted to draft to rework concurrent reading and WAL threading
  • Branch also needs a rebase
0 (+6)Mild
  • Strong concept support for removing LevelDB locking constraints (theuni, josibake, stickies-v, marcofleon)
  • Concerns about read-mode interactions with unapplied WAL files and lock ownership (willcl-ark)
  • Technical feedback on WAL atomicity and platform-specific flush edge cases (stickies-v)
  • Author converted to draft to redesign parallel readers and threaded WAL processing (sedited)
988 + 769 tests
  • 988 lines added or modified outside tests
  • 769 lines added or modified in tests
  • 201 lines removed in total
  • 31 files, 10 commits
(+)#35187 sedited kernel: Block validation without a complete UTXO set
  • Allow external library consumers to validate blocks without maintaining a full local UTXO database
  • Enables stateless verification for downstream projects like rust-bitcoinkernel
P2 · new feature
  • P2 because it expands kernel API completeness for external consumers wanting stateless validation
  • Unblocks downstream tools like rust-bitcoinkernel that need to validate blocks on demand
Needs rebase
  • Needs rebase against master due to merge conflicts
0 (+2)
Blocked
  • Concept approval for stateless block validation (yuvicc, nervana21)
  • Verified by implementing a prototype test suite in rust-bitcoinkernel (alexanderwiederin)
  • Prefers an in-memory coin container over dynamic callbacks to prevent inconsistent lookups (ajtowns)
  • Questioned whether assumevalid logic should bypass script checks during standalone validation (nervana21)
242 + 119 tests
  • 242 lines added or modified outside tests
  • 119 lines added or modified in tests
  • 0 lines removed in total
  • 6 files, 5 commits
(+)#29700 ryanofsky kernel, refactor: return error status on all fatal errors
  • Return fatal error details programmatically instead of aborting the node process during validation
  • Let libbitcoinkernel users handle critical failures directly without relying on notification callbacks
P2 · new feature
  • P2 because external applications embedding the kernel need structured errors instead of process shutdowns
  • Avoids requiring consumers to register asynchronous notification callbacks to detect fatal failures
Review #25665 first
0
  • No review verdicts recorded
Blocked
  • Blocked by an unaddressed approach objection
  • Unaddressed objection: Result-style error handling is unidiomatic and harms performance (purpleKarrot)
  • Nonblocking objection: nesting interrupt results inside error results invites unhandled stops (maflcko)
  • Approval without detailed technical analysis (Graysonbarton)
1,314 + 440 tests
  • 1,314 lines added or modified outside tests
  • 440 lines added or modified in tests
  • 675 lines removed in total
  • 55 files, 22 commits
(+)#34374 stickies-v kernel: use struct-based logging and simplify logging interface
  • Let kernel library consumers receive structured log data instead of parsing formatted text strings
  • Decouple the kernel library from internal node logging machinery
P2 · new feature
  • P2 because downstream kernel consumers get structured metadata without parsing formatted log strings
  • Removes node-internal logging dependencies to advance clean process separation
Ready
  • Ready for review, rebased on master with passing CI and addressed feedback
0
Mild
  • Strong concept and approach support for rationalizing the kernel logging API (ryanofsky)
  • Identified indirection overhead and argument evaluation regressions that were addressed (ajtowns)
  • Flagged callback registration deadlock and leak hazards which the author fixed (w0xlt)
+464/-269
  • 8 files
  • 6 commits
(+)#35557 ryanofsky kernel, validation: Add btck_chainstate_manager_set_clock_time
  • Allow kernel users and multi-instance tests to mock time per instance without relying on global state
  • Prevent kernel validation code from accidentally calling nondeterministic host system clocks
P2 · new feature
  • P3 because kernel consumers need deterministic validation without depending on process-global state
  • Instance-scoped time refines the kernel architecture beyond the existing global mock time
Ready
  • Ready to review: branch builds cleanly, passes CI, and is actively maintained across rebases
0
  • No review verdicts recorded
Strong
  • Positive sentiment with constructive review on typing, testing, and clock ergonomics
  • Supported keeping the changes unified and requested scoped clock tests (sedited)
  • Commended the test race fix and suggested using a fake clock (seduless)
  • Questioned whether this is still necessary after global mock time merged (maflcko)
172 + 86 tests
  • 172 lines added or modified outside tests
  • 86 lines added or modified in tests
  • 99 lines removed in total
  • 31 files, 6 commits
(+)#28690 sedited build: Introduce internal kernel library
  • Prevent the kernel library build definitions from diverging from core node builds
  • Stop the kernel from pulling in unwanted node utilities such as networking and process execution
P3 · decoupling
  • P2 because it enforces kernel isolation from unwanted node utilities at the build level
  • Helps safeguard library modularity and unblocks extracting the kernel into a standalone repo
Ready
  • Ready to review now
  • Branch is rebased with passing CI and incorporates the latest suggestions
2 (+2)Strong
  • Strong consensus on establishing explicit internal targets for the kernel
  • Verified on multiple platforms with Guix reproducible builds (janb84)
  • Verified compatibility with a downstream proof-of-concept iOS app (Sjors)
  • Debated library structure options and settled them without blocking objections (ryanofsky, ajtowns)
  • Re-approved after the latest push (yuvicc, w0xlt)
114 + 12 tests
  • 114 lines added or modified outside tests
  • 12 lines added or modified in tests
  • 122 lines removed in total
  • 6 files, 2 commits
(+)#30342 ryanofsky kernel, logging: Pass Logger instances to kernel objects
  • Allow kernel library consumers to route log output per instance rather than through a global logger
  • Help multi-instance applications segregate and control their own log streams
P3 · cleanup
  • P3 because eliminating global state aligns with library design goals without urgent user demand
  • Kernel working group inquiries showed minimal caller need for contextual logging
Needs rebase
  • Wait for rebase due to substantial merge conflicts across dozens of files
  • Review #34778 first
0 -1
Disputed
  • Disputed whether instanced logging justifies the interface verbosity and maintenance cost
  • Concept approval without stated reasons (sedited)
  • Approach objection: review cost and verbosity outweigh benefits without consumer demand (stickies-v)
  • Prefers keeping logging callback explicitly global via alternative PR #34775 (stickies-v)
723 + 376 tests
  • 723 lines added or modified outside tests
  • 376 lines added or modified in tests
  • 591 lines removed in total
  • 69 files, 18 commits
(+)#33847 ryanofsky kernel: Improve logging API
  • Make libbitcoinkernel logging safer by configuring loggers directly through context options
  • Eliminate an unsafe global disable function and stop buffering logs in memory by default
P3 · cleanup
  • P3 because the public C API is experimental and underlying logging remains global until future work
  • Improves safety by removing an abort-prone disable call and drops unnecessary in-memory buffering
Needs rebase
  • Needs rebase due to merge conflicts against master
  • Author has been inactive for several months while PR remains in draft
0
Disputed
  • Concept approval for making the logging interface local instead of global
  • Concern that new handles mislead callers while logging remains global internally (sedited, stringintech)
  • Prefers keeping this as a draft design discussion until multi-logger support lands (stickies-v)
  • Converted to draft for conceptual discussion (ryanofsky)
109 + 9 tests
  • 109 lines added or modified outside tests
  • 9 lines added or modified in tests
  • 108 lines removed in total
  • 5 files, 1 commits
(+)#35646 yuvicc RFC: Separate out runtime errors from BlockValidationState using `util::Expected`
  • Stop conflating internal runtime failures like disk write errors with peer-penalizing block invalidity
  • Separate internal system faults from consensus rejection logic across block processing
P3 · cleanup
  • P3 because it clarifies the kernel interface boundary without fixing bugs or improving performance
  • Ensures validation callbacks strictly signal block validity rather than internal faults
CI failing
  • CI is failing and reviewers asked to split the large commit into smaller steps before detailed review
0
Positive
  • Broad concept support for separating runtime errors from block validation results
  • Concept approval citing enforced error handling and less risk of conflating errors (optout21)
  • Concept approval welcoming the direction but requesting piecemeal commits (hodlinator)
373 + 244 tests
  • 373 lines added or modified outside tests
  • 244 lines added or modified in tests
  • 384 lines removed in total
  • 41 files, 5 commits
(+)#35641 sedited kernel: Add script evaluation tracer
  • Allow external kernel consumers and debugger tools to observe intermediate script execution state
  • Avoids the need for custom Bitcoin Core forks or reimplementations when inspecting or debugging scripts
P3 · new feature
  • P3 because external tooling and debuggers gain visibility into script execution
  • It provides an optional compile-time utility rather than essential kernel validation infrastructure
Waiting on author
  • Author response is pending on a material assertion bug when serror is null
0 (+1)
Mild
  • Strong concept and approach support across multiple contributors
  • Concept approval noting it would benefit testing greatly (furszy, w0xlt)
  • Approach approval (haanhvu)
  • Verified by testing with Python bindings and a transaction visualizer (elmeriniemela)
  • Unaddressed bug: assertion failure when serror is null (w0xlt)
539 + 78 tests
  • 539 lines added or modified outside tests
  • 78 lines added or modified in tests
  • 2 lines removed in total
  • 9 files, 1 commits
(+)#34775 stickies-v kernel: make logging callback global
  • Simplify the kernel logging API by replacing per-connection handles with a global callback
  • Avoid confusion for downstream consumers by reflecting that logging is a global singleton
P3 · cleanup
  • P3 because this is an API cleanup aligning the kernel interface with its underlying global logger
  • Downstream consumers get a clearer API, though it adds no new validation capabilities
  • Unblocks follow-up kernel work in #34374
Ready
  • Ready to review: CI is passing and recent feedback is addressed
0
Strong
  • Support for simplifying the logging interface by removing connection handles (sedited, w0xlt)
  • Questioned whether limiting the API is premature compared to contextual logging (ryanofsky)
  • Author addressed test isolation concerns by preserving scoped cleanup (sedited, w0xlt)
86 + 19 tests
  • 86 lines added or modified outside tests
  • 19 lines added or modified in tests
  • 66 lines removed in total
  • 5 files, 1 commits
(+)#33117 D33r-Gee Interfaces: Expose UTXO Snapshot Loading and Add Progress Notifications
  • Allow GUI clients to trigger UTXO snapshot loading and display real-time progress feedback to users
P3 · new feature
  • P3 after comparing with the other PRs here (assessed alone as P4): Raised to P4->P3: it extends the kernel notification boundary with snapshot progress and unblocks downstream GUI work, which is more than the cosmetic/mechanical items left in P4.
  • P4 because it is only a minor pass-through callback addition to kernel notifications
  • Limited to forwarding snapshot progress updates out of validation
Needs rebase
  • Needs rebase due to merge conflicts with master
0 (+1)
Strong
  • Strong consensus on concept and approach with all architectural concerns resolved
  • Verified snapshot loading using downstream QML GUI (pinheadmz) and current GUI (Sjors)
  • Approach approval (sedited)
127 + 2 tests
  • 127 lines added or modified outside tests
  • 2 lines added or modified in tests
  • 21 lines removed in total
  • 10 files, 3 commits
(+)#36283 nervana21 kernel: expose transaction version
  • Lets libbitcoinkernel consumers inspect transaction versions directly
  • Removes the need for library callers to slice and parse serialized raw bytes
P3 · new feature
  • P3 because it rounds out the kernel transaction inspection API without changing core behavior
  • Benefit is modest convenience for external library users reading transaction data
Ready
  • Ready to review
  • Small and clean change with straightforward feedback on test helpers
0
Strong
  • Reviewers agree on exposing the transaction version to complete the API surface
  • Concept approval without stated reasons (yuvicc)
  • Code approval with a minor suggestion on test helper headers (stickies-v)
19 + 10 tests
  • 19 lines added or modified outside tests
  • 10 lines added or modified in tests
  • 0 lines removed in total
  • 4 files, 1 commits
(+)#35322 ryanofsky logging: streamline Logger state and drop redundant methods
  • Avoid mutex acquisition and overhead during routine logging checks across the node
  • Simplify internal logger state management and remove redundant category methods
P4 · cleanup
  • P4 because updates to the kernel C API and test exports are mechanical adaptations
  • These adjustments are minor and will be superseded by a larger kernel logging rework
Ready
  • Ready for review
  • Cleanly rebased on master with passing CI and previous review feedback addressed
0
  • No review verdicts recorded
Neutral
  • Requested splitting commits and preserving flag behavior when debug mode is off (l0rinc)
  • Requested explicit tests for category enablement through RPC and kernel interfaces (l0rinc)
  • Author addressed all review comments and added tests, but follow-up review is pending
105 + 100 tests
  • 105 lines added or modified outside tests
  • 100 lines added or modified in tests
  • 196 lines removed in total
  • 14 files, 14 commits
(+)#33820 stickies-v kernel: trim Chain interface
  • Trim redundant accessor functions from the public libbitcoinkernel C API
  • Reduces public API surface where height lookups already cover genesis and tip queries
P4 · cleanup
  • P4 because this is routine API surface trimming with no downstream blocker or safety improvement
  • The removed methods offer marginal utility and are trivially replaced by existing height lookups
Author silent
  • Author has been silent for over 300 days
1
Strong
  • Strong consensus to remove redundant accessors from the public kernel interface
  • Agrees the calls should be removed and synchronization belongs to external callers (TheCharlatan)
  • Approves removing redundant methods (yuvicc)
+2/-33
  • 3 files
  • 2 commits
(+)#24230 ryanofsky indexes: Stop using node internal types and locking cs_main, improve sync logic
  • Prevent lock contention by stopping indexes from holding the main lock during sync and startup
  • Decouple optional indexes from node internal types so they can eventually run in separate processes
P4 · cleanup
  • P4 because it only performs a minor boundary cleanup by moving non-kernel types out of the kernel
Needs rebase
  • Needs rebase due to merge conflicts with current master
0
Strong
  • Broad concept and approach support across multiple maintainers with all code concerns resolved
  • Approach support for separating internal types toward multiprocess architecture (sedited)
  • Concept support verified through detailed testing across commits (mzumsande, josibake)
  • Concept approval without stated reasons (fjahr, aureleoules)
  • Resolved race conditions and crash on block invalidation during sync (mzumsande, furszy)
937 + 201 tests
  • 937 lines added or modified outside tests
  • 201 lines added or modified in tests
  • 577 lines removed in total
  • 42 files, 18 commits
(+)#35948 l0rinc init: correct first-run disk space estimate
  • Warn users with accurate required disk space on first startup
  • Prevent misleading pruned node operators into thinking they need full chain storage
P4 · cleanup
  • P4 because it only corrects unit names in documentation comments
  • Leaves all kernel code logic, signatures, and boundaries untouched
Ready
  • Ready to review with a small diff, passing CI, and addressed feedback
3 (+1)Strong
  • Strong consensus across reviewers to fix the misleading startup warning text
  • Verified expected warning behavior on pruned setups (murchandamus, jeanpablojp)
  • Supported keeping internal units in GiB while fixing displayed strings (achow101, mercie-ux)
  • Agreed that remaining GUI unit inconsistencies can be handled in a follow-up (hebasto)
5
  • 5 lines added or modified outside tests
  • 0 lines added or modified in tests
  • 4 lines removed in total
  • 2 files, 1 commits
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.
Ranking pass (2026-09-17): all PRs here were compared with each other; 8 notes on review order, overlaps, and band changes.

Covers

The libbitcoinkernel project: the C and C++ kernel API, its headers and bindings, the boundary between the kernel and the rest of the node (notifications, logging callbacks, error reporting, context and options objects), the bitcoin-chainstate example, kernel tests, and refactors whose stated purpose is to make validation usable as a library. The Kernel label is a strong prior.

A kernel PR that also substantively changes validation logic is both kernel and validation, and probably needs splitting; say so.

Not kernel: changes inside validation that happen to compile into the kernel library but do not touch its API or its boundary.

What matters here

Whether external users can build on the library: API completeness for the stated use cases (validating blocks and transactions, reading chainstate, receiving notifications), API stability and versioning, correctness at the boundary (error propagation, thread safety, object lifetimes), and platform coverage. Then removing node dependencies from kernel code, which is the project's core work. Then documentation and examples that determine whether anyone outside the project can use it.

Renames and cosmetic API polish without a consumer asking for them are P3 or below.

generated 2026-09-17 21:55 UTC