-
-
Notifications
You must be signed in to change notification settings - Fork 131
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
Enable proof of work defense [2 XMR] #1122
Comments
The
However, this leads to a startup error:
So now this issue needs to resolve that error. |
There is a bounty on this issue, the amount is in the title. The reward will be awarded to the first person or group of people who resolves this issue. If you are starting to work on this bounty, please write a comment, so that we can assign the issue to you. We expect contributors to provide a PR in a reasonable time frame or, in case of an extensive work, updates on their progresses. We will unassign the issue if we feel the assignee is not responsive or has abandoned the task. Read the full conditions and details of our bounty system. |
HiddenService options are per onion service you can't just put them in torrc. I think it was more likely an attack against which POW is ineffective (OOM-Killer) A case study on DDoS attacks against Tor relays How about if I make a PR to activate IntroDoSDefense in addition to PoWDefenses
Then we can temporarily activate the metrics port in torrc on the seed nodes
and see statistics like: I think #1012 by @preland is correct, I have in
... |
Sounds ok to me. I don't know much about Tor config so will defer. |
#1129 Since the options are per onion service and the Haveno hidden service is created dynamically via the control port, parameters can only be changed via rebuild. We currently have the default settings. If necessary, we have to adjust PoW and IntroDoS parameters in the network. (Means, in reto github) |
PR #1012 and #1129 are modifications to the torrc file of the "relay" app, which is a service to relay client notifications to users' mobile devices (via google or whatever). The seednode app is unrelated to "relay". Seednode is quite similar to regular haveno clients such as desktop and daemon. It creates its hidden service programmatically via the tor control port as @boldsuck stated above. The code flow goes through netlayer and jtorctl (separate sub-projects), sending Also, haveno is still using the jtorctl binary from bisq. |
I will try to find solutions, but I'm not a dev. I'll add 0.3 XMR from myself to the Bounty. Hints:
|
Attempting to configure the same HS in torrc and netlayer produces an error "hidden service collision" when netlayer starts. Alternatively, this patch allows netlayer to be bypassed so that a HS can be used and configured in torrc. It may be experimental & ugly, but it should help investigating if Tor DoS protection does solve the issue. |
We're targeting to release within a few days, if it's possible to do anything before then. |
Bounty bumped to 1 XMR. |
Yes, I have tried something similar. Then my client or seednode had 2 hidden.service .onion addresses.
I don't think there's any other way. In Tor control-spec ADD_ONION are available at 'Flag' as hidden service options only: MaxStreamsCloseCircuit & NumStreams = With your patch all onion service options could be configured. IntroDoS, PoW & MaxStreams :-) |
Great, thanks for trying it! Would be good to know if the patch & those settings solves the perceived problem too. |
So to clarify, in order to run with proof of work defense enabled:
Questions:
Ideally it's all preconfigured out of the box, and even the seed node operators don't need to take any extra steps. Not sure I'm following the overall steps here. |
Damn, the build always failed. Hard drive has errors. Now I know why the machine always breaks the Monero Stressnet Node database. ;-)
The build is running fine on a second server. Patch applyed to haveno-reto
I'll try this right away with system torrc & haveno_seednode home folder torrc.
AFAIK the seed nodes get new .onion addresses because ed25519 keys are generated.
Yes, because no control port is used anymore.
You could write the entire torrc in
I haven't looked into it yet. You can create multiple accounts and have multiple hidden services in the Bisq2 desktop app. |
Sounds like a significant change that would require quite a bit of testing and couldn't be released any time soon. I'm wondering why it's so difficult, that the option doesn't work from startup flags. We're looking for something that is more straight forward for the short term. |
Bisq2 took the approach of writing their own PoW at the application protocol level, and have not enabled Tor's lower level PoW settings. They also configure Tor HS via the control port, presumably DoS currently not a supported configuration option there. Creating a new PoW at the application protocol level would be a major change. Bisq2 did it in a complete rewrite.
That would be a question / request for the Tor project:
Either one of the above would solve the problem. |
EDIT: Damn I have: haveno-user is in tor group
|
With the patch, the seednode only runs with system tor. Create a hidden service in
I wonder why they re-wrote this. Tor's PoW is the Equihash PoW algorithm using HashX as underlying hash function. This is derived from the RandomX hash function used in Monero's Hashcash PoW algorithm. Developed by @tevador https://github.com/tevador/equix/blob/master/devlog.md
I'll ask Roger & Matt that at the next Tor relay meetup.
Definitely not. There are these per onion service options and overall DoS configuration for which by default Tor directory authorities will define reasonable values for the network. Consensus Health -> consensus
|
Odd; have you tried to run the binary directly with that user? My guess is that the process isn't getting spawned with the correct user privileges. If running the seednode as root results in the same issue, that might be the case. I am currently unable to work on this issue until late on Saturday, so if woodser needs this issue addressed before then, I won’t be available outside of infrequent passive commentary. |
It was only because port was less than 1024. To avoid making things more complicated¹, I use ports over 1023. I am currently preparing a Haveno-reto fork with patch from @fa2a5qj3 & a finished torrc and instructions for the seed node operators. EDIT: Haveno now uses Tor SocksPort. haveno-user does not have to be in the tor group. |
This runs on the mainnet when the clients upgrade to 1.0.9. https://github.com/boldsuck/haveno-reto |
2 seed nodes are running with v.1.0.9 & the patch in the mainnet since yesterday. The 3rd is ready to take action. These are probably warning messages because peers are no longer reachable. Some Metrics PoW only works when we are under DDoS. I added a small Tor install script for Ubuntu/Debian, required torrc and some documentation. It's not finished yet. |
I've been spot-testing those new nodes for the past few days with a standard 'reto' client. e.g.unable to connect, & timeout
|
The seednodes running stable with a default 24h restart and I have on both now:
z47tltuwytd5icqq4hni2ammvlugp6pcwqboeu7ngawruualxjjuu3ad.onion
xephvvzd3orepnny7lbia4nkwie5t7wjivlvvz5lhbsck7ubavystead.onion
HiddenServiceMaxStreamsCloseCircuit: If set to 1, then exceeding HiddenServiceMaxStreams will cause the offending rendezvous circuit to be torn down, as opposed to stream creation requests that exceed the limit being silently ignored. Sometimes I get 1000s of errors from some clients. But 50-80 peers remain connected.
Unfortunately the patch also affects the clients and arbs informed us @preland. |
I'll work on getting that fixed once I get my preliminary work on the universal mac binary for monero-cpp (should have a preliminary PR up either later tonight or sometime tomorrow) |
Issue resolved byhttps://github.com//pull/1186, #1181 and paid out. |
The proof of work DoS protection flag (
HiddenServicePoWDefensesEnabled 1
) was added in #1012 by @preland.However, the flag is not applied to the seed nodes or app directory's tor directory (i.e. xmr_mainnet/tor/torcc).
This issue requests applying the flag successfully to enable proof of work DoS protection for Tor services.
The text was updated successfully, but these errors were encountered: