From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: btc@ariard.me
Subject: [bitcoindev] New bitcoin backbone code release: BIP152, outbound tx support + libbitcoinkernel API feedbacks
Date: Fri, 6 Feb 2026 02:09:14 +0000 [thread overview]
Message-ID: <CALZpt+HDWZCiaZ210dyKyCRM6FoQ8644Owv-ZyaabKCTdwEUnw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]
Hello devs,
Shared new code for bitcoin backbone available on the website (
bitcoinbackbone.org). Biggest
changes from the latest release has been mostly working on compact-block
BIP152 support, of
which most of the groundwork is present, outbound tx synchronization and a
lot of internal
circuitry due to the native multi-process architecture (and some other
minors on addr mngt).
Currently, bitcoin backbone is leveraging a homemade C interface to deal
with the deeper
libbitcoinkernel encapsulated consensus code. Idea is of course to update
the consensus
code to the newer version, though for now in terms of flexibility using a
homemade interface
has a lot of advantages.
I had a look on the libbitcoinkernel as you're finding in v0.30. I have no
strong opinion
on yet on the level of granularity around the btck_ChainstateManager
abstraction. So far,
being able to access lower levels is very useful, most notably for
debugging and checking
the internal state of your chain state manager, and knowing on which branch
it is.
Yet, already coming to my mind, I'm thinking there are 2 interface
extensions that could
be useful, or at least worthy to consider. The first one is 1) being able
to verify header
consensus structure on their own. In bitcoin backbone, I have a
block-daemon managing block
relay and sanitizing the headers as they're coming it's useful (the
libbitcoinkernel would
be re-linked in the binary, but not stateful).
A second extension would be able to validate a transaction in its wholeness
for all consensus checks
during mempool processing. Same backbone has its own mempool process (i.e
mempool-daemon).
I'm leaving for design broodings if it's interesting to be able to confirm
atomically a chain of unconfirmed
txn back to their origin coinbase or deeply buried UTXO.
Still very much a toy, though at least it starts to have its own testing
framework.
Keep building.
Cheers,
Antoine
OTS hash: e2d9f01c29660767860789d3e134e8d7048a2e50b673bf6b453cd9786580083f
--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BHDWZCiaZ210dyKyCRM6FoQ8644Owv-ZyaabKCTdwEUnw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2852 bytes --]
reply other threads:[~2026-02-08 2:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALZpt+HDWZCiaZ210dyKyCRM6FoQ8644Owv-ZyaabKCTdwEUnw@mail.gmail.com \
--to=antoine.riard@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=btc@ariard.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox