Bitcoin Forum
October 22, 2017, 12:30:17 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  Print  
Author Topic: CoinJoin: Bitcoin privacy for the real world  (Read 262864 times)
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
November 02, 2013, 09:25:40 PM
 #161

what happens if the facilitator is compromised?

Depends on which implementation you are talking about. In gmaxwell's protocol and my crowd-fund proposal, outputs are blinded so neither the facilitator nor any of the participants know which outputs belong to any of the others. So the facilitator doesn't have to be trusted, other than to complete the protocol. Genjix's server doesn't use blind signing & anonymous revelation, so I'd imagine you'd be able to trace ownership from the facilitator's logs (I haven't looked at his code, however).

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
1508675417
Hero Member
*
Offline Offline

Posts: 1508675417

View Profile Personal Message (Offline)

Ignore
1508675417
Reply with quote  #2

1508675417
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508675417
Hero Member
*
Offline Offline

Posts: 1508675417

View Profile Personal Message (Offline)

Ignore
1508675417
Reply with quote  #2

1508675417
Report to moderator
1508675417
Hero Member
*
Offline Offline

Posts: 1508675417

View Profile Personal Message (Offline)

Ignore
1508675417
Reply with quote  #2

1508675417
Report to moderator
piuk
Hero Member
*****
expert
Offline Offline

Activity: 910



View Profile WWW
November 03, 2013, 02:00:40 AM
 #162

Blockchain.info's coinjoin implementation (Shared coin) is now available in the wallet interface by default.
 


It uses a hybrid approach mixing with other clients and a pool provided by the server. The advantage to this approach is a) there is no long wait time needed for other clients to join in your transaction (hence easier to bootstrap if usage is low initially) b) the server always has a large pool available which can be used to reduce transaction taint more effectively. Browser extension coming soon.

Depends on which implementation you are talking about. In gmaxwell's protocol and my crowd-fund proposal, outputs are blinded so neither the facilitator nor any of the participants know which outputs belong to any of the others. So the facilitator doesn't have to be trusted, other than to complete the protocol.

I think there is a flaw in the blind signing solution. The client doesn't know how many other genuine participants have joined in a transaction so if the server was malicious it could lie, add its own outputs, and force one participant per transaction. With only one genuine participant in the transaction even if the outputs are blind signed it simple to connect the correct inputs.

Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
November 03, 2013, 03:16:13 AM
 #163

Blockchain.info's coinjoin implementation (Shared coin) is now available in the wallet interface by default.


Thank you! This is great news.

Depends on which implementation you are talking about. In gmaxwell's protocol and my crowd-fund proposal, outputs are blinded so neither the facilitator nor any of the participants know which outputs belong to any of the others. So the facilitator doesn't have to be trusted, other than to complete the protocol.

I think there is a flaw in the blind signing solution. The client doesn't know how many other genuine participants have joined in a transaction so if the server was malicious it could lie, add its own outputs, and force one participant per transaction. With only one genuine participant in the transaction even if the outputs are blind signed it simple to connect the correct inputs.

I replied to maaku's crowd-fund proposal with similar concerns. In the general case I think blind-signing is a overly complex cryptographic solution looking for a problem. What you describe is just a particularly bad example of how it doesn't actually give you any anti-sybil protection if you don't know who the counterparts to the transaction are. I proposed that two-party mixes be used in the general case. The cryptography required is almost trivial and can be done with existing libraries used for their intended purpose, the user experience is good because the transactions can happen almost as fast as regular ones and it's easy to do the negotiations on the existing P2P network, and finally the anti-sybil resistance claimed is much more honest: we know we can't prevent sybil attacks, but we can make them cost a lot of transaction fees.

maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
November 03, 2013, 03:27:22 AM
 #164

I think there is a flaw in the blind signing solution. The client doesn't know how many other genuine participants have joined in a transaction so if the server was malicious it could lie, add its own outputs, and force one participant per transaction. With only one genuine participant in the transaction even if the outputs are blind signed it simple to connect the correct inputs.

That's why you use multiple facilitators, and act as act as facilitator yourself 1/N of the time. The implementation I'm working on is fully p2p.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
November 03, 2013, 03:38:11 AM
 #165

