Bitcoin full node and query server

January 2026

Archive of the libbitcoin Slack #general channel.

Thursday, January 1, 2026

u32Luke00:39

Happy new year all! Thank you to all of the developers for pushing us towards greater decentralization and growth 🎉

🎉 1

TC01:37

Howdy! Happy New Year!

🎉 1

evoskuil16:29

I'll be here today for the meeting in 30 mins.

Huddle with evoskuil, eynhaender · 140 min17:02

Friday, January 2, 2026

evoskuil10:36

I've completed the split of libbitcoin-server and the bitcoin-server (bs) console builds from libbitcoin-node and bitcoin-node (bn). This means there is no longer a bn console application. node is now a dependency of server, and server provides the console application. The node and server libraries are about the same size, and splitting them has simplified and better organized the code and sped up the individual builds. The only difference for general usage is that the install.sh from the libbitcoin-server must be used, the console application is bs, and the log file names are bs_begin.log and bs_end.log. Config settings were already organized with the anticipated (server) names, so there is no impact to settings.

(edited)

👍 1

eynhaender12:50

Excellent, that's now absolutely consistent and makes it clearer in external communication. I'll clean up the readme later.

👍🏻 1

evoskuil18:51

Looks like there are some build configuration issues in libbitcoin-server, so there's no console at this point. Should have it ironed out soon.

evoskuil20:28

All good now.

evoskuil22:51

I've updated the secp256k1 NuGet package, adding a proper versioned release for the outdated version we have been using for the past year, and also a release that tracks with the current release. https://www.nuget.org/packages/secp256k1_vc143

22:54

I'm looking into LTCG for the vc++ and eventually all other builds. This should reduce binary size and improve performance. We've supported these builds for some time, but dependencies must be built with the same compiler, not just the same version compiler but often the same patch release. So by updating the secp256k1 library this updates the ltcg binaries to the current vc++ compiler that I'm using and therefore enables this scenario.

👍 2

Sunday, January 4, 2026

evoskuil05:52

https://x.com/samwhoo/status/2007590903448514921

X (formerly Twitter)

Sam Rose (@samwhoo) on X

StackOverflow graph of questions asked per month. Holy shit.

😮 1

eynhaender05:57

ouch

evoskuil08:17

It took 1 day to integrate SOCKS5 for [outbound] and [manual] (p2p) connections. These are configured independently (and there is no inbound p2p or incoming service endpoint support).

[outbound]
socks = localhost:1080
username = foo
password = bar

[manual]
socks = localhost:1080
username =
password =

Credentials settings are parsed, but password authentication is not hooked up yet. I'll get that in the morning. This is the very first successful round trip message via socks5 proxy, and the very first block synced (later in the same connection).

🚀 2

evoskuil08:28

About half the work for this was just passing through the settings via the config, node connector factories, sessions, and connector construct, and updating all tests. The rest was nothing more than a derived connector class. The connector and acceptor are socket factories, establishing one socket connection per instance, managing timeouts, name resolution, bindings, socket config, etc. So this just overrides connector::handle_connect(...) and connector::start(...) protected base class methods and implements the indirection on the socket strand. https://github.com/evoskuil/libbitcoin-network/blob/master/src/net/connector_socks.cpp

evoskuil08:34

Once the connection is established the socket is handed off as before with no other impact. Note that the connector operates on the network strand, and establishes sockets - which have their own strand. The socket is used in the handshake with the socks5 proxy server, so that operates on the socket's own strand. Given socket::stop() and all other methods are thread safe and dispatch to its own strand, it's pretty simple. And when already on own strand, dispatch is a no-op. So the communication sequence enters the socket strand and then returns to the connector's network strand, to safely complete the base operations.

(edited)

evoskuil08:39

I worked primarily from datatracker.ietf.org/doc/html/rfc1928 and used a simple/crappy local proxy called shinysocks https://github.com/jgaa/shinysocks and Wireshark for traffic analysis.

08:43

Also, I compiled with LTCG in vc++ and ran some performance tests. Noticeably worse, and the binary was even slightly larger. So that's back on ice.

evoskuil08:50

I tried running a default sync against the little proxy, and it of course crashes in a few seconds. Also the node is rejecting multiple connections because they reflect the same IP address. Still need to capture the outbound address as the channel address (which normally we get from the socket itself).

evoskuil19:23

SOCKS5 is what gives us Tor and I2P support. So that's now implemented, with the exception of gossiping onion and garlic host addresses via p2p. That just requires processing of the address_v2 message, with updates to the address pool.

Monday, January 5, 2026

evoskuil03:14

Syncing via SOCKS5 through Tor now, with and without password authentication. Tor is one of the easy ways to functionally verify this, as it accepts any username/password, or not, which are distinct protocols. Also the issue of the socks proxy being identified as the endpoint authority is now resolved, using the configured endpoint to address as the outbound authority when proxied.

(edited)

🔥 1👍 1

evoskuil04:42

100-200Mbps over Tor, on over 50 channels.

04:44

Rate limiting of course kicks in, as the bandwidth of the entire Tor network is under 1Tbps. But certainly our proxy client is working 🙂.

