I’ve never exposed the RPC over Tor before (this seems less secure, since you could mix up the two .onion addresses and leak access to your RPC – though .cookie auth should mitigate that risk). So I don’t have experience with this.
My understanding from the spec, though, is that bind is for the p2p interface (port 8333) It should have no bearing on the RPC interface (port 8332). If you remove both bind and rpcbind, does it still work? I’m wondering if the loopback 127.0.0.1 is too restrictive when Tor is in between. You could try 0.0.0.0 to test that theory (though don’t leave that way, since it opens the RPC up to any incoming IP.
It looks like “discover” tells Knots to discover it’s public IP(s) and advertise them. That would only be applicable if you were accepting incoming connections over clearnet (It associates your public IP with Bitcoin, which from a privacy perspective could increase your risk of a wrench attack)
Besides the ones you have, it looks like onlynet=onion might be good (along with discover=0) to increase your privacy by only operating on Tor and not clearnet.
The 1 incoming connection implies your node is reachable. I’m not sure what numbers are considered normal (I’ve seen this range wildly). 1 and 10 are not concerning. It gives you a good diverse sampling of the network.
I don’t need bitcoin-cli beyond that, so I guess I could remove the rpc things and put server=0 for good measure
What I find weird is that beside that user agent of an incoming connection, I have seen another one connected now too:
user agent: bitcoinj:0.16.2/Bitcoin Wallet:9.26
127.0.0.1:46808
Why would that connect right now? wtf. And I have no wallet opened or anything. I mean im assuming all these 127.0.0.1 incoming connections are internal things but I don’t understand it since I have never seen this before.
I have commented all bind and rcpbind lines on bitcoin.conf (leaving server=1) and it’s working. I don’t get it, yesterday when I tried without these it was not creating the .cookie file.