I think there is a flaw in the blind signing solution. The client doesn't know how many other genuine participants have joined in a transaction so if the server was malicious it could lie, add its own outputs, and force one participant per transaction. With only one genuine participant in the transaction even if the outputs are blind signed it simple to connect the correct inputs.

That's why you use multiple facilitators, and act as act as facilitator yourself 1/N of the time. The implementation I'm working on is fully p2p.

That's no better than the two-party case though - you have no idea if anyone else in the p2p network, facilitator or not, is real or part of a sybil attack, and it's still going to be slower to complete a transaction than the two-party alternative.

Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
November 03, 2013, 03:39:34 AM
 #166

Blockchain.info's coinjoin implementation (Shared coin) is now available in the wallet interface by default.

For transactions where I'm not in a rush - and am willing to leave my bc.i client running - think you could add an advanced option where you give the wallet a destination address and a timeout and it waits until someone else is available to do a coinjoin?

dserrano5
Legendary
*
Offline Offline

Activity: 1848



View Profile
November 03, 2013, 07:42:17 AM
 #167

Blockchain.info's coinjoin implementation (Shared coin) is now available in the wallet interface by default.

Way to go piuk! It's a centralised effort but it's better to have a centralised coinjoin than no coinjoin at all.

molecular
Donator
Legendary
*
Offline Offline

Activity: 2380



View Profile
November 03, 2013, 09:40:36 AM
 #168

Blockchain.info's coinjoin implementation (Shared coin) is now available in the wallet interface by default.

Way to go piuk! It's a centralised effort but it's better to have a centralised coinjoin than no coinjoin at all.

I totally agree. However I think it should be made transparent that with this solution, the facilitator can map inputs to outputs easily and you have to trust him with retaining your own personal privacy.

One question piuk: does your servers in any way store records that would allow this mapping to be conducted by some entity gaining access to your databases?

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
November 03, 2013, 01:44:39 PM
 #169

One question piuk: does your servers in any way store records that would allow this mapping to be conducted by some entity gaining access to your databases?
You should never asks this question of any service.

Why? Because the answer you receive doesn't matter because you have no way to independently to verify the truth of a response.

A dishonest operator can lie.

An honest operator might not start out keeping logs, but could be ordered to do so and forbidden from telling you the truth via the threat of going to jail.

An honest operator might not realize they are keeping logs because their system has been compromised.

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
November 03, 2013, 01:47:31 PM
 #170

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.

I hate to do this (in fact it might be the first time I actually have) but:

+1

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
November 03, 2013, 03:34:42 PM
 #171

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.

piuk, and my, point is that decentralized P2P systems with anonymous counterparties aren't necessarily any better because you can't know if your counterparties to the coinjoin are the NSA/FBI/whatever.

At least with a central service if they are honest you're well protected. With P2P stuff every transaction you make may or may not be deanonymized.

Best to use both if you really need to be able to count on the privacy... and hopefully someone will come up with a off-chain transfer system on some Tor site that implements chaum tokens.

genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
November 03, 2013, 04:02:45 PM
 #172

to make coinjoin work properly we first need decentralised identity and reputation systems to protect against that. otherwise just making it p2p for the fun of it is not doing anything.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
November 03, 2013, 04:03:00 PM
 #173

piuk, and my, point is that decentralized P2P systems with anonymous counterparties aren't necessarily any better because you can't know if your counterparties to the coinjoin are the NSA/FBI/whatever.
It turns into a numbers game. If x% of the participants are evil, then you need to mix 1/x times.
Best to use both if you really need to be able to count on the privacy... and hopefully someone will come up with a off-chain transfer system on some Tor site that implements chaum tokens.
I agree the ideal solution is a cryptographic protocol in which nobody can cheat, even if all the participants are evil.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
November 03, 2013, 04:05:20 PM
 #174

otherwise just making it p2p for the fun of it is not doing anything.
Actually it is doing something - providing a type of plausible deniability.

Suppose CoinJoin transactions become a frequent occurrence in the blockchain. I can now spend funds from my wallet using transactions that appear to be CoinJoins, but are actually only my funds. I might only need to use "real" CoinJoin transactions some small percentage of the time.
Trader Steve
Hero Member
*****
Offline Offline

