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++?

1 Like

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.


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.

1 Like

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.


1.2.8beta… It’s great that Grin++ is getting more and more user friendly. The addition of Tor bridges via the GUI is an improvement in the right direction.

Now about my experience. I’m in a country with heavy censorship and aggressive blocking of everything. Previously, I tried to work through obfs4 bridges, adding them manually to the torcc file. It sometimes worked, but most of the time it didn’t, and finding a working bridge is an art. Out of 100 attempts, one is successful, and I’m not exaggerating.

Now I have experienced adding snowflake bridges. In the GUI, all you have to do is move a switch and the torcc file is automatically updated. Unfortunately in my country I am not getting any improvement compared obfs4 bridges. The address is still not green.

I do similar tests separately in the Tor browser. Snowflake also usually doesn’t work there, and when it accidentally works, the exit to the browser’s working mode is very very slow, it takes minutes of waiting.

As a result, in the Tor browser, I found the optimum for my situation. Tor Browser now always works and gets up and running quickly, in less than 5 seconds. This is the Tor over vpn method. https://www.reddit.com/r/TOR/wiki/…

Here is my working recipe. I’m running Shadowsocks app
and in the Tor browser in the settings I choose
‘I use a proxy to connect to the Internet’, SOCKS5, Address:, Port: 1080.
No bridges, and everything works quickly and without problems.

It was previously proposed to use the Socks5 method in Grin++ by adding the entry
to the torcc file.
I have repeatedly tried to replicate this by running the Shadowsocks app, but it has never worked for me. Does this solution really work? Why does Tor browser work easily and always over Socks5, but Grin++ never works over Socks5 for me?


Thanks for sharing your experience, it is very helpful. I will check the links you have shared. From Grin++ v1.2.8 it should work as Tor Browser but I haven’t tested all cases as I don’t live in a country with much censorship. I will try Shadowsocks and SOCKS5, again t should work but I will test it and make sure it works for your case.


I figured out my strange problem. Now everything works great for me.

I managed to observe the absence of a green grin address with a running proxy on two different computers. In both cases, the problem was solved by reset the network cache.

On Command Prompt screen, type the following Commands one-by-one and hit the enter key after each command.

  1. ipconfig /flushdns
  2. netsh int ip reset
  3. netsh winsock reset

After executing above Commands, Restart your computer.

1 Like