Quote from: anonymixer on Today at 03:40:04 PM

Quote from: suchmoon on Today at 03:25:23 PM

Ok, I take your word for it here on tracking the UTXOs but the second part kinda contradicts your OP where you said the mixer would be a maker. Are you going to run takers too, or just produce a client and expect others to run it?

The Maker and Taker code would be written from scratch. However, still interfacing and communicating with same IRC channels as the regular JoinMarket Python software. Transactions produced would still appear as if they had been produced from the Python software. I would not be running on an entirely different network, but the internals and decision making in terms of which UTXOs were selected and which Output Addresses I chose would be up to my own software.

But you would be running makers AND takers?

Quote from: anonymixer on Today at 03:40:04 PM

Strictly speaking, 1 CoinJoin away, I think you're definitely right. Sorry for that, but at what point does this change? I am not sure this is "absolute" as it dilutes to some extent with time?

If you sent Coins to an Entity which then performed 20 CoinJoins in a row over time (each CJ with other JM parties, each time). If you received Coins back from that later, 20 CoinJoins down the line, are these still "Your Coins"?

As I said earlier, I don't think that TX graph is a big JM issue to begin with... plausible deniability is good enough for me, especially by the time it gets to depth 4, let alone if it has been circling there for months. I'm just picking on your claim that the advantage of this service (over using JM directly) is that would break the TX graph, which it doesn't really do, or at least doesn't do it any better. And it could make input commingling a bigger problem. If I'm not mistaken the default maker tries to avoid co-spending my own inputs at all depths. If I send coins to your mixer there's probably a higher a chance my coins could be spent together as early as the next CoinJoin after the initial one.