I thought by contribute you meant provide. Now I see you meant add.
The adding of user-provided random excessses is the mechanism by which to randomly permute the self-spends at each stage, to obfuscate the i/o links to anything less than a full mixnode collusion.
Yes, you’re wrong. Mixnode 1 doesn’t know what input corresponds to what output.
Each mixnode randomly permutes the i/o links using data only available to them.
Thanks again for helping me understand. After reading your answers, discussions with @phyro and @vegycslol on Keybase, and re-reading the proposal, I think I finally understand how it works.
I was confused thinking that the mixnodes provided their own random excesses, instead of the user computing them as shares of the final/total excess.
Was also forgetting the part where other mixnodes’ shares are wrapped in onion bundles, hiding them from mixnode 1.
Still have a couple nits about some practical issues in the protocol, mostly about fragility and timelines. Will keep thinking about solutions to those problems.
Thanks for your work on this proposal @tromp
Has there been any progress on this?
Afaik, the proposal is ready to be challenged so we can fix any flaws we find.
Could you please make a list of the drawbacks of implementing coinswap ?
and also , How will Grin privacy compare to monero with coinswap ?
and finally , will it get implemented for real or is it just an idea that will never be implemented like privacy for bitcoin ?
Requires finding reputable parties. enjoying widespread trust in Grin community, willing to run the mixnodes. Perhaps even multiple sets that users can select from through wallet configuration.
If implemented and enabled by default in most wallets, and having at least a few dozen genuine tx mixed per day, then the privacy is comparable to Monero.
It’s too good not to get implemented. But with current lack of developers, it will take time.
Is there already a bounty for developing a CoinSwap mix node? If not, why not put a bounty on it, who knows a developer might bite.
There is nothing to lose with putting a bounty on as far as I can see.
thanks. Does it mean that when one sends a tx , it won’t be confirmed for several hours potentially (compared to now) , waiting the coinswap to occur ?
Before implementing it some famous cryptographers would need to verify it works as expected, i think a bounty for that might be better unless someone can get someone to do it for free
Obviously, a daily mixer could induce waiting periods up to a day, while an hourly mixer (which only makes sense if a daily mixer gets lots of traffic) would limit that to an hour.
But if a wallet cannot wait, it can just go ahead and double spend outputs sent to be swapped. the coinswap will automatically filter those out.
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.
I’d like to mention that there’s a way to blind the coinswap mixnodes as well if people really wanted to. Alice and Bob can produce two 1-1 coinswaps with the same value whose ending outputs are multisig outputs that start the “fund” for each party. The mixnodes even when colluding will think they know the graph links, but the next transaction can be Alice claiming the output from Bob’s multi-output produces which makes Bob learn the secret to Alice’s multi-output. This is basically a bitcoin like coinswap with only 2 kernels because the funding transactions come for free from the coinswap transaction.
To produce a multi-output, given N mixnodes, Alice picks the shares for mixnodes at odd position and encrypts them while Bob picks the even positioned shares. Not sure the relative refund txs can be done though due to a lack of kernel, perhaps only height locked refund txs.