Improving the privacy of Grin

1

I wanted to start this topic because for a while I had some concerns regarding some privacy aspects of Grin. I shortly discussed it on KeyBase and made it into a future request, but it might be good to discuss it with the wider community here.
The problem is that currently a public/external tor address is the same as your wallets slate-pack address, see here technical details. and this is potentially a bad thing . Not the case, only a .onion address linked to it is visible.

privacy concern regarding the current use of slate-pack addresses as external tor address directly.

My concern is two fold
a) By directly broadcasting a tor address as external tor address, anyone who scans the tor network can simply log and collect slate-pack address information. With this information public, it is easy to mark wallets with outputs especially when there is auto-receive enabled in the wallet, which is currently the case.
b) When a node goes offline, anyone who connects to enough nodes can detect this and store the IP and time information. An attacker who monitors the tor network and connects to enough nodes, can also map tor/slate-pack nodes that go offline.
by matching the time, an attacker can relatively easily map IP’s to slate-pack addresses which compromise the online ID of the wallet owner.

Possible solutions

  1. Add one extra level to tor, meaning you broadcast a random address and only when asked for the specific slatepack address, the wallet pretends to relay it. This only adds one extra step of decrypting incoming packages which is relatively cheap with a lot of privacy gain. At least it will not enable attack a), anyone from scanning for slate-pack addresses, and it will make b) slightly more difficult.
  2. Make it possible to run nodes via tor. Even if they would have some sort of permanent ID, as long as that would not involve an IP address, there is no significant privacy leak when nodes and wallets go offline at the same time.
  3. Optionally make some sort of tor decoy service, meaning when you shutdown your wallet. The tor address stays online longer or pretends to be online even when all packages are simply written to output 0.
  4. Suggestion by @davidtavarez use Nostr to solve all these issues

I hope that these concerns also make it a bit more clear why as community we funded the implementation of the option of generating a new slatepack address in Grin++ as well as why we are having so many discussion on whether auto-receiving of funds is good (good UX) or bad (anyone can send your wallet tainted coins).

Edit: According to @joltz, slatepack addresses are not broadcasted via tor (see discussion on Keybase). So this takes away 90% of my concerns. It is however still a privacy concern that nodes leak users IP address, which when combined with their time of going online and offline could be linked to a slapack address or transaction if sufficient data is collected. One easy way to mitigate this is by running your wallet and node continuously, good for the network and good for your privacy! So consider running a dedicated node and wallet on a Raspberry Pi (minimal 4 GB) for example.

2 Likes
2

I think the Grin should be agnostic about the medium used during the transaction building process. Tor seemed like a good way to simplify interactivity, but although it had been around for decades, it is showing no signs of being a reliable option when it came to circumventing censorship. Which is sad. Shadowsocks seems to be winning the fight against the Great Firewall. In short, an Encrypted Proxy seems to work just fine.

The latest I could read about Tor is that Tor is being rewritten using Rust, with the ultimate benefit that mechanisms could be introduced to increase speed, which is nice, but brings no clear benefit to Grin.

An Exchange or Mining Pool could develop its own infrastructure to properly implement Tor + Grin, but the end user should not have that responsibility.

There is also the legal issue concerning adding tor relays to the Tor network. It is clear that governments hold those who run exit nodes responsible for traffic. This discourages any enthusiast from running their own relay.

No one in their right mind would take the risk of going to jail for playing the activist. Or at least they shouldn’t.

What I’m getting at is that even if technically they could rewrite the code from scratch to make it perfect, there is still a layer that the Tor Project foundation will not be able to overcome: the legal layer.

In terms of privacy, my concern with Tor is that it would not be difficult to use OSINT to collect any grin1 address, determine the .onion url and call the check_version method constantly to collect behavioural information. One could easily correlate the times a wallet is listening with say, a transaction at some point in time, if one has enough data. This is very low hanging fruit, which makes me worry about it.

83 lines of code is too cheap.

It seems to me that Nostr:

  • By adding asynchronous transactions “solves” the interactivity problem"s You can create a note that expires in say 72 hours, giving enough space to the recipient to add his signature.

  • Removes from Grin the responsibility of maintaining the code. For me, excellent.

  • Increases privacy. Aside from the fact that the notes are encrypted, the transport medium is encrypted as well, making it extremely difficult to use metadata and determine what the packets are about.

  • Add much more flexibility.

  • There is no legal issues, as Nostr is a generic protocol. It would be very difficult for governments to attack Nostr.

  • Would allow users to use different relays depending on who they build a transaction with.

  • Nostr would solve the same problems that Tor solves in relation to Grin.

  • Easy to implement, it could run on any device.

  • Exchanges or pools could easily run their own relays.

  • One would not even have to run one’s own relays, one could use any public one or several at the same time.

I know Nostr is kind of “new”, that might be the downside, but by choosing Tor over Nostr we are not making us (wallets devs) any favor.

5 Likes
3

Nostr could be an interesting opt-in in my opinion. I do think we should see it as experimental for now, so not as default. It would not be wise to swap out torrent completely. Perhaps there are easier solution, like each time generating a new .onion address when going online?
The main privacy concern that remain is the IP leak of grin nodes, would be better to run them via tor or at least avoid them going online just before a transaction and going offline after a transaction.

4

I added something like that to Grin++, one can generate a new address automatically after receiving a transaction, or on demand.

Traffic could be redirected through Tor too, in theory. That could be something cool to test.

Tor is unreliable, that’s a fact, and I don’t see how that will be mitigated in the near future. IMO.

1 Like
5

Nostr + Grin is future.

1 Like