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.
- When sending money, use private outputs if possible
- 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:
- Obfuscates the direction of money flow - Any of the two inputs could be the sender so they boost privacy of the sender
- Shows one receiver’s input - the receiver’s privacy leaks a bit because they need to contribute an input so it shows some link
- 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:
- 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
- Show a receiver’s input - there is no leak if the input the receiver contributed came from the coinswap service
- 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.
- We should make it clear that private outputs are from the coinswap and the privacy comes under the assumptions of the coinswap service.
- It would need to be researched a bit deeper than what is done in this post.