You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 19, 2020. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
On this:
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.
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.The text was updated successfully, but these errors were encountered: