CoinJoin: Bitcoin privacy for the real world

[maaku]

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

[1713584902]

1713584902

[1713584902]

1713584902

[1713584902]

1713584902

[1713584902]

1713584902

[1713584902]

1713584902

[1713584902]

1713584902

[Cryddit]

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

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. 

[ShadowOfHarbringer]

After studying your posts on these forums, I am fairly certain that you have the skill. The question is, whether you want to do something with it, or just keep discussing the topic ?

Honestly, I just don't need it, so I don't really feel the urge to create such a thing.
(...)
Still I believe it can be done and since it can be done, someone will do it one day

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

[maaku]

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. 

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

[Cryddit]

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.

[randomguy7]

After studying your posts on these forums, I am fairly certain that you have the skill. The question is, whether you want to do something with it, or just keep discussing the topic ?

Honestly, I just don't need it, so I don't really feel the urge to create such a thing.
(...)
Still I believe it can be done and since it can be done, someone will do it one day

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

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.

[hozer]

After studying your posts on these forums, I am fairly certain that you have the skill. The question is, whether you want to do something with it, or just keep discussing the topic ?

Honestly, I just don't need it, so I don't really feel the urge to create such a thing.
(...)
Still I believe it can be done and since it can be done, someone will do it one day

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

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.

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.

[ShadowOfHarbringer]

After studying your posts on these forums, I am fairly certain that you have the skill. The question is, whether you want to do something with it, or just keep discussing the topic ?

Honestly, I just don't need it, so I don't really feel the urge to create such a thing.
(...)
Still I believe it can be done and since it can be done, someone will do it one day

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

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.

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.

[therealbigcoin]

Is this the thing darkcoin will implement?

[philipmicklon]

Is this the thing darkcoin will implement?

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

[gmaxwell]

The extant solution for anonymous networks (Tor) requires extra steps that many users won't do,

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.

[themgp]

The extant solution for anonymous networks (Tor) requires extra steps that many users won't do,

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.

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."

[AnonyMint]

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

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.

[therealbigcoin]

The extant solution for anonymous networks (Tor) requires extra steps that many users won't do,

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.

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."

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

[AnonyMint]

Comments please on my technical statement herein?

Yes, I think CoinJoin should be a very good start.  But do any really decentralised and fully working implementations of CoinJoin exist already?  I don't think so and would be interested to know if they are.

I'm not aware of any either but don't let that deter you from using one of the already existing solutions even if they aren't perfect.

A decentralized CoinJoin will have difficulty forming transactions (including unequal or equal transaction amounts) that look like this if anyone can join:

https://blockchain.info/tx/e4abb15310348edc606e597effc81697bfce4b6de7598347f17c2befd4febf3b?show_adv=true

A sharedcoin transaction will look something like this: https://blockchain.info/tx/e4abb15310348edc606e597effc81697bfce4b6de7598347f17c2befd4febf3b (picked at random). As you can see multiple inputs and outputs make the determining the actual sender and receiver more difficult.

The server does not need to keep any logs and transactions are only kept in memory for a short time. However If the server was compromised or under subpoena it could be force...

Because the way it must work is the users sign the transaction first with their requested outputs, then in the second round they sign their payments as inputs to the transaction. If the payment inputs are less than the total, then the transaction is invalid. There is no way to determine who cheated and rate limit them. Thus the saboteur can stomp on every attempt to create a CoinJoin transaction and destroy the decentralized system.

DarkCoin says they can solve this by charging a fee, but you will see I originally proposed that idea in the CoinJoin thread and the requirement is all the participants must be permanently identified and then must use divide-and-conquer to whittle down to who was the saboteur. But identification defeats the mixing!

Thus I have not yet seen a workable decentralized CoinJoin that can scale. And I don't expect one.

[gmaxwell]

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.

[AnonyMint]

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.

[gmaxwell]

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.

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:

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.

[wheatstone]

Keep your ad hominem attacks out of it please. I asked kindly for technical comments.

I think you misunderstand what an ad hominem attack is. If gmaxwell had called you are blithering fool, that would qualify. As it were, he pointed out that your posts have been incorrect and confused, and then backed it up with specifics. That's not attacking the man, that's attacking the content (which was full of errors and confused).

You might try answering gmaxwell's assertion that ratelimiting is, in fact, not an issue instead of merely stipulating that it is insoluble.

For my own part, I would question that there is a non-ephemeral identification of participants, namely by requiring the inputs first. The inputs would serve as an identification and if any problems were subsequently to arise, they could be blacklisted.

[solex]

I have had the AnonyMint on ignore for months now and my experience of this forum is much improved. Shame that quotes still occur, however.