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.

4 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.

6 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
6

why only onion and Nostr ?
why not even i2p and SimpleX ?

long term grin need to be a non interactive coin and function like Monero
or better than that

7

Just because we do not have devs, not have human power…etc…

8

we will in future

grin just has to innovate more on privacy tech

and market will play out fine.

and grassroots adoption will increase.

9

Could veilid be used? Its written in rust, so it fits in with grin well. I see it sort of like nostr mixed with tor.

Veilid / veilid · GitLab. From its description:

From Orbit

The first matter to address is the question “What is Veilid?” The highest-level description is that Veilid is a peer-to-peer network for easily sharing various kinds of data.

Veilid is designed with a social dimension in mind, so that each user can have their personal content stored on the network, but also can share that content with other people of their choosing, or with the entire world if they want.

The primary purpose of the Veilid network is to provide the infrastructure for a specific kind of shared data: social media in various forms. That includes light-weight content such as Twitter’s tweets or Mastodon’s toots, medium-weight content like images and songs, and heavy-weight content like videos. Meta-content such as personal feeds, replies, private messages, and so forth are also intended to run atop Veilid.

this slide pack from defcon give good info too: https://veilid.com/Launch-Slides-Veilid.pdf

1 Like
10

@phraudsta they say its rust tor+ipfs like so maybe

1 Like
11

Slatepacks can be sent with any messaging app/protocol. You can send them in WhatsApp, Apple Messages, Signal, etc.

The reason that people like Nostr is because

  1. The protocol is very simple and lightweight so adding it to a wallet is not so difficult

  2. There are many open source apps that can be forked and customized to have Grin specific functionality (like rendering slatepacks in a nice way)

  3. The protocol is open and agnostic to any specific monetary system or economic incentive

  4. User IDs are just 32 byte hex keys. Very open and easy to make and manage them with existing tools

1 Like
12

@trab yea Onion and Nostr grin client is all well and good
is their any specific problem with i2p(java) and SimpleX(flutter) or their future rust client (maybe)

13

Tor and i2p are about network privacy. That doesn’t matter at all afaik.

Slatepacks are just text like you and I are writing right now. Anything you can send text in, you can send slatepacks in.

If SimpleX could add an extension that automatically detects a slatepack in their messages and makes them visually pretty, awesome. But even if they don’t, you can send slatepacks there just fine.

14

Flutter is just for UI. To communicate inside we need to use SMP protocol API, client is in Haskell (https://github.com/simplex-chat/simplexmq/blob/stable/src/Simplex/Messaging/Client.hs)

It can be good idea to use it optionally for slatepacks communication, so user will have choice:

  • Online: use http(s) (not private) or Tor,
  • Offline: async slatepacks communication through Nostr, SMP and so on… we can actually integrate any messaging protocol to send slatepacks, 2nd wallet just need to support it to receive.

The only problem here is fragmentation of wallets with support of different protocol/addresses, if only we will have some kind of Naming System to unify tx sending/receiving mechanism for this, it can solve a lot problems for adoption. To avoid storing additional information on the blockchain it can be some separate optional P2P service near the node for users who want to enjoy GNS (Grin Naming System) :slight_smile: .

1 Like
15

@ardocrat cool idea but instead of name system, bech32 or bech32m encoded hexadecimal address is also fine.

or one can do both and let market decide.

16

What would this be for? I’m unclear on what the problem is, so I don’t understand why such a solution would be needed

17

Problem is every protocol requires separate address.

18

there was a small discussion quite some time ago of address containing your transport information, but that would require quite a lot of changes to messaging.

19

Yes, a discussion on disconnecting the transport protocol from the slate itself if I remember correct. Like a json that functions like a wrapper and smart script, first try method A, if offline, try method B, etc. I think it still could be interesting to further explore these thoughts but I remember that one problem is that we simply do not want to put to much information in an address.
However, if we would not put the information in the address but more like a wrapper around the slate-pack address with this information and a sender can scan it from a QR code, it would be much more feasible to put such extra information.

20

honestly i would probably have a “contact card” message, which would contain transport info alongside with some ID (to know who’s spamming you → not relevant today, but likely needed when evil people join), user could “add contact” and select default transport for this contact or smth. It’s a big rework and there are other more important things to solve first though.

1 Like