Topic: CoinJoin: Bitcoin privacy for the real world - page 17. (Read 294649 times)

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.

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.

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:

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.

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.

The very first post in the thread points out that decentralized versions take more work because of the anti-DOS proofing. A couple posts down I give some examples of how it can be done.

You're presuming a broken model that I don't believe anyone here has ever suggested. 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.

Comments please on my technical statement herein?

how about security? I think most exit nodes are under nsa controll, how could that improved?

My understanding of dc-nets is it is impractical to stop denial-of-service. Generally speaking the stronger the anonymity of the mixing, the more difficult to deal with denial-of-service.

I have more comments about what actually works for anonymity at another thread.

I was looking at Orchid (a Tor library) today and saw Mike Hearn's name on a github pull request: https://github.com/subgraph/Orchid/pull/9 with the comment: "I need this fix for bitcoinj."

Tor is actually quite easy to bundle, and some other programs (like torchat) already do. I'd assume that someday there would be bitcoin clients offered with bundled tor.

Yes, I believe this is the general idea behind the darksend feature. But the darksend feature hasn't been rolled out yet.

Is this the thing darkcoin will implement?

WTF, I already did. Look at my sig, genius.

And that is NOT what I am talking about. I am actually criticising piotr_n for coming to this thread and complaining, instead of coding it himself.
And (as he confirmed himself) he could actually do it, he just does not care.

I cannot code CoinJoin anyway, too complex for my skill level.

My thoughts exactly. If you are serious about anonymity and privacy, PAY FOR IT. Cause you have this big problem of how do you test it to make sure it's working. I'm sure the EFF or some other non-profit could be found to hold some money to pay for development and testing.

Wtf maybe you should contribute something on your own (code, money) instead of telling other people which type of unpaid work they should do for you in their free time.

The extant solution for anonymous networks (Tor) requires extra steps that many users won't do, many of those who do will get wrong, and many of those who get wrong won't be aware that they've got wrong.  It is subject to attacks where the compromises of a few selected machines outside your control (your route and exit nodes) can cause your privacy to be sacrificed even if every other node in the mix is honest.  And it is subject to traffic rerouting in transit on the backbone, which is known to be done by at least one sophisticated attacker specifically in response to the fact that it is Tor traffic in the first place. That attacker, and presumably others, specifically reroutes Tor traffic through attack sites which use browser flaws to compromise the machines that originate the traffic.

Tor was a good design once; but the attacks on it are in place, sophisticated, only getting worse, and not easily detectable from the originating node.  So I think that its usefulness is closer to its end than to its beginning.  While Tor may still be good more than 90% of the time, I'm not willing to trust it in the long run. Nor am I willing to trust that people using it can keep their machines from getting compromised by reroutes to attack sites which are using zero-day exploits against their browsers.  Most of them don't even fully disable scripts and cookies in their Tor browser sessions.

The dc-net solution requires you to trust only that there exists at least one other node (ANY participating node) that is not compromised; that's a strictly stronger guarantee than Tor.  If it's built into the protocol then it involves no steps that many users will not do, nor steps that users will attempt but do wrongly.  It is not dependent on the security of machines other than those directly participating, and does not expose machines to attack via a browser as Tor in normal use generally does.

Further, its guarantees are orthogonal to those provided by a (properly functioning) Tor network;  With Tor alone, (if the critical path machines and your own remain uncompromised) you can't associate nodes with IP addresses, but if you're sniffing packet traffic you can associate inputs and outputs with particular nodes.  With the DC-net alone, you can't associate inputs or outputs with particular nodes, but if you're sniffing packet traffic you can produce a list of the IP addresses of the nodes.   So I claim the proper solution is to implement the DC-net as the "fundamental" basis of the protocol, and then let people use it over Tor if they want the extra layer of obfuscation and can correctly use Tor.   That way, even if they fail at configuring Tor, or get unlucky with their Tor network routing, or fail in keeping their own machines secure while using Tor, they still have some fundamental amount of protection.  And if they use Tor correctly, they get additional protection that the DC-net alone could not provide.

Yes, you need an anonymous network. But we have solutions for that...

Ok then, so you prefer to sit and wait for someone to do it for you.

Wow
So laziness
Much not giving fuck
Such a shame
Wow

True.  But Blind signatures alone are not sufficient to implement reliably untraceable coinmixing.

In the solution with blind signatures, you still have someone listening to the packet traffic able to associate inputs and outputs with particular IP addresses - and therefore with each other. 

Cryddit, did you read the op? Blind signatures require no honest nodes.

It's possible to implement coinjoin that can be trusted, even if nobody deletes the logs.  You can secure it against the ability to associate inputs or outputs with each other, or with IP addresses, to an opponent using blockchain evidence, server logs, or realtime packet sniffing. 

The "tricky cryptography" is a stream cipher with multiple keys, each key being known to exactly two participants  (aka, a dc-net).  There is a requirement that there must be more than one honest participant in the "join" whose stream key is unknown to the opponent.   An opponent listening to packet traffic can associate inputs/outputs with any participant whose key that opponent has compromised, so if there is only one honest participant whose key is uncompromised, the opponent can associate inputs/outputs with that participant by process of elimination.

I'll implement it if nobody else has by the time I get around to it, but it isn't my highest priority right now; I have a higher-paying bounty to pursue in programming, which is (arguably) even more important to Bitcoin in terms of adoption and remaining decentralized, and that is to limit the size of the blockchain download needed to run a full node.

Honestly, I just don't need it, so I don't really feel the urge to create such a thing.

If the solution was easy I would have probably done it even when not needing it, but in such case someone else would have already done it before me. The problem is that it doesn't seem so much straight forward. At the other hand providing feedback on the forum is easy - this I can do by the way of having another beer before sleep, nothing hard about it

Still I believe it can be done and since it can be done, someone will do it one day - it is just a matter of time.
But to design it well, you first need to define what kind of privacy this technology is supposed to target.
I mean you can identify a different kind of threads.
The first one is of course that all the internet traffic is recorded.
The second: that the peers with who you are sharing your transaction may (and surely will, after you launch the project) be malicious - e.g I can imagine a network of bots flooding the p2p system with many txs to themselves, just to learn about your transactions.
A third... probably also something.

But if you just want to do a "p2p CoinJoin", without caring about any of these things, then you might just as well look for people to share your tx with at IRC; you all make a joined tx and each party signs manually its part. There already is a software that can do it - not only mine, for what I know.