Re: MtGox database leak: why you should always mix your coins.
And here is our friendly Bitcoin csore developer...
Keep your ad hominem attacks out of it please. I asked kindly for technical comments.
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
Incorrect. What I wrote is functionally equivalent to what you described. The point is the transaction can be jammed in the final round.
Since you didn't see the equivalence let me explain it. I thought you were smart enough to deduce such things. I chose to let the signatures of inputs go in the second and final round and point to a transaction because I envisioned using ring signatures. And the transaction won't be valid (blockchain will reject it) if the inputs are less than the outputs, so my version is just as safe as yours. And the DOS problem is equivalent. Come on you are a math guy, you can surely see that without me needing to explain it you.
And if you think about it a while you will realize, by inverting the operations and using a ring signature, mine has advantages suchas that not all have to sign in the first round before proceeding to the second round (they get excluded from second round too). Yet the DOS issue remains in the final.
Well now you see your error. You can reread my post again, and admit I was correct.
From your upthread post:
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.
AnonMint, Every post you've made here has been error and confusion.
Keep your ad hominem attacks out of it please. I asked kindly for technical comments.
The very first post in the thread points out that decentralized versions take more work because of the anti-DOS proofing.
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.
[A couple posts down](https://bitcointalk.org/index.php?topic=279249.msg2984051#msg2984051) I give some examples of how it can be done.
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're presuming a broken model that I don't believe anyone here has ever suggested.
Incorrect. What I wrote is functionally equivalent to what you described. The point is the transaction can be jammed in the final round.
Since you didn't see the equivalence let me explain it. I thought you were smart enough to deduce such things. I chose to let the signatures of inputs go in the second and final round and point to a transaction because I envisioned using ring signatures. And the transaction won't be valid (blockchain will reject it) if the inputs are less than the outputs, so my version is just as safe as yours. And the DOS problem is equivalent. Come on you are a math guy, you can surely see that without me needing to explain it you.
And if you think about it a while you will realize, by inverting the operations and using a ring signature, mine has advantages suchas that not all have to sign in the first round before proceeding to the second round (they get excluded from second round too). Yet the DOS issue remains in the final.
You'd always being the protocol by specifying the inputs in which you intend to sign. Signature authority over inputs is the principle scarcity that allows you to may the system dos-attack resistant. After the inputs are signed, outputs can be specified in a cheat proof way, and then the only avenue for disruption is refusing to sign which can be addressed by blacklisting your inputs (and other rate limiting tokens) and restarting.
Well now you see your error. You can reread my post again, and admit I was correct.
From your upthread post:
If a party fails to sign, everyone else is convinced that its because they are jamming the process (intentionally or maliciously) and then can all ban (ignore in the future) whatever costly identity they used to enter the mix, or if there is no other mechanism that particular txin which they used.
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.