Follow up on my bitcoin node installation (command line, linux, Knots).
I decided to install and configure tor.
But knots keeps generating its own address and not using the hidden tor address. I've stopped and started and removed the V3 key and tried everything grok can think of and this seems like a bug:
Why Not Use the Address Bitcoin Knots Generates?
Bitcoin Knots can generate its own .onion address by creating a private key (stored in /mnt/ssd/bitcoin-data/onion_v3_private_key) when configured with torcontrol=127.0.0.1:9051. Here’s why using this address (e.g., vbtlm...) instead of Tor’s (tj4jw...) is problematic:
Standard Approach Relies on Tor’s Hidden Service:
The standard Tor integration for Bitcoin Knots (and Bitcoin Core) involves Tor managing the hidden service via /etc/tor/torrc (HiddenServiceDir /var/lib/tor/bitcoin-service/, HiddenServicePort 8333 127.0.0.1:8333). This creates a stable .onion address (e.g., tj4jw...) that Tor advertises to the network.
Knots’ torcontrol is meant to fetch this address from Tor’s control port (127.0.0.1:9051) and advertise it, ensuring consistency with Tor’s configuration. When Knots generates its own address (vbtlm...), it bypasses Tor’s hidden service, leading to a mismatch that can confuse peers or reduce discoverability.
Knots’ Address is Unpredictable:
Each time we clear /mnt/ssd/bitcoin-data/onion_v3_private_key and restart bitcoind, Knots generates a new .onion address (e.g., q7gqu... → qucur... → vcjwb... → sl4cmn... → vbtlm...). This instability makes it hard for peers to consistently connect to your node, as the address changes frequently.
Tor’s hidden service address (tj4jw...) remains stable unless /var/lib/tor/bitcoin-service/ is cleared, providing a reliable endpoint for inbound connections.
Control and Management:
Tor’s hidden service is fully managed by the Tor daemon, which handles key storage (/var/lib/tor/bitcoin-service/), network publication, and routing. Knots’ generated address relies on Knots managing the private key, which can lead to conflicts (e.g., Knots recreating onion_v3_private_key) and lacks Tor’s robust hidden service features.
Using Tor’s address ensures compatibility with the broader Bitcoin-over-Tor ecosystem, where nodes expect Tor-managed hidden services.
Previous Issues:
Your node previously showed both tj4jw... and obbqipl... addresses, indicating Knots was advertising its own address alongside Tor’s. This dual-address behavior can split inbound connections or cause peers to connect to the wrong address.
The HSDir error (No more HSDir available to query) suggests Tor struggled to publish its hidden service, but Knots’ address generation (e.g., vbtlm...) bypasses this, creating a new address that may not be properly published either.
Can Tor Conform to Bitcoin Knots’ Generated Address?
Technically, it’s not possible to make Tor adopt an onion address generated by Bitcoin Knots (e.g., vbtlm...) because:
Tor Generates Keys Independently
#tor
#knots