Tor integration in the Dotsama ecosystem
This is a post covering Tor(onion-routing) integration in the Dotsama ecosystem. A problem that is often faced is that several client libraries used to connect to rpc/ws nodes does not support socks5 proxies. In order to allow people to connect a .onion node, the connection must first be tunneled through a Tor proxy. An RFP was recently created in web3 foundations grant program in order to motivate developers to work on enabling socks5 support in the popular rust library JsonRpsee.
As of writing this, Tor integration has not been a big focus area in the dotsama community. Because of lack of socks5 support in several client libraries, it makes it hard for end users to utilize connected
An RFP created to motivate developers to work on socks5 integration for JsonRpsee.
Tor is a anonymization project that has been active for several years. By utilizing a traffic obfuscation protocol to route data, it enables users to anonymize their internet traffic. Several blockchain projects leverage this technology to allow users to connect to nodes over tor, inputting the .onion address of the rpc provider.**
By providing a .onion address for a rpc/ws node, we can allow users to have more privacy by masking the origination of the request (the sender’s ip address).**
In february 2023, a small public rpc provider was launched in order to provide .onion rpc endpoints for a handful of chains in the ecosystem.**Privhost was later listed on the awesome-substrate list.**
In order to connect to a .onion site, a user must pass it’s connection through a tor socks5 proxy in order to resolve the .onion domain and connect.**
Several ecosystem projects want to add support for connecting to .onion, but are blocked due to JsonRpsee not having support for sock5 proxy.**
Third party pr’s that are waiting for JsonRpsee to support socks5:**
On 4th of September of 2022 a pr was created **to start the process of adding socks5 support for JsonRpsee.Noone has had time to fix this issue and implement this feature, therefore this RFP has been drafted.
Bitcoin Core (bitcoind) began supporting Tor (The Onion Router) for network communication in version 0.7.0, which was released on *April 19, 2012*. Tor support allows Bitcoin users to route their network traffic through the Tor network to enhance their privacy and anonymity when using Bitcoin.
Since that initial implementation, Tor support has been improved and integrated into subsequent Bitcoin Core releases, making it easier for users to run a Bitcoin node while maintaining a higher level of privacy. It’s important to note that using Tor with Bitcoin can help obfuscate the user’s IP address but may require some additional configuration and knowledge to use effectively.
I am a RPC provider and want to give my users more privacy, how can I provide .onion domains for my RPC nodes?
If you are running public ws nodes, you should consider offering .onion addresses as well, it’s normally no extra costs involved except for increased bandwidth(if your ISP charges you based on bandwidth load)
How to generate a .onion:
Install tor on your server, use an up to date version(for debian: https://support.torproject.org/apt/tor-deb-repo/).
Add the following in the` /etc/tor/torrc` configuration file:
HiddenServiceDir /var/lib/tor/wsnode/ # set directory
HiddenServicePort 9944 127.0.0.1:9944
Restart the tor daemon and view the hostname file in the “/var/lib/tor/wsnode” folder.
Rate limiting can not be done by blocking a certain ip after a certain amount of request, since all source ip’s will come from 127.0.0.1, in order to implement ddos protection, see the following guidelines put out by the Tor project:
I(flipchan) reached out to the Tor core developers and was told that “HiddenServiceExportCircuitID” is the silver bullet for enabling rate limiting.
Feel free to reach out directly to Privhost
Are you a Rust developer looking for a new fun project? Then this might be for you!