Mimblewimble CoinSwap proposal

Development and Technical Discussion
40

This paper contains a nice summary of privacy techniques that can be used on Bitcoin and their tradeoffs

I think the entries for Mimblewimble CoinSwap would be something like this

Anonymity set                    | Large
Unlinkability                    | ✓ (User generates new commitment for each coinswap)
Untraceability                   | ✓ (If CoinParty has untraceability point, we should as well since it is a similar model)
Value privacy                    | ✓ (CT)
Theft resistance                 | ✓ (Impossible to steal value. Undo attack gives it back to the same user)
DoS resistance                   | ✓ (Malicious users cannot DoS through invalid coinswaps because we can
                                      filter out the invalid ones - they consider centralized services DoS resistant as
                                      none of the participants can abort the protocol and affect others).
Sybil resistance                 | ✓ (Every coinswap costs X fees and MWixnet waits for N hours before
                                      running the protocol so everyone can participate)
No interaction with input users  | ✓
No interaction with recipient    | ✓ (self-interaction)
BTC Compatible                   | X
Direct send to recipient         | ✓
no. Trx                          | 1
Min Block                        | 1

I’d also add something that is important in case of reorgs when we have transactions with big anonymity sets.

Reorg friendly | ✓

Reorg friendly means that given a transaction with 1000 inputs and 1000 outputs where one of the inputs was double-spent in a reorg, we would be able to replay the coinswap rounds and reconstruct a new coinswap shuffle transaction with 999 inputs and 999 outputs. This prevents future graph collapsing due to transactions using commitments that no longer exist and localize the issue to the subgraph going from the double-spent commitment forward.

5 Likes