Walletwasabi: Possible denial-of-service attack

[onvej-sl]

I think I found a vulnerability in the implementation of the coordinator. I'm not one hundred percent sure because I didn't test it. An attacker can exploit the vulnerability to perform a denial-of-service attack such that the current coordinator doesn't ban the attacker. Nevertheless, the attacker must posses around 10 BTC (on average) to mount the attack and the attacker may be identified (and the registered coins banned) by a retrospective analysis.

Assume that in the end of the input confirmation phase, there is a level such that there are just two Bobs (Bob1 and Bob2) participating in it and these two Bobs are controlled by the attacker. This is why the attacker needs a lot of coins because both corresponding Alices must register enough coins to participate in such a level that nobody else participates in it.

In the output registration phase, Bob1 registers his output, whereas Bob2 doesn't. In the signing phase, the coordinator builds the coinjoin transaction:

• He adds output for every Bob except for
  
  
  
  • the Bob2's output, since it wasn't registered and
  
  
  • the Bob1's output, since there are not engouh Bobs on this level.
  
  
• He adds his own output instead of the Bob2's one.
• He adds change outputs for all Alices. The change amount of an Alice should be the sum of her inputs minus the sum of the denominations of all the levels she participate in minus the fees. However, the change amount of the Alice corresponding to the Bob2 is not computed correctly. The coordinator believes that there are not enough Bobs on the last level and doesn't decrease the sum of the inputs of the corresponding Alice by the denomination of the level.

That means, that (not counting the transaction fee) the sum of the outputs of the final transaction is greater that the sum of its inputs and the difference is the denomination of the last level, and the transaction is not valid.

I didn't investigated the consequences, but the following may happens:
1) The coordinator is smart enough to realise that the transaction is not valid and throws an exception or returns an empty transaction serialisation. The attacker successfully performed a denial-of-service attack.
2) The wallet is smart enough to realise that the transaction is not valid and refuses to sign it. An attacker signs the transaction since there is no harm in signing an invalid transaction. All other participants are banned since they didn't sign the transaction. The attacker successfully performed even better denial-of-service attack since all other participants are banned.
3) All the participants (including the attacker) sign the transaction, the transaction is broadcasted but refused. The attacker successfully performed a denial-of-service attack.

I guess the case 3 occurs.

[nopara73]

Thank you! The fix is on its way. Would you mind sending me another Bitcoin address in private so we can reward you for finding this bug?