One of the possible Grin paths

1

I wanted to summarize some options I see for the future of Grin and hopefully hear your agreements/disagreements on this.

As some of you have already noticed, there has been some new research done around privacy which proposes a way to do Coinswaps on Mimblewimble. We sometimes refer to this research as MWixnet because it is similar to mixnets. In case no critical flaw is found, this may open some interesting options that I’m going to discuss below.

Let’s assume that every wallet sends newly received outputs that did not come from the coinswap service to the Daily Coinswap service and that at least one node in the MWixnet is honest so we are getting an aggregate coinswap transaction that is obfuscated.

Privacy as a rolling window

Every single non-mixed output will stay unmixed for a maximum of 1 day from the point it was received. In the simplest case of just receiving an output O1 for which the sender knows belong to me, the wallet will behind the scenes send O1 → P1 to the coinswap service and produce this new output in roughly 24 hours. If I decide to spend O1 before it is coinswapped and I produce a new change output O2 then this one will also get sent to the coinswap service. Both O1 and O2 will be in the Coinswap service. This means that they will also have the same time until the coinswap happens, so we can say that every unmixed output produced should become private in ~24 hours along with the chain it formed onwards (there may actually be some edge cases, but this should be true for the most part).

Let’s call the outputs that have been mixed in the coinswap service private outputs because they are “unknown” to the observers.

Wallet rules:

  1. When sending money, use private outputs if possible
  2. After every received output that is not a private output (we could label these perhaps), create a coinswap and send it to the coinswap service

These two rules should give a fair amount of privacy.

Payjoins for scaling

First, a short intro to payjoin transactions. If the receiver contributes an input, then we have both parties adding an input and we call such transaction a payjoin. Payjoin does the following:

  1. Obfuscates the direction of money flow - Any of the two inputs could be the sender so they boost privacy of the sender
  2. Shows one receiver’s input - the receiver’s privacy leaks a bit because they need to contribute an input so it shows some link
  3. Doesn’t increase the UTXO set size - a transaction that has at least as many inputs as outputs doesn’t increase the UTXO set size.

I want to emphasize the point 3. because this is what we will be going after next.

Our wallet now has a pool of “private outputs”. Let’s add the following wallet rule:

  • Add a ‘private output’ to a receiving transaction if possible

If all the wallets follow this, then all the transactions are payjoins because the receiver will add a private input. But let’s analyze the payjoin points again in this new setting:

  1. Obfuscate the direction of the money flow - it still obfuscates the money flow, but if both parties use a private output as inputs, then there is not much privacy gain
  2. Show a receiver’s input - there is no leak if the input the receiver contributed came from the coinswap service
  3. They don’t increase the UTXO set size - this is still true

This means that if every transaction is a payjoin, then given that receivers contribute private outputs, we don’t leak any privacy while still benefiting from the scaling that payjoins come with!

The downside I see is a very small fee the user needs to pay for the additional input, but this is worth it for the network as a whole. It’s fair to say that there may be some other downsides to this that I don’t know yet. Please share if you happen to think of any.

Important notes

  1. We should make it clear that private outputs are from the coinswap and the privacy comes under the assumptions of the coinswap service.
  2. It would need to be researched a bit deeper than what is done in this post.
4 Likes
2

whatever you do,dont put a name coinswap mixnet,coinjoin etc to attract eyes. put somethng cammouflage)
there is privacy allergy for institutions.
thnx for work!

3

i completely agree that it seems like the default payjoins + default coinswap have great synergy, both in privacy and scalability.

4

If mixnodes pay themselves a fee as a payjoin, and thread all these together, then to replay a tx with a coinswapped input would require replaying lots of coinswap history and all payjoin ancestry. This would severaly reduce the need for anchors.

1 Like
5

I think that even without that it should be close to impossible to replay a tx with coinswapped output because you would need to replay each input of that aggregated tx (and to replay them you need to recursively replay their inputs etc)

6

Demiguise if you want to use something from the Potterverse.

2 Likes
7

Is this similar to the “Improvements” section here Replay resistance through payjoins and aggregators ?

Edit: Am I understanding it right that what you’re suggesting is equivalent to every mixnode contributing a coinswap of its own?

8

Yes; I’d forgotten about that thread:-)

A payjoin for very mixnode is possible, and gives the strongest threading.
Alternatively, they could take the fees with one payjoin in round robin fashion. That is less fair though if the volume varies a lot from day to day…