Warn federated nodes clients when disabling tor for Bitcoin network (or enable Tor automatically in the same case)

suddenwhipvapor commented 1 month ago

Description

Currently, Bisq btc nodes federation is prominently tor-only, hence, if a user unchecks "Use Tor for Bitcoin network" under Settings > Network info, Bisq will not be able to connect to more than 2 btc nodes, making it impossible to trade.

Version

1.9.17

Steps to reproduce

Use federated nodes, disable tor for bitcoin network, restart.

Expected behaviour

Bisq should show a warning popup, telling users that if they disable tor for bitcoin connection, it should only be in case they plan to connect to a node on the local network, otherwise if they intend to keep using federated nodes Bisq will become unserviceable because of too few btc connections. Regarding the above, the behaviour where Bisq forces a restart after disabling Tor for btc network should be discontinued, because user will also need to edit the "use custom btc node" field so after a restart Bisq can work normally. Same should also go with editing the custom node field, so that user can for example fill in a local network ip:8333 and then disable tor. In the aformentioned case, if a local IP is already filled in the custom node field, the warning popup for disabling tor should not be shown,

As a fall back, if no custom node is set and Bisq uses federated nodes, during startup it should automatically enable tor for btc connection even if it was disabled in settings. With some smart checks, Bisq could verify how many federated nodes have a clearnet endpoint, and if >4 allow keeping tor disabled.

Actual behaviour

No warning is posted, Bisq requires you to restart after disabling tor (going from memory it does)

Screenshots

Device or machine

Additional info

Some users have been reporting not getting more than 2 btc connections, indicating they had tor disabled.

pazza83 commented 1 month ago

I have experienced issue myself.

My thoughts are:

Adding more clear net nodes would be helpful. That way there would be more than 4 available to connect to.
If the user is unable to connect on clear net they should be able to revert back to Tor. This is not possibe to do via the UI as it will not load. It would be good for the UI to load even if there is no connection present so that setting can be accessed.

suddenwhipvapor commented 1 month ago

Clearnet nodes are harder to come by as they either need to be hosted on a VPS, which is costlier, or even worse from your own IP which reveals your location and basically your identity as well, that is why a contributor will rather expose only an onion endpoint

suddenwhipvapor commented 1 month ago

Re: UI, that is an annoyance indeed, and either it is worked to avoid the blocking behaviour during the startup, or users should be directed to run bisq with the --useTorForBtc=true parameter

pazza83 commented 1 month ago

Clearnet nodes are harder to come by as they either need to be hosted on a VPS, which is costlier, or even worse from your own IP which reveals your location and basically your identity as well, that is why a contributor will rather expose only an onion endpoint

Is there a reason why the clearnet nodes cannot just be ones that are used within the bitcoin community rather than provided by Bisq contributors. For examples ones used for open source wallet providers.

suddenwhipvapor commented 1 month ago

Clearnet nodes are harder to come by as they either need to be hosted on a VPS, which is costlier, or even worse from your own IP which reveals your location and basically your identity as well, that is why a contributor will rather expose only an onion endpoint

Is there a reason why the clearnet nodes cannot just be ones that are used within the bitcoin community rather than provided by Bisq contributors. For examples ones used for open source wallet providers.

I have sometimes wondered this myself, I guess only a small minority of public nodes have peerbloomfilters enabled, since that could be used as a DDoS vector, and being outside of bisq federation they are not bound to be always up, nor to accept bisq nodes, as the latter are identifiable on the network and usually place quite of a strain on a full node when a spv resync is in progress, so they could be targeted by a blocking script that rejects connections by them

bisq-network / bisq