And my post to which you are replying is in fact explaining the DOS (denial-of-service) is insoluble if you can't identify the participants in order to rate-limit them.
And again in that post you admit there is a DOS problem. You didn't solve it. And you can't solve it in a decentralized setting unless you have non-ephemeral identification of the participants. Which is precisely the point of my prior post to which you are replying
You are asserting it, (over and over again) but it doesn't make it true. It was explained in adequate detail previously enough for other people to understand it and implement tools that address it.And again in that post you admit there is a DOS problem. You didn't solve it. And you can't solve it in a decentralized setting unless you have non-ephemeral identification of the participants. Which is precisely the point of my prior post to which you are replying
Quote
Incorrect. What I wrote is functionally equivalent to what you described. The point is the transaction can be jammed in the final round.
It's actually not, since it's not actually possible in the Bitcoin protocol to do what (it sounds like) you're describing, but more importantly performing the operation in that order defeats the anti-dos. If you lead with the inputs they provide a trivial anti-dos mechanism.Quote
And exactly how do you propose to identify that adversary in a decentralized setting? 
My point is you can't, at least not without breaking anonymity, and anonymity was the entire point of mixing.
Because they fail to sign. There is no need to identify them beyond identifying their input coins to achieve rate limiting, and no need to identify the input/output correspondence. My point is you can't, at least not without breaking anonymity, and anonymity was the entire point of mixing.I'll repeat it, since maybe other people are having problems following the link:
An example (using the blind signature approach, simplified for equal values) is that each participant cryptographically blinds their desired output, and then signs their blinded output using the keys from their intended inputs. They then present to the group their inputs (and assuming those inputs are not black-listed) everyone in the group blind-signs each of the outputs. Then everyone connects again with new connections (e.g. a new circuit in tor) and presents their unblinded outputs and their signatures. Now everyone knows that all of the provided outputs were from authorized parties but not the correspondence. The transaction is composed and back on their original connections they all sign. If someone doesn't sign, it means they're jamming the process, everyone blacklists theirs inputs and automatically restarts. The network naturally rate limits them via the finite supply of available outputs. (of course, if you want you can attack other valuable identities to the first step, like coin burning or what have you, if the natural network rate limit isn't enough).
This is just one example of a way to address this. There are several other ones possible and discussed early on in this thread. Other ones include publishing commitments and then if the process fails having everyone reveal their intended outputs (which they then discard and never use) in order to avoid being banned, or using an anonymous accumulator instead of blind signing to control access.