evoskuil04:54

This seems to mitigate the throttling, as well as some of the connection rejection. It appears to accept on just one thread, and reducing the batch size to 1 reduces some of the connection establishment concurrency. Reducing the number of connections doesn't drop the bandwidth, but smooths out the throttling. Tor attempts to connect for 15 seconds, so I also increased those timeouts (from 5 secs) to reduce connection churn. This now cycles between 50 and 175 Mbps

[outbound]
socks = localhost:9050
connections = 50
connect_batch_size = 1

[network]
connect_timeout_seconds = 15
handshake_timeout_seconds = 15

04:55

04:56

evoskuil05:04

Gotta say, I'm pretty happy with that, especially since we had zero proxy work done as of 48 hours ago.

evoskuil05:31

I also bumped up the standard deviation threshold, as it doesn't seem possible to hold anywhere near enough connections to saturate bandwidth. So no need to be dropping the slow ones (stalled ones still get dropped). The default value is 1.5, and a (negative) SD limit of 2.0 rarely drops.

[node]
allowed_deviation = 2.0

05:32

Even better...

evoskuil06:04

Can even loopback over the simple ShinySocks proxy:

2026-01-05T06:02:24Z.0 Node is running.
2026-01-05T06:02:26Z.2 Accepted peer connection [127.0.0.1:61716] on binding [0.0.0.0:8333].
2026-01-05T06:02:26Z.1 Outbound [127.0.0.1:8333] version (70015) "/Satoshi:0.14.2/"
2026-01-05T06:02:26Z.1 Inbound [127.0.0.1:61716] version (70015) "/Satoshi:0.14.2/"
2026-01-05T06:02:26Z.2 Manual channel start [127.0.0.1:8333] success

proxy log:

2026-01-05 01:01:49.572 Eastern Standard Time INFO 61612 ShinySocks 1.4.0 starting up. Log level:
2026-01-05 01:01:49.579 Eastern Standard Time INFO 61612 Resolving host=0.0.0.0, port=1080
2026-01-05 01:01:49.585 Eastern Standard Time INFO 61612 Listener on 0.0.0.0:1080
2026-01-05 01:02:26.151 Eastern Standard Time INFO 33196 Incoming connection on socket.
2026-01-05 01:02:26.156 Eastern Standard Time INFO 24472 Proxy starting on socket 127.0.0.1:1080<-->127.0.0.1:61715
2026-01-05 01:02:26.161 Eastern Standard Time INFO 24472 ParseV5Header: Will try to connect to: 127.0.0.1
2026-01-05 01:02:26.167 Eastern Standard Time INFO 24472 Connecting to endpoint 127.0.0.1:8333

evoskuil06:13

Tor doesn't like the loopback:

Jan 05 01:11:56.000 [warn] Rejecting SOCKS request for anonymous connection to private address [scrubbed].

Note that I often use something like this for p2p testing:

[node]
user_agent = "/Satoshi:0.14.2/"

(edited)

evoskuil06:47

And I just realized that string shouldn't be quoted :)).

evoskuil07:20

Running a full sync now over Tor. I'd expect it to be 10-15 hours (vs 1), which would still beat bitcoind (without Tor) on this machine! :)

(edited)

🔥 3😂 1

07:23

I'm going to merge this in a bit. The only issue presently is that fqdn peers (e.g. manual.peer and outbound.seed) will not resolve when passed via a proxy. I'll deal with this when I add onion/garlic resolution and address gossip.

evoskuil17:41

Windows maxi is on block 872,646 at 10.7 hours over Tor. That's about twice as fast as Core on the same machine without Tor. When it hits 900k I'll plot the data, but it looks to have been pretty constant all night. Full validation would be about the same time, since maxi only needs 4.2 hours to validate.

(edited)

🚀 2

evoskuil18:41

900k over Tor in 11.7 hrs.

🎉 2

evoskuil21:05

Pretty consistent rate.

evoskuil21:36

eynhaender21:57

nice

evoskuil22:20

On this machine bitcoind took 24 hours to assume valid to block 850,000 (no Tor).

(edited)

eynhaender23:28

I'm increasingly getting the impression that assumevalid takes longer than the standard sync.

1 reply · evoskuil · last Jan 05, 2026

evoskuil23:29

It should be the same as long as there is excess CPU when fully validating, and there is always excess CPU when validating blocks sequentially.

Tuesday, January 6, 2026

evoskuil01:13

https://github.com/bitcoin-core/bitcoincore.org/pull/1210

😮 1

pmienk01:16

Pretty big whoopsie

01:17

Always back up your keys

👍🏻 1

Wednesday, January 7, 2026

stratan19:09

replied to a thread: view

Hello again! Your feedback regarding the disk space was correct. I wasn't expecting it to really be a disk issue as I had over 100gigs of disk space (don't remember the exact number). Now libbitcoin-node spawns and works just fine. I stumbled upon another "issue" when trying to port libbitcoin-node as a target for fuzzamoto. That is, fuzzamoto uses Nyx for deterministic snapshot fuzzing but due to its limited resources it doesn't have enough space to pre-allocate a regtest db profile. I played around and hacked a regtest config that seems to work ok and I would appreciate your feedback on whether I'm overdoing it or not. I haven't found any documentation around libbitcoin-node + regtest so I'm open to suggestions on that side too.

