Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bypass the need for multiple mixing rounds #21

Closed
nopara73 opened this Issue Aug 9, 2017 · 6 comments

Comments

Projects
None yet
1 participant
@nopara73
Copy link
Owner

nopara73 commented Aug 9, 2017

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 nopara73 changed the title Bypass the need for multiple mixing round Bypass the need for multiple mixing rounds Aug 9, 2017

@nopara73

This comment has been minimized.

Copy link
Owner Author

nopara73 commented Aug 9, 2017

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.

Chaumian CoinJoin

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

This comment has been minimized.

Copy link
Owner Author

nopara73 commented Aug 9, 2017

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

This comment has been minimized.

Copy link
Owner Author

nopara73 commented Aug 9, 2017

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

This comment has been minimized.

Copy link
Owner Author

nopara73 commented Aug 9, 2017

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 comment has been minimized.

Copy link
Owner Author

nopara73 commented Aug 9, 2017

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

This comment has been minimized.

Copy link
Owner Author

nopara73 commented Aug 14, 2017

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

@nopara73 nopara73 closed this Aug 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.