Closed cbeams closed 6 years ago
r3dsojfhwcm7x7p6 was moved to one of @Emzy clearnet nodes.
r3dsojfhwcm7x7p6.onion is now running temporary on 62.75.210.81 as second hidden service.
I upgraded to a more powerful server, hopefully with fewer timeouts. Can you change the ip from 37.221.198.57 to 88.198.39.205?
Thanks for the update. The 37.221.198.57 server is not used then anymore I assume. The nodes are hard coded so the change will be only in the next update. I will change also that the domain name will be used instead of the IP (costs extra DNS lookup via Tor but is more flexible for such cases).
The old server is still running, but that may change in the future. So it is not a problem, if the change isn't immediate.
Ah cool. We will have soon an update anyway and our users are usually fast with updating. Just changed that we use the domain instead the IP if both are available.
I added a tor hidden service to my bcwat.ch node: z33nukt7ngik3cpe.onion:8333
@sgeisler Ah great thanks!
@tbocek @jhoenicke : Co you have your nodes also reachable as onion nodes?
My node with hidden service: lgkvbvro67jomosw.onion:8333
New hostnames for my nodes: node1.emzy.de has address 163.172.171.119 node2.emzy.de has address 62.75.210.81
@mrosseel Can you set a domain name as well. Gives more flexibility in case of moving the host.
@Emzy Can you setup tor for 78.47.61.83 and provide a domainname + IP for poyvpdt762gllauu.onion?
@jhoenicke @tbocek : Do you have tor enabled for incoming connections? If so can you provide the onion address?
@jhoenicke, @tbocek, @sgeisler : Do you have the maxconnections set to default (125) or do you have set it higher? 500 seems to be good but of course cause more traffic. We saw that the nodes are not getting filled up (and then rejecting new connections) if that limit is > 400.
Also the timeout for btc nodes is default 5 sec. which seems for Tor connections too low. We increase that now to 30 sec. Do you see any concerns by changing that?
I use those settings in bitcoin.conf: maxconnections=500 timeout=30000
I use Tor only for incoming connections, so no setup on the btc side just edited the torrc files. That way the btc node has no risk to get partitioned from the rest of the btc network as it get mixed incoming connections and connects itself via clearnet to other btc nodes.
We will change the behavior also that we will connect to onion nodes only if the user has Tor enabled for BitcoinJ. That prevents privacy and performance issues with Tor exit nodes if Bisq nodes would connect to clearnet btc nodes over Tor. Do you see any concerns by sticking to Tor btc nodes only (as mentioned above there should be no risk for btc network partitioning issues).
My node kirsche.emzy.de has now a onion address: 78.47.61.83:8333 | kirsche.emzy.de | fz6nsij6jiyuwlsc.onion:8333
Closing as superseded by #67, primarily because this issue has gotten so long and is in many ways now out of date. See also the new "Bitcoin Node Maintainer" role at #66.
The distinction between Maintainer and Operator here is important. Going forward, the Bitcoin Node Maintainer (currently @ManfredKarrer) will be responsible for updating shared bitcoin.conf
config files and ensuring that all operators in the federation are aware of and up to date with changes to it. This way we should have clear lines of responsibility about ensuring that config changes get propagated across the federation in a consistent and timely way.
Is this list still being maintained? I am looking for some trusted & reliable Tor fallback nodes for bitcoin.
See #67 for current nodes maintained by Bisq contributors.
The idea here is that a number of Bisq contributors take on this role, run a full node and publicly attest that their full node will run the latest major version of Bitcoin Core. Doing this provides a service to Bisq users who want to ensure they're on the correct chain during contentious forks like that posed by the forthcoming SegWit2X project.
See https://lists.bisq.network/pipermail/bisq-contrib/2017-November/000006.html for further details and links.