Bypass the need for multiple mixing rounds

[nopara73]

Right now if the fixed denomination is 1btc and the user wants to mix 3btc, it must participate in 3 mixing rounds. However it could potentially register 3btc input and then register 3 times 1btc outputs. With this it can mix cheaper, because it only participates in one round.

This topic should be further explored.

[nopara73]

The updated 'Simplified Protocol' section would look like this:

A. Simplified Protocol

Alice and Bob are the same user, however the Tumbler does not know this.
Bob1, Bob2, Bob... may be the same user, however the Tumbler does not know this.

1. Input Registration Phase

Many Alices register their

• confirmed utxos as the inputs of the CoinJoin,
• proofs, those are messages signed with the corresponding private keys,
• their desired change outputs,
• and blinded outputs to the Tumbler.

Tumbler checks if inputs have enough coins, are unspent, confirmed, were not registered twice and that the provided proofs are valid, then signs the blinded outputs.
Alices unblind their signed and blinded outputs.

2. Output Registration Phase

Bobs register their signed outputs to the Tumbler.

3. Signing Phase

Tumbler builds the unsigned CoinJoin transaction and gives it to Alices for signing.
When all the Alices signed arrive, the Tumbler combines the signatures and propagates the CoinJoin on the network.

[nopara73]

It also comes with some implementation difficulties, because all Bob outputs must be registered within 1 minute. Therefore the change between a user's Bob identities must be fast, since multiple Bob identities per user wer introduced. (Tor circuit changes.)

[nopara73]

DoS protection still works as it has to, because the user can pre-divide its coins, neverthless if it wants to disrupt more than one round.

[nopara73]

Because of the aformentioned implementation difficulties it might be possible at output registration phase we start getting close to the 1 minute timeout, and this would slow down the that phase from a few second to close to minute.

[nopara73]

This would also make deanonymization somehow easier, because there'd be less distinct participant in a mix.
I think this should be only introduced when some massive liquidity/anonimity set is already achieved, so deanonymization is less of a concern or if Bitcoin fees go really high that implementing this becomes unavoidable.

[nopara73]

It was referenced from the document, the issue can be closed.