Bitcoin full node and query server
September 2025
Archive of the libbitcoin Slack #general channel.
Tuesday, September 2, 2025
R
rose16:41
Hello, I'm running libbitcoin-explorer with a local libbitcoin-server. Both libbitcoin-explorer and libbitcoin-server are version 3.8.0. I'm able to fetch the block height 848141 (using bx fetch-height), so it seems the explorer and server are connected correctly and the server is reading from the blockchain datastore. However, when I run "bx fetch-history 134HfD2fdeBTohfx8YANxEpsYXsv5UoWyz" it returns: transfers "", and it should return more detailed info per https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-fetch-history. Do I need to re-index the blockchain datastore? Perhaps there is some indexing missing? The entire datastore directory is 918GB, so I suspect it is fully synced and indexed already... but I'm probably missing something. Any help is appreciated!
84 replies · neillm, rose, evoskuil · last Sep 11, 2025
neillm16:43
When I run that command against my own server (mainnet1.libbitcoin.net), I see this:
$ ./bx fetch-history 134HfD2fdeBTohfx8YANxEpsYXsv5UoWyz
transfers
{
transfer
{
received
{
hash 97e06e49dfdd26c5a904670971ccf4c7fe7d9da53cb379bf9b442fc9427080b3
height 247683
index 1
}
spent
{
hash b7354b8b9cc9a856aedaa349cffa289ae9917771f4e06b2386636b3c073df1b5
height 247742
index 0
}
value 100000
}
}✅ 1
neillm16:44
I think there's likely a configuration difference on your server -- what does your config look like?
R
rose16:47
I'm using the default bs.cfg generated on first run, I just modified "[database] directory" to my blockchain store and added a seed node.
neillm16:48
It's been a while, but in the [server] section, do you have this enabled?
# The lower limit of address and spend indexing, defaults to 0. index_start_height = 0
R
rose16:50
Ah yes there are several checkpoints enabled in the default config, I will try disabling them
neillm16:52
Yes, unfortunately that's an issue on v3. Sometimes it never shuts down cleanly, and if you manually/forcefully kill it at that point, the database will be corrupt 😞
R
rose16:56
It's possible i've already corrupted the db by force killing, as I force killed the last time I shutdown the node. After force kill it wouldn't start, but I mv'd 'flush_lock' and it started fine. Will note i'm not confident this is the rzn for the current issue (fetch_history returning a blank), since I was already encountering it before i forced killed the node.
evoskuil16:59
You might want to start working with v4, although the bx integration isn’t there for a while.
evoskuil17:02
Theres no zmq interface because server is a wip. It indexes addresses using the Electrum server method. Which is far more robust, this optional index adds about 30 mins to sync time.
evoskuil17:04
But you would have to write your own c++ interface. This is actually very easy, there’s an embedded sample.
neillm17:06
For sure, but I just mean like no server running, some tool to pull data right out of the on disk files
evoskuil17:09
It’s not great because it won’t stay synced. It’s trivial to add custom queries to bn though.
👍 1
R
rose19:38
Sorry to bother you guys, I've gotten setup with the latest libbitcoin-node but keep getting this error when running with a modified [database] path directory: "Database failed to start with error 'no such file or directory'". I'm trying to sync to an external HD that's mounted in /mnt/, so the config line looks like this: path = /mnt/hd/blockchain. It seems to be related to how paths are being resolved, since it works fine when I set a non-absolute path like "path = foo/blockchain". Any thoughts on how to resolve?
evoskuil19:42
An internal SSD is def recommended.
Look at the start of the console output for the indication of what config file is being used. Also, what are you using as your guide to config settings?
R
rose19:44
I copied the config from data/bn.cfg and commented out the fields since the defaults seemed reasonable. Just changed the 'path' variable. Can confirm it's running with the correct config
evoskuil19:54
The sample may not be current. You can dump the current options and hep from the console. You can get help on the console options using -h or —help
evoskuil19:55
The node also has a robust live console. You can dump those options while running by hitting
m <enter>.evoskuil19:57
If you look at bn build source you will see test_reader.cpp and test_writer.cpp. I use these for ad-hoc queries. There are quite a few disabled samples. These can be executed from the live console.
(edited)evoskuil19:59
You shouldn’t need many of the config options, the defaults are pretty good for most things.
👍 1
evoskuil20:00
The default starts full validating at block 900k. You can set that to genesis in config if you wanna full validation run. I recommend a default milestone run first to get a good benchmark.
evoskuil20:08
32GB with 8 dual cores and a fast 1TB SSD ($350) is our baseline for benchmarking. Below that level of RAM or without an internal SSD it may be significantly slower than advertised.
(edited)👍 1
R
rose14:51
Hello, you mentioned libbitcoin v4 is fault tolerant. Is there any way to recover from this?
R
rose14:51
====================== startup ======================= Using config file: "/home/user/.config/bn/bn.cfg" Database failed to start with error 'flush lock failure'. Please wait while restoring from most recent snapshot... restore::recover_snapshot(store) Database restore failed with error 'missing snapshot'. Node stopped successfully. ====================== shutdown ====================== Press <enter> to exit...
R
rose14:53
Painfully, 4 days into sync (had reached early 2024) my USB port glitched and my SSD disconnected mid-sync...
evoskuil14:55
No, the store is recoverable to the most recent snapshot. It’s not configured to take a snapshot until current. You can however take a snapshot while it’s running (or stopped) using
b <enter> but there is no recovery from where you are.evoskuil14:56
It takes less than a minute to snap on my machines, and only takes the amount of space required by the head subdirectory.
evoskuil14:59
This moves the /primary snap into /secondary and creates a new /primary, each time you snap. This ensures the new one is committed without losing the previous. The creation and recovery are atomic. Once you have a snap you can always recover to the most recent.
(edited)❤️ 1
R
rose15:04
I guess it's slower because I'm using an external SSD, also it took me a bit to figure out you can disable the logging which might have been slowing it down too.
evoskuil15:25
Logging doesn’t make a measurable difference. It can even be entirely compiled out and still no difference. Though you should make sure you are running a release build, as debugging is costly.
evoskuil15:26
It should generally be network limited, if not then something else is the bottleneck.
👍 1
R
rose16:51
It's going much faster now I plugged the ssd directly into the motherboard (you can do this on framework laptops). I think the shitty expansion dock was the bottle neck. Really appreciate your feedback
🔥 1
R
rose09:01
Hello again, I had another port failure and am now trying to restore from a snapshot (which I had been taking regularly). I'm getting this error:
====================== startup =======================
Using config file: "/home/user/.config/bn/bn.cfg"
Database failed to start with error 'flush lock failure'.
Please wait while restoring from most recent snapshot...
restore::recover_snapshot(store)
restore::open_file(header_head)
restore::open_file(header_body)
restore::open_file(input_head)
restore::open_file(input_body)
restore::open_file(output_head)
restore::open_file(output_body)
restore::open_file(point_head)
restore::open_file(point_body)
restore::open_file(ins_head)
Database restore failed with error 'no such file or directory'.
Node stopped successfully.
====================== shutdown ====================== R
rose09:02
Maybe I forgot to set something in the config file? Is this recoverable or do I need to start again?
R
rose09:03
I'm thinking maybe the snapshot itself is corrupted, since the port failure may have happened during a snapshot. Is there a way to restore from the second most recent snapshot?
evoskuil11:41
If the first snapshot didn’t complete then there is no snapshot to recover to. If a second or later snapshot failed, then there will be /secondary directory and no /primary directory, and startup will recover from /secondary. The final step of a snapshot is to rename the snap to /primary, which is a file system atomic operation. So if it’s there it’s complete, if it isn’t then /secondary is used.
(edited)evoskuil11:45
The operation on non-windows may be flawed, since it hasn’t been fully verified there. I’d suggest deleting or renaming the /primary directory and then starting again. You can also attempt recovery using
bn -r (same but without starting up).evoskuil11:47
The error seems to imply that the directory rename was not atomic, since otherwise there would either be no /primary or the /primary directory should be compete.
evoskuil13:16
It would be good if you could write up a short issue in the libbitcoin-database repo that covers the situation where there was an unrecoverable /primary.
R
rose13:19
Sure, happy to write an issue. Will drop this info there but in any case, here are the files in the (renamed, unrecoverable) /primary directory: archive_header.head archive_output.head
archive_input.head archive_point.head
evoskuil13:40
Thanks. I just reviewed the implementation again and the behavior that you experienced is correct/intended. The snap is written directly into the /primary directory, so a termination during write will leave it corrupted. A fault (error) would cause it to be deleted, but in this case it was terminated.
❤️ 1
evoskuil13:41
This can be improved by writing into /temporary and then renaming it into /primary once successful.
👍 1
evoskuil21:16
I've been working on factoring
network:: classes (session, channel, and protocol) into base behavior and derived [class]_peer and [class]_client, with existing specializations derived from the _peer side of the hierarchy.
I've just completed the separation, which also has a small impact on node::. I'm going to rename the network::p2p class to net because it will end up hosting both peer and client channels.
I'm not sure I'm totally excited about the source organization, but it's at least reasonably isolated and should be performant. I'm running now to verify.👍 1
Wednesday, September 3, 2025
evoskuil13:10
No change in performance on the maxi, 900,000 blocks in 58 minutes, or with full validation in 4.8 hrs. 66 second prune and snapshot, 35 second shutdown.
(edited)evoskuil21:45
Completed the p2p->net class rename, and all
client classes are stubbed in. So time to start connecting! Next step is to add a session_input_client that uses the shared acceptor and a new [server] config section to accept incoming connections (e.g. port http://localhost:80) . Getting the channel_client 's established with a simple default protocol_client is the first step. That should allow connection by simply hitting the URL with a local browser. Then as before, it's down to isolated protocol implementations, and finally generalization across specific queries and other similar client-server protocols.🙌 1
evoskuil22:10
Posted this today based on a decred critique of the Hybrid Mining Fallacy.
https://github.com/libbitcoin/libbitcoin-system/wiki/Decred-Censorship-Computations
🔥 1
Thursday, September 4, 2025
Huddle with pmienk, eynhaender, Marnix, Rowan Voskuil, evoskuil · 50 min16:54
Friday, September 5, 2025
evoskuil19:04
Antoine Poinsot
An investigation into a few hundreds misbehaving publicly reachable nodes on the Bitcoin network
👍 3👏🏻 1👏 1
Monday, September 8, 2025
evoskuil01:03
Just fired up the node with a
session_inbound_client, opening a socket acceptor on the configured ip:port, attached to the port using http://localhost:42?hello=world, which spawned a socket and created a channel_client containing the socket, and hit debug points in attach_handshake.👍 2
evoskuil02:07
I'd say that within a week I'll be building http (get/put/websockets), Core JSON-RPC compat (http), Stratum v1/v2, and Electrum protocol stubs. Then it's off to the races.
🎉 3🚀 1
I also verified that we can actually embed a subset of Mbed TLS, for TLS and use a simple cert directory to avoid platform-specific stores.
🙌 2
1 reply · evoskuil · last Sep 09, 2025
jungly09:04
Did you see Core's move to use capnproto for IPC stuff? Their push approach to getblocktemplate is interesting. Though, it seems like the docs on the IPC changes are a bit lagging.
2 replies · evoskuil, jungly · last Sep 09, 2025
jungly11:11
The capnproto stuff is about optimised (de)serialisation. I am not too excited about it tbh.
However, switching from pull getblocktemplate to push is interesting.
As things stand, we wait for a blockupdate on the zmq publishing endpoint and then fetch a blocktemplate. The change to push, eliminates this round trip and bitcoind now pushes blocktemplates when certain well defined criteria are met. It is a slight optimisation, but it is in the mining loop, so could be important.
Thursday, September 11, 2025
Huddle with evoskuil, Marnix, eynhaender · 131 min17:03
eynhaender18:03
This is a current libbitcoin run on my 92GB RAM computer on a 300MBit internet connection. Ubuntu 24.04.
This is core on the same computer/os. I don't have a milestone counter for this though.
Keep in mind that activity doesn't necessarily means progress. To see the real progress speed on the chain, we'd need to add the block height.
👍🏻 1
Friday, September 12, 2025
eynhaender00:53
There we have a full core sync to current block height. I can't tell at what point we crossed 900k but I assume it was with the pattern change at 430 minutes. Compared to yesterday's libbitcoin milestone run of 306 minutes to 900k, libbitcoin is 29% faster than core on the same setup. Or, because it sounds better, cores needs 40% longer to sync.
👍 1
evoskuil00:54
Sure, if you slow the network enough Core will be the same, because we are network limited and Core is not.
evoskuil01:04
The efficiency is very evident in network receive. Libbitcoin is almost entirely continuous receive.
Notice also that we do much less writing, though our reading picks up toward the end due to duplicate detection.
Also, it's worth checking if there is any "assume utxo" going on by default (I assume not).
(edited)Also their default assume valid point is probably lower than ours. That's prob why CPU changes toward the end.
(edited)Saturday, September 13, 2025
eynhaender17:34
Look at that beauty. It looks much better if I run it while no one else is using the internet. I also extended the script to scale horizontically. this is a 600k dynamic release. I will do the same for a static release next night. both milestones of course.
❤️ 1
oh, the binary?
1 reply · eynhaender · last Sep 13, 2025
And I was also playing with the full sync again.
validation kicking in?
evoskuil17:40
You can set a checkpoint at genesis to prevent that (always clear the store when changing milestone/checkpoint [or fork] settings).
(edited)But checkpoints are consensus.
(edited)eynhaender17:40
[database] path = /mnt/blockchain/bitcoin [network] #threads = 4 #threads = 16 seed = cup.nop.lol:8333 [bitcoin] #checkpoint = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0 milestone = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0 [node] #threads = 16 #threads = 32 [server] inbound_connections = 0 bind = 0.0.0.0:80
you mean this
evoskuil17:41
[bitcoin] #checkpoint = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0 #milestone = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0(edited)
evoskuil17:41
If you enable the checkpoint, it overrides the defaults. Same as for milestone.
(edited)With both set to genesis, you start fully validating at 1.
(edited)With checkpoint only set to genesis, you still start validating at 900,001 by default.
Venn diagram 🙂
eynhaender18:44
we have a similar patter with milestone AND checkpoint set to genesis, it's just way slower
Whenever it starts validating, it stops downloading. that'what I see.
and hardware utilization is a joke while validating
evoskuil18:52
Yes, validation is prioritized over download, since download is significantly faster. However CPU should sustain 100% unless it has download gaps.
(edited)Do you have node thread count configured?
eynhaender18:56
no, that's all settings I have on the last one:
[database] path = /mnt/blockchain/bitcoin [network] seed = cup.nop.lol:8333 [bitcoin] checkpoint = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0 milestone = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0 [server] inbound_connections = 0
evoskuil19:52
In the first 250k blocks or so there is very little actual validation (empty blocks don't even have scripts to validate), so it may just be low CPU because of the overhead in that range. How much time did the plot above cover?
(edited)eynhaender22:06
block_organized..... 316162 5197 block_validated..... 316163 5197 block_confirmed..... 316163 5197 block_organized..... 316163 5197 block_validated..... 316164 5197
Looks like you're validating on at most 4 threads.
Sunday, September 14, 2025
Tuesday, September 16, 2025
evoskuil17:35
Update: stream readers are updated for strong/line-oriented parsing (new
read_line(terminator) methods). This allows for simplified and efficient parsing of http request line, headers, and bodies given single/multi-char terminators (such as "\r\n", " ", ":", "," and ";").🎉 1
1 reply · evoskuil · last Sep 16, 2025
evoskuil22:03
write_line(string, terminator) also now added to the stream writers. Simplifies creation of the http response line, headers, and body. Also created request and response objects to encapsulate each. The request is passed via the notification mechanism (like p2p messages), along with the message (request body), which determines the notification type. This gives the handling protocol(s) direct access to the request while maintaining loose coupling and statelessness. The response object is constructed passed when a message is sent (response body).
http request/response only applies to html and json-rpc (Core compat) protocols, as well as the first message in a WebSocket upgrade. Others, including Stratum (vs/v2) and Electrum are just JSON over TCP - no http request/response. So those just skip the request/response serialization but are otherwise the same.👍 2
Thursday, September 18, 2025
evoskuil04:02
Completed implementation of the
response object, and refactored to share redundancy with request . Added comprehensive testing for all the parts, which mostly covers the hard part of http.🔥 1
Huddle with pmienk, evoskuil, Rowan Voskuil, eynhaender · 268 min16:54
6 replies · eynhaender, cguida, parsevalbtc · last Oct 03, 2025
eynhaender13:39
Well, seems to be the new normal at least. No disadvantage on milestone runs with this hardware on linux compared to Win 11. At least not while network is the limiting factor ☝🏻
🙌 1
C
cguida17:47
Oh wait, that's not faster than windows, not sure why I said that... 5 hours is much slower than windows on my machine, which was about 1-2 hours
Friday, September 19, 2025
evoskuil05:07
I tracked down a subtle bug in the
byte_writer exposed by using its ::set_limit(...) in conjunction with ::peek_byte() , and also implemented an dynamical exponential buffer expansion for http header reads with an lower and upper bound configuration. This keeps the pre-channel read buffer small in cases unless larger is required.eynhaender12:08
I checked the cpu activity during validation with the ressource monitor. Fortunately it shows the same low activity as the diagrams we've seen yesterday. In other words, we can reproduce the unwanted behavior at will. @evoskuil Can you send me the exact config file you used yesterday?
evoskuil14:16
The only thing material to the config apart from defaults is the setting of milestone to genesis and node.threads=64 (to match my hardware 32x2 cores). If your thread count was too low the low utilization would be expected. I think the default is 32, which is what I use on the mini (8x2 cores).
Also it doesn’t appear you are having any issues in milestone, which appears to resolve the original question of low resource there.
There's a bunch of plots there.
Wednesday, September 24, 2025
evoskuil01:40
Spent some time formalizing http header field parsing. The request and response are now fully compliant with http1.1 and tested. Next I'm going to validate required/honored headers, obtain content size (or chunked) and load the body. Also did some renaming to better align with http standards.
🙌 1👍 1
Thursday, September 25, 2025
Huddle with pmienk, evoskuil, Rowan Voskuil · 159 min16:51
2 replies · Rowan Voskuil, evoskuil · last Sep 25, 2025
Rowan Voskuil18:35
blockstream.info
Blockstream Explorer is an open source block explorer providing detailed blockchain data across Bitcoin, Testnet, and Liquid. Supports Tor and tracking-free.
evoskuil18:36
Blockchair
Analyze Bitcoin blockchain stats: search blocks, transactions, addresses, balances, and more with fast and reliable Blockchair explorer.
Tuesday, September 30, 2025
evoskuil22:14
The boost beast http request deserializer and response serializer are now integrated. There's a simple protocol class that gets attached to the channel upon connection. The channel parses the request, and dispatches the request object. The protocol subscribes to message notifications, receiving the request, and performs arbitrary processing to construct a response object, which it sends. The subscribe and send are the same as with p2p, except there is only a single message type to subscribe to and to send. For http this is sufficient, as the protocol then just handles page provisioning. It's identical to p2p processing, just sitting on top of existing structure.
evoskuil22:21
For http REST APIs (eg bitcoind JSON-RPC) we can utilize a derived channel to process the request body from json into message objects and dispatch to any number of protocols. This would make it identical at the protocols level, apart from any semantic differences, for other interfaces, such as ElectrumX and Stratum. So I think I'm going to leave this low level http processing in the network layer and implement the messages and associated protocols in node.
👍 1
