Obfs4 and Meek methods in Grin++

I have a Tor connection problem (Russia). Respectively Grin++ does not work for receiving coins at the address.

Even the obfs4 method doesn’t work. To check, I launched the Tor browser. It doesn’t work with default settings. There is also no success when getting obfs4, tried to get new ones repeatedly. Apparently, they are being quickly blocked. Only meek and snowflake methods work.

Back to Grin++. There is only obfs4 method instruction for Grin++
But I need Meek method. Or snowflake.

Downloading meek-client:
I place the exe file in %userprofile%/.GrinPP/MAINNET/TOR. In the same place I make torrc file (file name, no extension).

What to write in torrc file? Let’s write so:

ClientTransportPlugin meek exec meek-client
UseBridges 1
Bridge meek url=https://az668014.vo.msecnd.net/front=officeimg.vo.msecnd.net

But it doesn’t work that way. Tried different addresses.
How to make the meek method work correctly in Grin++?

Most likely the problem is not the obfuscation protocol itself (obfs4, meek etc) it is the bridge IP distribution.

The cheapest way for a censor to stop the obfuscation protocols is to harvest IP addresses that are publicly available, such as those provided by the tor project. Most likely that is why obfs4 is not working for you- your censor has knowledge of the bridge IPs you have tried to use by looking for them in the same places that you have and adding them to their blacklist.

One solution is to use a VPS with a clean IP address that works for you and run a private obfs4 bridge on that server and not share that IP address publicly with anyone. Then use that as your bridge IP address in tor config.

Otherwise your best option is to manually exchange the slatepack messages with your counterparty on a communication channel that works for you (XMPP, email, carrier pidgeon etc).


The Slatepack method naturally works flawlessly and I use it. However, I would like to use other possibilities as well. In particular, I have a little bit of stucked GRIN on a pool, receiving only the address. It is not critical for me to donate it to the pool, but there is a sporting interest in receiving them.

I did a check with another provider. In the Tor browser obs4proxy bridges work normally. I get new bridges because the built-in ones do not work by default (blocked). After that I try to apply these proven bridges in Grin++ but to no avail. I go back to the Tor browser, it works fine. Hence, new bridges are not blocked as quickly and should work in Grin++.

Perhaps us need to detail instructions for Grin++. The instructions contain several inaccuracies and inconsistencies that I saw, but maybe I’m doing something else wrong. This instruction was copied in different places without correction, which means it was only copied but not tested in operation.

  1. torrc is not an extension, but a filename without an extension.

  2. Slashes in the folder path should be reverse. This does not play a role in the problem, but it should be noted.

  3. It is unclear if the obfs4proxy client is built into Grin++ or you still need to manually add the exe file to the torrc folder. I added.

  4. Then I add the line to torrc
    ClientTransportPlugin obfs4 exec obfs4proxy

The Meek method did not work for me in Grin++, most likely due to the fact that I incorrectly defined the torcc file. How will be correct?

As I can see from practice on the Tor browser, the Meek and Snowflake methods are now working reliably. The obfs4proxy method works badly in real (China, Russia). For me: on one provider it does not work even with new bridges, on another provider it works only with new bridges (built-in ones are blocked). It is theoretically correct to start your own node with a clean ip, and it will work well, but for practice, such a solution is troublesome, especially since there are alternatives that are simpler for an user.

I love the idea of Snowflake and keep a couple of snowflake nodes running all the time. It needs detailed (practical, not theoretical) instructions on how to use Meek and Snowflake methods in Grin++.


Same problem encountered time to time. This makes me afraid of opening Grin++ because the address is always BROWN! I experienced all difficulties in setting up Tor bridges. It is so frustrated!

Edit: I just checked out https://github.com/GrinPlusPlus/GrinPlusPlus/issues/171 . And the last comment is really helpful. I have a stable Socks5 proxy. And Use the .torrc suggest there


I finally get my grin address green!

Please update Bypassing Internet Censorship to receive Grins via Grin++ | David Tavarez this page by adding Such easy configuration for people who have Socks5 proxy available. I did not know this approach before. Tor bridges approach is seriously blocked in some countries while Socks5 works very well. In addition, I also use Socks5 proxy to browse Google.com etc. And it is no extra cost.

1 Like

A few clarifications to the list in my earlier post.

= 1. In Windows, it is customary to name the sequence of characters before the dot by the file name, and the one after the dot is called the filename extension. That’s why using ‘.torrc’ as the file name was confusing for me at first.

= 3, 4. It was unclear if the obfs4proxy client is built into Grin++ or you still need to manually add the exe file to the folder. I had these doubts because for a long time I could not get the obfs4 method to work. As I later realized, the reason is that it is a very big problem to find working obfs4 bridges. So obfs4proxy client is built in and nothing need to manually add.

My experience remains the same. The obfs4 method works, but finding working obfs4 bridges is a very long journey, requiring big effort, considerable time, patience and iron nerves. It seems Snowflake method in Grin++ would be the best and it would work quickly without requiring many manual steps.

I’ve been testing several approaches for this lately. The next beta release will include the option of using snowflake as ClientTransportPlugin. I wonder if this should be the default behavior, I do not know yet.