Subject: [bitcoindev] Feedbacks on libbitcoinkernel & bitcoin backbone

From: Antoine Riard <[email-masked]>
Date: Thu, 7 Aug 2025 01:36:30 -0700 (PDT)

Hi,

Sharing the code for a small side project of mine, bitcoin backbone
a natively multi process full node written in rust, wrapping the core's
libbitcoinkernel (v27.0 iirc). This is full demo code for now, though
it got to the point where blocks can be downloaded from a vanilla bitcoind
peer and the heap of C / Rust / CPP code built correctly on both ARM 
(Darwin) and x86_64 (Debian 12) platforms. The whole build system is
still a huge bunch of dirty hacks, but it's done without binding generator
or whatever. That's good to keep the build toolchain strictly minimal.

Architecture is for now one main process (`backbone`) running the
libbitcoinkernel and orchestrating connections with traffic network
dedicated process (`block-relay` and `addr-relay`). Configurations
is very basic and I've not tested on all networks so far (reg, main,
test, etc).

Code can be download here (head commit 689e9df60)

git clone git://bitcoinbackbone.org:/public-release.git

Few lines of feedbacks on the libbitcoinkernel. First and foremost,
a pure C API is very fruitful for crossing the boundaries between
the different langages memory model. While in theory, you can e.g
write your CPP code in Rust code, in practice a lot of CPP abstractions
doesn't map well equivalently in Rust (--or whatever other langs). For
now, hacked a custom C API on top of the libbitcoinkernel with basic
block processing and chainman init/shutdown, though the ideal one
would keep all the state on the CPP side. And allow multi-threaded
code access on top.

Second, while writing the block-relay process I figure out that
for some data structs one might be willing to check the syntax 
structure of the headers by calling the libbitcoinkernel methods
as pre-checks __before_ to pass full blocks to the main validation
one. So you could have multiple same-version shared libbitcoinkernel
code in you're different process, one with the chain state the other
"empty". That way you can verify a subset of the consensus rule, without
re-implementing the rules in your other lang, at the risk of f*kcing them
up or deviating.

Third, I've not starrted really to work on tx-relay, but there is the
question of validating at some moment the transactions you're receiving 
against the spent UTXO to verify the "spent" UTXOs are indeed part of
your latest validated UTXO sets. In a multi-process setup, this UTXO set
state might not be fully live in the same memory space and there are
indeed challenge to that correctly. There are few hacks I'm brooding on,
in the style of utreexo, though here you don't need proofs as it's in
the same "full node" boundary. It's an interesting question.

Keep building.

Cheers,
Antoine
OTS hash: 3c8c398a8730539303767a20b1408dd887cb955ae9d602590c57277dd52f645f

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/9812cde0-7bbb-41a6-8e3b-8a5d446c1b3cn%40googlegroups.com.