Change monerod --proxy to --tx-proxy#6021
Conversation
| " If this option is given the options add-priority-node and seed-node are ignored"}; | ||
| const command_line::arg_descriptor<std::vector<std::string> > arg_p2p_seed_node = {"seed-node", "Connect to a node to retrieve peer addresses, and disconnect"}; | ||
| const command_line::arg_descriptor<std::vector<std::string> > arg_proxy = {"proxy", "<network-type>,<socks-ip:port>[,max_connections][,disable_noise] i.e. \"tor,127.0.0.1:9050,100,disable_noise\""}; | ||
| const command_line::arg_descriptor<std::vector<std::string> > arg_tx_proxy = {"tx-proxy", "Send local txes through proxy: <network-type>,<socks-ip:port>[,max_connections][,disable_noise] i.e. \"tor,127.0.0.1:9050,100,disable_noise\""}; |
There was a problem hiding this comment.
It's all txes, no ?
There was a problem hiding this comment.
Txes received over i2p/tor are immediately forwarded over clearnet. So this help comment is accurate to what the current code is doing.
The issue was the "white noise" feature. When enabled, it has the effect of dramatically reducing bandwidth for outbound txes. So i2p/tor is currently only used to broadcast your own txes to another node.
ALSO - using Dandelion++ over i2p/tor is also a possibility to break up traffic analysis even further. I mentioned on Monero Coffee Chat the other day that I didn't see a reason for this since Dandelion++ was designed for the limitations of the public p2p channels of Bitcoin. However, you just re-reminded me that without a "true" mixnet, Dandelion++ over i2p/tor isn't a dumb idea either. A "global-passive adversary" could theoretically track down the tx origin with just i2p/tor + white noise. Its not "dead-simple" but plausible.
65e8a89 Change monerod --proxy to --tx-proxy (vtnerd)
3 participants
No description provided.