Bitcoin full node and query server
Sep 2, 2025
View in context in the libbitcoin Slack #general mirror.
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