nopara73/ZeroLink

Reusing unprovided output

anwfr opened this issue · 7 comments

anwfr commented

I was wondering about the following scenario, if banning unprovided outputs is not implemented:

  • Alice registers inputs on a first round, but doesn't provide the output
  • A new round starts
  • Alice provides unblinded output(s) from previous round(s)

Would this enable her to disturb the round? (more outputs than expected)
Even maybe to steal money by getting her output instead of someone's else in transaction? (of course client should verify tx output before signing it...)

If so, blame protocol for banning unprovided outputs is a MUST.

Best regards

nopara73 commented

This is bad. I did not think about. Stealing of course cannot happen, because if an Alice doesn't see its output in the coinjoin, it won't sign (and unsigned Alice gets banned, this is actually the hidden blame protocol). But a new type of disruption is now possible. I'll spend all my time on this, until it gets addressed.

nopara73 commented

Here's the fix. I'm going to add the following lines to the specification under DoS Attack section.

DoS 4: What if Bob provides a signed output in the wrong round?

If Bob refuses to provide an output in the round it acquired its signature, then the corresponding Alice gets banned in Signing phase, because she will not provide signature to the CoinJoin.
However Bob's output will never be unblinded, therefore at OutputRegistration phase the Tumbler does not know if the output had been signed in the current or in some previous round.
In order to disrupt the round Alice can keep acquiring signatures (in expense for her utxos to get banned) and providing outputs to incorrect rounds.
For privacy reasons the Tumbler MUST refuse the same blinded signature to be registered twice in Input Registration phase and the Tumbler MUST refuse the same active output to be registered twice in Output Registration phase. This may already makes it uneconomical to keep this attack up for too long, but ZeroLink introduces an extension to the Chaumian CoinJoin protocol to completely defend against this attack:

  1. At Connection Confirmation phase, for Alice's connection confirmation request, the Tumbler answers with a hash of all inputs, called roundHash.
  2. At Output Registration phase this roundHash must be provided to the Tumbler by Bob.
  3. At Signing phase, when Alice acquires the CoinJoin, she must check if the roundHash is indeed the hash of all inputs.

The question arises, why not use a random round identifier, instead of roundHash? It is because the Tumbler could trick Alices into providing them different round identifiers and with that information deanonymizing the round.

nopara73 commented

Maybe I can keep this open until you ack the fix.

anwfr commented

Thanks for the fix! Looks good ;)

nopara73 commented

Me thanks. For the record I already implemented it. WalletWasabi/WalletWasabi@8d4c682

anwfr commented

Sure! Thx :)