Activity: 832


"How do you eat an elephant? One bit at a time..."


View Profile
November 03, 2013, 05:00:06 PM
 #175


Best to use both if you really need to be able to count on the privacy... and hopefully someone will come up with a off-chain transfer system on some Tor site that implements chaum tokens.

Could Open Transactions play a role in any of this?

https://github.com/FellowTraveler/Open-Transactions


molecular
Donator
Legendary
*
Offline Offline

Activity: 2380



View Profile
November 03, 2013, 08:17:50 PM
 #176

One question piuk: does your servers in any way store records that would allow this mapping to be conducted by some entity gaining access to your databases?
You should never asks this question of any service.

Why? Because the answer you receive doesn't matter because you have no way to independently to verify the truth of a response.

A dishonest operator can lie.

An honest operator might not start out keeping logs, but could be ordered to do so and forbidden from telling you the truth via the threat of going to jail.

An honest operator might not realize they are keeping logs because their system has been compromised.

Under no circumstances can you trust someone's word about not keeping logs. This applies to VPN providers, bitcoin mixers, email hosts, or any other privacy-sensitive service. If it's conceivably possible that they are keeping privacy-destroying logs then you must assume they are, and act accordingly.

There's the possiblity he will just say: yes, we keep logs. In that case the question would've made sense.


PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
molecular
Donator
Legendary
*
Offline Offline

Activity: 2380



View Profile
November 03, 2013, 08:23:50 PM
 #177

otherwise just making it p2p for the fun of it is not doing anything.
Actually it is doing something - providing a type of plausible deniability.

Suppose CoinJoin transactions become a frequent occurrence in the blockchain. I can now spend funds from my wallet using transactions that appear to be CoinJoins, but are actually only my funds. I might only need to use "real" CoinJoin transactions some small percentage of the time.

Exactly.

There's this huge upside to widespread use of coinjoin transactions (no matter how they've been assembled) in general (even affecting people that don't ever use coinjoin), because it torpedoes the assumption that all inputs of a transaction are owned by a single entity that can currently pretty reliably be used to cluster addresses, which is the most common (valid) argument used when arguing that bitcoin isn't as private as many think.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
Anon136
Legendary
*
Offline Offline

Activity: 1288



View Profile
November 05, 2013, 03:21:04 PM
 #178

I think there is a flaw in the blind signing solution. The client doesn't know how many other genuine participants have joined in a transaction so if the server was malicious it could lie, add its own outputs, and force one participant per transaction. With only one genuine participant in the transaction even if the outputs are blind signed it simple to connect the correct inputs.

That's why you use multiple facilitators, and act as act as facilitator yourself 1/N of the time. The implementation I'm working on is fully p2p.

That's no better than the two-party case though - you have no idea if anyone else in the p2p network, facilitator or not, is real or part of a sybil attack, and it's still going to be slower to complete a transaction than the two-party alternative.

how did we solve this with bitcoin? you could solve it here the exact same way. have the facilitators be the 6 most recent miners to contribute new blocks to the blockchain. or atleast the 6 most recent who agree to provide the service.

maaku if you read this also please tell me what you think.

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
November 05, 2013, 06:50:05 PM
 #179

Anon136, there is no need to reduce the set of facilitators in any way, even by distributed consensus. But miners could certainly publish lists of perceived reliable facilitators in their blocks, helping others to find them. There's a proposal along these lines for peer lists that is currently circulating the development mailing list.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
Anon136
Legendary
*
Offline Offline

Activity: 1288



View Profile
November 05, 2013, 09:13:42 PM
 #180

Anon136, there is no need to reduce the set of facilitators in any way, even by distributed consensus. But miners could certainly publish lists of perceived reliable facilitators in their blocks, helping others to find them. There's a proposal along these lines for peer lists that is currently circulating the development mailing list.

what if the majority of the facilitators were actually a single malicious actor using multiple ip exit nodes? have you devised a mechanism for preventing him from being able to deduce information about transactions in this manner? or have you devised an alternative mechanism for insuring that no such actor is ever able to gain that much influence?

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!