-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bitcoind: add separate p2p socket for tor connections #405
Conversation
f11db15
to
ec189d3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
ACK ec189d3e89f22d463884b0e02f127bd4fae312e8
Inbound tor connections now tagged as "network": "onion", not
"network": "not_publicly_routable".
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEiDOlIkszv4ojhh+OtgROy6La5dAFAmFmw0wACgkQtgROy6La
5dDkOw//X/UsAUS8n/PFhhb/HSQ8Numq4mmYnOLiajnSBwRhfZgLywzLd96K3xDa
9YHUYO63CjF0uc/w90rQdqHKbFmwEUheHjPLjqiqG3rcwOcfGX3lIYrkdrPLOHIc
NA5NgeEY7EXv9qagMP5rOJY0ucsM2Yb9h+A0naqmM1Uts4cruJHXYOOqm0CS+3/u
8r168S3gWIC7KZwgFUXkMzTaRFmMpNU3ye6qTCzF0qsIHnwbP5XSs2f9uZjVRpI2
LKi2uk8tj8FkOjaB7erEKII3nmUGrN6+Jlk8c4AoSGfRAbuKdWvnRFklPl3/ZccF
X/ryzqS8KXxuwsCvSCF55P53/6fhCC3JH9OUGy1EsqMP2W41zn7im5by3F0bbv/z
4QHrqyGHlxMKwDx1RQldfDJhwYrD5Or90xHFqSj3VOiMnEQl2olBAIRml4+0lsj6
Pu8Pa+dFNJN+Q3CO9ghP+qJ2XdbitjFXYzi2F+JFkdwnodlBVeCAD3HV3KrmoABN
4J7Xvxs2K6SfxlYZX8XQ5W9eS7MaUNBGFX+75eiwdiNJYB/tKMJVdFcp4OlFPSU+
2yqSM2BJNW2ufnfSqNi6d3N3w42s98a+mF81wapidEJW5yfE3IdeW8WhoFO0OhUQ
fzF6eggLlvLydgX0CZDKKIJ8wK7dOP0zQ5k3+1h+mzzGRaSHiYI=
=1+oV
-----END PGP SIGNATURE-----
It's still not clear if we need this. In my tests bitcoind can distinguish Tor connections from regular connections that originate from the same localhost socket, so no seperate socket is required. |
ec189d3
to
0a1fa66
Compare
Whether an incoming peer is flagged as So this PR is still relevant. I must have accidentally used this PR in the test mentioned in my previous post. I've found a |
Here's a script which tests this PR. |
02c38ee
to
ffd2902
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
ACK ffd2902a7dc41052f7383ac7c9508ebb85a1a705
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEiDOlIkszv4ojhh+OtgROy6La5dAFAmFwJ4sACgkQtgROy6La
5dBpiBAAl5m1ZTMIr9igNJr9K8NlBmC8gcFtxTvBNUFXzc2mnLnUOxWHHWexaMaU
afEQ0juGcDJMIml/8/Xm+SMYNgFslC2fI19ue03HcVGk8D02Sc/DRdaivblXgkWy
/iQEIOh9XeCUKnUbtW7NSmHFEd2oUIztv8uyvvgnaLVBZw+42x2tJmG+v0yChXeC
FsO3Oatqxn9BYSgr3XY/D95VBLO4Gb7DsTNMn9KT5cUCE35tnCRf9F8pGtfyGH+l
HL381VaaY3gV7/Bzh82+B05Y8AKCrMEc3p2nzeNyFEDqpvxBEfXgbJlvrEUcexJZ
SY3u1HZryQafS64QNf+N0O+S70U3jFObwIh9TzqLVGE4AqtK9e0JEltSOe2r0Mip
T1jyGbYpgBwJOURrPTGJ7YF6aSTsKvhEoKSOxkMBHerXQPJLmPcRSOk0wXCMVhYB
VH2edcFKoJiENh6eXlLmEqFmm99atRDy6mjBa03ME+HbhaHfpd6CN3fTYJ5KwqPI
xxrCLWzXZe67ySok3mcKAIep6Hf3gON3J2YloweE9TXqwU70N2Q+Wf6kmTwM1/O4
+ACznnWAThq8PPrO/Gm5q6apQOXJTWEDJtM72mrxBzbGejbqJT0vvc9x94gSdHrF
wIwPXBJr0Ql+Uy95yVncH5sN6KESalb5gP9tGkwgd/rG60JDjVQ=
=ejIq
-----END PGP SIGNATURE-----
@@ -118,19 +118,13 @@ in { | |||
}; | |||
# Enable p2p connections | |||
listen = true; | |||
extraConfig = '' | |||
whitelist=${nbLib.address cfg.nbxplorer.address} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! This is actually a low to medium security issue because obtaining the mempool via bip35 allows determining the transactions originating from a node (iirc). I think in general the download permission is still necessary, because bitcoin module users might want to use maxuploadtarget
without breaking their btcpayserver. On the other hand, giving download
permissions for inbound onion peers also breaks maxuploadtarget
(as is the for the electrs module).
If you're confident that no whitelisting works with btcpayserver (@nixbitcoin did you test this?) we can merge this to fix the issue of fully whitelisting onion nodes. But my guess is that if we want to do this correctly we won't get around the complexity of having a whitebind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
confident that no whitelisting works with btcpayserver
We only introduced whitelisting three weeks ago and it has worked fine before.
having a whitebind
As mentioned here, whitebind
is incompatible with listening on all interfaces (0.0.0.0
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only introduced whitelisting three weeks ago and it has worked fine before.
Ugh true that. I remember having issues using btcpayserver without whitelisting but that may have been before we added the btcpayserver module to nix-bitcoin.
Whitebind localhost and add a separate onion socket (whitebind=127.0.0.1:8333, bind=127.0.0.1:8334=onion)
This is incompatible with accepting inbound connections on all interfaces bind=0.0.0.0:8333 due to the port clash.
Is there a problem with whitebinding on 8335?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a problem with whitebinding on 8335?
We would need to add options listenLocal
and localPort
(= 8335
) in bitcoind and liquidd and use them in btcpayserver
and electrs
.
This adds more complexity and we would move away from the default p2p port which might surprise users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More complex, yes, but seems like the right approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I add it to this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to have, but not extremely high priority (compared to not give full whitelisting permissions to onion peers).
ffd2902
to
1fdc5a1
Compare
This re-enables onion tagging while still supporting untagged connections. Onion sockets are not yet supported in the latest liquidd/elements version 0.18.1.12 available on nixpkgs.
Whitelisting localhost implicitly whitelists all inbound onion connections. This prevents banning misbehaving inbound onion peers and enables message `mempool` which can cause privacy leaks. Instead, grant `download` as the single bitcoind whitelist permission, which should be safe for onion peers. Remove liquidd whitelisting because it doesn't support fine-grained permissions. After a cursory glance at the nbxplorer code I think that nbxplorer requires none of the other default whitelist permissions (noban, mempool, relay). Details: dgarage/NBXplorer#344
1fdc5a1
to
ec4a4db
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK mod nit
|
||
# When the bitcoind onion service is enabled, add an onion-tagged socket | ||
# to distinguish local connections from Tor connections | ||
services.bitcoind.onionPort = mkIf (cfg.bitcoind.enable or false) 8334; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does "or false" do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's just too much sugar for me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK ec4a4db
Main commit msg
This re-enables onion tagging while still supporting untagged connections.