VPNs that accept Grin as payment?

It should not be possible, and that is why coinswap is so promising. But cross input aggregation does not happen today. Coinswap is not available today, and many community members here are even reticent to implement or even enable it by default. We will see if coinswap ever gets adopted.

From my point of view we need some kind of Timel-locked Transactions for this, let’s say users are paying for time of using Services running on top of GRIN, Fog Computing is good example. Micropayments are needed for this.

1 Like

This post explains how to de-aggregate transactions:

basically by running many nodes to intercept transactions before dandelion merges them. Aggregation on the block level is simple, just store what is in the mempool, not the aggregated transaction you find in a block.
What you get from all the effort to de-aggregate is at best that you can link outputs to tor address, without knowing the amounts or to whom they are send (unless you have a lot of relay nodes in the tor network perhaps). So not that interesting, still, this is something CoinSwap would fix.

1 Like

Ah thanks, I suppose I see how this is not 100% privacy but IMO metadata protection is what I really care about. Mixing / coinswap will improve privacy of course. Also from Tromps comment it seems as if this attack merely identifies a UTXO set but no metadata from them at all? I don’t understand how this could be used against someone or linked to a particular person.

if we create transaction A where you create utxo X then i know that X is yours. If i then see a new transaction where X is an input then i know that you were a part of that transaction (today that means you’re very likely sender in that transaction since wallets don’t support payjoins). You can imagine that an exchange knows quite a lot of such X’s. If the transaction would be payjoined they might even be able to identify both parties. But yeah, that’s as far as they can go, they can’t know the amounts (theoretically in some rare cases they can predict upper limit of the amount, but that’s only if they can match all inputs to some mining rewards or smth similar).

1 Like

but then if i create another UTXO afterward, it could be to me or someone else, you would not know correct?

yes, i only know that you’ve spent it, not which new utxos are yours (unless the person who was a part of this second transaction tells me).

In my opinion this is quite robust privacy if you are capable of avoiding KYC exchanges and stuff, VPS funded w grins could improve overall privacy with any kind of tor or ip based linkage, and atomic swaps and coin joins would be what would fully transition it into full privacy.

(of course we still have a user defined level of privacy which is ok I think because even in Monero people can be tracked by using similar KYC enabled stuff and using their real ip or not using tor and stuff.)


This should, become real. Keep this idea going.


I found this article which is suitable for low-medium tech guys to start a small VPN business at low cost. The difficult part is marketing and integrating Grin payment for users.

1 Like

I will be your frist customer. Have grin. Need VPN.

Launch your own VPN is easy, you just need barebone servers, to handle enough clients.

1 Like

You said you are Rust dev, take a look at:

Let’s collaborate to do things.


Best to make this a combined effort👍. Perhaps this email plugin for grin transactions is not ideal for a webshop, but for requesting VPN access, it should work fine. Just send an email with slatepack to pay XXX Grin, get return slate, finalize after which you get an email with access account and code and login instruction send to your email. VoilaVPN paid by Grin using slatepacks over email.

Perhaps advice to only use proton email address for sending and receiving VPN access (use proton bridge on VPN side to link to script), for added privacy although slates are also encrypted if the sender enters the receives address.


This is interesting. Is there any architectural description anywhere? The repo itself is small, but makes no mention of how the P2P network is expected to behave.

I don’t have a lot of extra time, but I would certainly help such a project, if I could understand a bit more about its design