[log]
path = {logdir}

[bitcoin]
# Regtest genesis block (hex-encoded)
genesis_block = {genesis_hex}
# Regtest proof of work limit (0x207fffff = 545259519)
proof_of_work_limit = 545259519
# Accept any valid chain (no minimum work requirement)
minimum_work = 0000000000000000000000000000000000000000000000000000000000000000

[forks]
# Regtest allows easy mining without real proof of work
difficult = false

[network]
# Regtest network magic (0xDAB5BFFA = 3669344250)
identifier = 3669344250

[inbound]
# Listen for P2P connections
bind = 127.0.0.1:{p2p_port}
connections = 10
enable_loopback = true

[outbound]
# Disable outbound connections to prevent contacting mainnet seeds
connections = 0
host_pool_capacity = 0

[database]
path = {datadir}
# Tiny regtest DB profile (avoid multi-GB prealloc).
header_buckets = 1
header_size = 1000
txs_buckets = 1
txs_size = 1000
tx_buckets = 1
tx_size = 1000
point_buckets = 1
point_size = 1000
strong_tx_buckets = 1
strong_tx_size = 1000

input_size = 1000
ins_size = 1000
output_size = 1000
outs_size = 1000

candidate_size = 1000
confirmed_size = 1000
duplicate_buckets = 1
duplicate_size = 100
prevout_buckets = 0
prevout_size = 1

validated_bk_buckets = 1
validated_bk_size = 1000
validated_tx_buckets = 1
validated_tx_size = 1000

address_buckets = 1
address_size = 1000
filter_bk_buckets = 0
filter_tx_buckets = 0

[node]
# Don't delay inbound peers waiting for "current" chain state (regtest genesis is old).
delay_inbound = false

Thursday, January 8, 2026

evoskuil03:44

replied to a thread: view

Hi, you've definitely got the right idea. I haven't tested regtest or testnet in a long time, so it's good to see this. I’m traveling so can provide much more feedback, but it should work. Just note that one bucket means the hash table becomes a linked list. That's fine but of course will be a bit slow if there are a lot of entries. I do it by accident sometimes and am always surprised that’s it’s pretty fast considering. Also, I don't think you want loopback. That allows the node to connect to itself.

evoskuil03:44

replied to a thread: view

Also, bn is no longer. You will need to move to bs for future work. Same config and command line otherwise.

stratan07:19

replied to a thread: view

Thank you for the feedback! I’ll keep it in mind.

stratan07:22

replied to a thread: view

As far as I understand bs isn't at a “usable state” according to its README, which is why I pivoted to bn. How do you suggest I proceed?

(edited)

Huddle with pmienk · 31 min16:54

Sunday, January 11, 2026

evoskuil19:31

I've merged the last of the socks5 work. This generalizes the socket address handling so that both numeric and non-numeric (fqdn) addresses remain supported for both proxied and unproxied connections. Previously the presumption was that the far end of the connection was always resolvable to its IP address, which was used for certain aspects of peer tracking and logging. This is now generalized to non-IP names. This is necessary because under a proxy the name resolution should occur at the proxy, and the resolved IP address is not necessarily returned to the caller under socks5 (e.g. Tor proxy). Given this change address tracking is now based on the outgoing config::endpoint as opposed to the outgoing config::authority. And the resolved IP address remains used only for differentiating incoming connections.

Monday, January 12, 2026

evoskuil19:15

I've merged a few updates to the explore interface, which will allow for completion of the block explorer. One of these queries is pretty expensive, since we don't cache fees. Fees require prevouts, and where we skip full validation and client filtering, there's no point at which we have prevout association during sync, which means no fees. The current "block details" query pulls in the whole block and its prevouts in order to compute fee-related values, and a bunch of other stuff available given the populated block. On a single thread this takes < 100ms for a warm store, which is fine for now. On a cold store the paging cost can bring that up to 1-2 seconds. The cost can be dramatically reduced be de-normalizing the query (not getting the full block/prevouts). We could provide an option to impose fee caching in the exact same way to impose client filter building, which would slightly increase the store size and reduce this query to almost nothing (~3ms, like the others). On the maxi that would raise milestone sync time from 1 hr to 2.5 hrs (basically client filters). Really there's no need for high speed block fee queries, and that would be very reasonable for a server. When performing full validation there would be only trivial time increase. So a simple approach would be to drop block + prevout computed values into the client filters table and use that as optimized query when available. WRT analogous values for txs, it's probably not work the space to cache such values.

Tuesday, January 13, 2026

evoskuil03:37

New record maxi milestone sync time of 52.8 mins to block 900,000. This just my periodic check to make sure changes aren't causing some unexpected hit. This build incorporated generalizations of the socket class to simplify secure transport integration for each of the transport protocols (zmq and sv2 stubbed in but deferred): p2p/s, http/s, ws/s, zmq/s, rpc/s, sv2/s.