Well I got another reply from CORE BITCOIN DEVELOPER gmaxell and here is my rebuttal...posting here in case he deletes my post there as he has threatened me in a private message (which I also publish below)...
I see those (other than gmaxwell who is not very ad hominem in his response, other than the slight "over and over" which is irrelevant to the technical response) who posted while I was sleeping have relished in their
boastful snobbery.
Now let's deal with the
humbling facts.
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.
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.
As far as I can see, you can't.
I am confident that now you see the functionally w.r.t. to anti-DOS of what I described and what you described are equivalent, i.e. any one who is the least bit mathematical can see that the salient mathematical foundation of CoinJoin is that the correlation between the inputs and outputs must be cryptographically blinded, thus it makes no difference mathematically for anti-DOS whether the inputs or outputs are specified in the first round of the protocol.
As for whether my proposed protocol of putting the outputs in the first round is implementable on the Bitcoin blockchain, it is irrelevant since we are talking about a general protocol here and an altcoin could be designed to allow a transaction where outputs and inputs can be signed to point to the transaction nonce (a hash of any number) plus the addresses of the inputs OR outputs. I didn't bother to check how Bitcoin signs the transactions, because it is conceptually irrelevant to our discussion. Perhaps in Bitcoin the signature of the transaction must include all the inputs AND outputs. The reason I presented my formulation (in fact I mentioned the ring signatures idea from Adam Back in the Zerocoin thread months ago in this thread) is because it is more powerful conceptually than one gmaxell described. I thought gmaxell would appreciate that since I think he is a math guy.
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.
I'll repeat it, since maybe other people are having problems following the link:
I will quote from your more detailed description upthread.
This is an extremely interesting idea. Could you elaborate on how the Zerocoin transaction stages map to the stages of CoinJoin transaction creation?
For non-decenteralized coincoin, you simply pass around a transaction and sign it. It's a single sequence and an atomic transaction, you'd make two loops through the users, one to discover the inputs and outputs, and another to sign them. There really aren't stages to it.
Making a decenteralized CoinJoin secure, private, and resistant to DOS attack (people refusing to sign in order to make it fail) is trickier... for the privacy and dos attack resistance you can use ZC:
Presume the participants for a transaction are sharing some multicast medium and can all communicate. They need to accomplish the task of offering up inputs (txid:vout) for inclusion in the transaction and then, in an unlinkable way, providing outputs to receive their coins.
Each participant connects and names bitcoin input(s), an address for change (if needed), and the result of performing a ZC mint transaction to add to the ZC accumulator. They sign all this with the keys for the corresponding inputs proving its theirs to spend.
Then all the parties connect again anonymously and provide ZC redeem transactions which specify where the resulting bitcoins should go.
Zerocoin (ZC) requires a trusted party to generate the parameters, thus it is the antithesis of decentralized, so you have a logical error above.
https://github.com/Zerocoin/libzerocoin/wiki/Generating-Zerocoin-parametersThis isn't the only way to do this in a decentralized manner, the way to do it with blind signatures is fairly similar:
Each participant connects, names Bitcoin input(s), an address for change (if needed), a key for blind signing, and a blinded hash of the address they want paid. They sign all this with the keys for the corresponding inputs proving its theirs to spend.
Each participant then blind signs the blinded hashes of all participants (including themselves).
And so how can you correlate which input is the one who didn't blind sign all?
As far as I can see, you can't.
I've dug very deep (into cryptography research papers) lately into trying to find a way to delink inputs from outputs without a trusted party, and I have realized that mathematically it can't be done. It is a fundamental conceptualization.
The only way to delink without anti-DOS is to use an accumulator commitment scheme with common NP-hard parameters that can be presented in an NIZKP (non-interactive zero knowledge proof) which will always require a trusted party to generate the common parameters for the trapdoor math.
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.
That isn't anti-DOS.
Each spender commits a hash of his intended output. Then everyone does the blinded protocol. If the blinded protocol fails, everyone including the adversary reveals the link between inputs and outputs, because by definition the output key must be an abundant resource so that it is not costly to reveal it and generate a new one to try again.
, or using an anonymous accumulator instead of blind signing to control access.
A ZKP + accumulator isn't decentralized as I explained above.
Tada!
Here is the private message he sent me and my response to him... (bold emphasis is mine)
Go read my post in his thread from yesterday. It wasn't belligerent. It was a discussion of the technical issues and asked for technical comments. How is discussing technical facts belligerent?
Looks to me like below he is trying to justify an imminent abuse his authority...
.
