Skip to content
This repository has been archived by the owner on May 19, 2020. It is now read-only.

Note on JM-style-CJ roles #5

Closed
AdamISZ opened this issue Jul 31, 2017 · 1 comment
Closed

Note on JM-style-CJ roles #5

AdamISZ opened this issue Jul 31, 2017 · 1 comment

Comments

@AdamISZ
Copy link

AdamISZ commented Jul 31, 2017

On this:

This of course gets expensive quickly as the anonymity set grows and it rather achieves plausability, than unlinkability,

I suspect you meant 'plausible deniability rather than unlinkability'. I think that's a little strong if you use the tumbler algorithm (in the sense that it does quite a bit more in terms of defence against timing and amount correlation, and uses a network of txs), but no big deal. It's more than fair as a description of a single JM style CJ, though.

because how the makers use their coins after the mix will noticeably differ from the takers' behaviour.

This is true and IMV one of the most important critiques of the JM approach, but note that roles are not fixed; a typical Maker will often spend coins as a Taker now and then, and there are more complex algorithms: the patientsendpayment operates as a Maker for a while until a timeout then switches to Taker. Additionally, even in a completely partitioned Maker-Taker set, using the tumbler algorithm (somewhat similar to the 'switching network' concept described above), in the presence of many simultaneous Takers it gets much harder to make an input-output mapping for a particular Taker. More detailed notes on potential weakness of tumbler here.

@nopara73
Copy link
Owner

nopara73 commented Aug 1, 2017

I made some modifications, based on your suggestions: 661de40

Please reopen the issue if it is still incorrect.

@nopara73 nopara73 closed this as completed Aug 1, 2017
SamouraiDev added a commit to SamouraiDev/AnonWork that referenced this issue Aug 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants