Full stack Bitcoin software
November 2026
Archive of the libbitcoin Slack #general channel.
Sunday, November 1, 2026
evoskuil00:33
This util (
selector.exe) builds as the system console app. It is trivial, just tries all of the hardware options (except cuda, which always compiles in). It will just spit out whatever ones satisfy our criteria. This will be used in packaging to identify the right binary, and can be used to manually pick one for download.evoskuil04:39
The
-n, --newstore command line option has been renamed to -m, --make and has no parameters. There is a new -n, --net option that requires a network token (mainnet, testnet3, testnet4, regtest, signet). The store directory default name is changed from bitcoin to the token, mainnet by default, and all relevant config settings are also adjusted to correspond to the selected network. A configured bitcoin.network=<token> is overridden by the --net=<token> value, but otherwise controls the network defaults. Overrides are logged, as they are with any restart where stored settings don't match configured settings.🎉 1
Tuesday, November 3, 2026
evoskuil00:31
The
no-boost implementation landed it's first validation at a record Shelly time of 61 mins (previous was 65 mins) and a typical pruned milestone pass of 25 mins.🔥 4🚀 1😮 1🙌 1
evoskuil01:38
There were some slightly faster times (
53 mins) before no-boost when I was working on the store compression, but it didn't hold up on the low end machines, so that's no longer in the code or in the record books.
evoskuil06:42
Lots of great updates on the site in the past couple days as I've been working through all of the gaps we've had over the years. Generally the big work has been done, but we just need to iron out the details (as with BE and DLL builds). Getting rid of Boost, and the other dependencies over time, made all of it a LOT easier.
(edited)Big Endian (s390x), Windows DLL builds, CMake for Windows (with presets), clang-cl (native VS/Windows open source compiler), MinGW-w64 GCC, MinGW-w64 Clang, arm32, clang-cl arm64... literally every combination of mac/win/linux on any hardware, any major compiler or build system, with nearly every hardware optimization, all verified in CI - using cross-compile and in a few cases emulators for test execution.
AND
deterministic builds, tested in pairs, executed in Guix (verifiable build chain) using all of the libbitcoin-build code generation machinery, running in GH actions in Phillip's new release flow.
AND
packaging for apt (deb) (Linux), Homebrew (macOS), winget (windows), Docker (github), Umbrel and StartOS (bitcoin), also running in GH actions, pulling signed binaries from the release outputs - and soon automated submission.
AND
bx not far behind for the full monte.
libbitcoin.info/building/platforms.html?skin=moonlibbitcoin
Building Bitcoin Server (bs) and Bitcoin Explorer (bx) on Linux, macOS and Windows: build options, toolchains, libbitcoin-build, platform coverage and build status.
🚀 2
evoskuil18:14
There's a material performance regression in the client/server interfaces (actually p2p as well, but it would go unnoticed even in a fast IBD run, because it's tiny at that scale) from the boost removal. Prob found, fix underway. Working through the full interface performance quite (the data that drives the website).
Wednesday, November 4, 2026
neillm02:45
Started a mainnet sync yesterday and just checked in on it and apparently it crashed:
/usr/include/c++/16/bits/stl_deque.h:1642: void std::deque<_Tp, _Alloc>::pop_front() [with _Tp = std::shared_ptr<libbitcoin::network::socket::ws_frame>; _Alloc = std::allocator<std::shared_ptr<libbitcoin::network::socket::ws_frame> >]: Assertion '!this->empty()' failed. Aborted master/install/bin/bs -c bs.cfg.v4
Related to the found regression?
evoskuil02:47
doubt it, that was just a perf issue, but the whole asio stack was rewritten, so there are likely some issues. that's a websocket thing and it's failing on a debug assertion. are you running a debug build??
(edited)did you have the admin console or block explorer up?
(edited)looks like a consequence of a lazy stop update I made to ws a few days ago.
1 reply · evoskuil · last Nov 04, 2026
evoskuil05:06
I've changed
(edited)bip90 to off by default. It's the only hard fork we've been carrying, and there's no reason for it. It costs 10-15 seconds on the header sync to disable it. It's a hard fork material query optimization for Core, but we don't need it.
I pointed out that it was a hard fork when they documented it, and they argued about it, called it a hard fork, and then reverted that status to unspecified. And after that they never documented another, but there have been seven others by my count (4 hard forks, 3 soft forks). The only difference with bip90 is that they posted it to a website after the fact.
That's not counting the LevelDB bug, stopgap, and removal, or the inflation bug and removal. That's 5 more forks (3 hard, 2 soft), but since those weren't intentional, I'm discounting them above.evoskuil05:19
I got on this tangent because I was finally implementing
bip9 (and the speedy trial variant), which is what gets us off of bip9, but also prepared for future activations, including bip54. All three are now implemented (bip54 is 5 simple forks, with independent ST activation). That's disabled by default presently, and has no activation parameters because they haven't been determined yet. So this also gives us some time with the bip9/ST code activating bip68/112/113/141/143/147/341/342 - so if there's an issue we'll find out sooner than later. But I've verified that all forks are transitioning on the same blocks as when checkpointed.
evoskuil13:26
The initial overall ASIO replacement performance review is in. There's still one area of regression (reddish here), patch done. Note that this is specific to Windows, other are pending.
The plots show the regression is in one place. Plain HTTP/WebSocket small requests run at 0.19–0.50 of published from 16 connections up. Blocks and every TLS row are at or above parity, and Electrum latency is 2–5× faster.
(edited)
evoskuil14:14
All master branches passing with
(edited)92-99% code coverage, including bx.
Release build made it all the way thought the double guix builds, and failed on build comparison of Windows and macOS debug symbols. The only ones that differed were built across runner architectures (Arm vs. Intel), but only for macOS and Windows. So gonna retry just three runs, with only x64 runners, to verify. We could also drop the debug symbols, but better to keep them if it's this easy.
Packaging is an additional workflow after release build signing, and it's got no status yet because we haven't completed the workflow on master. I'm running a test workflow in my repo now against last night's unsigned builds.
evoskuil14:19
Test packaging run completed, packages downloaded and verified. Test release run on the three platforms will take a while.
(edited)
evoskuil15:50
- The test
Double Buildpackaging run (the new part ofPackage Release) succeeded on all three platforms, after switching both win/mac runners to x64, so deterministic builds should be done. - The test
Packaging Releaseworkflow completed successfully, with packages verified locally. - A new test
Distribute Releaseworkflow completed and added packages to our new apt and homebrew-tap repositories, with apt/brew integration verified locally.
evoskuil15:59
- Docker packages are also pushed to our GitHub container repository (ghcr) by
Packaging Release.
docker pull ghcr.io/libbitcoin/libbitcoin-server:<version>
...and
:latest once Distribute has run.
The others...
microsoft/winget-pkgsby PR; the manifests point at the installers on the release- Umbrel app tarball submitted by hand to
getumbrel/umbrel-apps - StartOS
.s9pksubmitted by hand to Start9 packages-sha256.txt(stays with the release)
Huddle with pmienk, neillm, evoskuil, Marnix, Eric Chennells, eynhaender, Rowan Voskuil · 199 min16:51
3 replies · neillm, Eric Chennells, pmienk · last Nov 04, 2026
Eric Chennells19:26
It’s in two places in the libbitcoin/libbitcoin.github.io repo, both still there on master just now:
- packages/md/index.md:18: the docker run line has no stop timeout, so Docker’s 10-second default applies:docker run -v <data directory>:/data -p 8333:8333 -p 8080:8080 -p 8180:8180 ghcr.io/libbitcoin/libbitcoin-server:<version>The fix is to add --stop-timeout 600.
- architecture/build/md/packaging.md:133:
docker stopsends SIGTERM, which closes the store.SIGTERM does start the close, but a syncing node needs longer than 10 seconds, so Docker kills it first. In my tests a clean close took 33 to 41 seconds.
Thursday, November 5, 2026
evoskuil01:34
Turns out there was an integer version of the std::stream-based number parser in use in several places in the client-server interfaces, and it has the same flaw. every thread passed thru a critical section. Also the json parser had a dumb perf flaw. And the http serializer was sending header and body independently. With that and one io scheduler optimization, the perf is back to pre-boost-removal baseline, with significant improvement in many regions (almost 2x in some case). Also building with the verbose logging level disabled increase http server performance at every level by about 10%.
eynhaender12:00
The first libbitcoin sync on a Raspberry Pi 4 (8GB) with a 1TB USB SSD. I run it on some old “RaspiBlitz” hardware, though I had to build a custom kernel because the address space of the standard kernel wasn’t sufficient.
950k milestone reached in under 7 hrs
block_organized..... 950000 24480. Not bad for this aging system I guess.
🎉 1