Bitcoin Forum
June 24, 2017, 09:04:28 PM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   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 252400 times)
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
May 31, 2014, 03:31:04 PM
 #521

maaku, you do actually have to read the post before making OT admonishments

He was asking about Zerocash. Zerocash has nothing to do with CoinJoin, and has it's own thread. I'd happy to discuss it there. In very short summary: Zerocash is not and never has been considered for inclusion on the bitcoin block chain. When the author references bitcoin he means the bitcoin protocol generally.

@Michael_S the point is that you multiple mixes, as well as opportunistic mixes each time you transact. Each mix increases the anonymity set. No one is claiming perfect anonymity a la Zerocash.

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
1498338268
Hero Member
*
Offline Offline

Posts: 1498338268

View Profile Personal Message (Offline)

Ignore
1498338268
Reply with quote  #2

1498338268
Report to moderator
1498338268
Hero Member
*
Offline Offline

Posts: 1498338268

View Profile Personal Message (Offline)

Ignore
1498338268
Reply with quote  #2

1498338268
Report to moderator
POLONIEX TRADING SIGNALS
+50% Profit and more via TELEGRAM
ALTCOINTRADER.CO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1498338268
Hero Member
*
Offline Offline

Posts: 1498338268

View Profile Personal Message (Offline)

Ignore
1498338268
Reply with quote  #2

1498338268
Report to moderator
1498338268
Hero Member
*
Offline Offline

Posts: 1498338268

View Profile Personal Message (Offline)

Ignore
1498338268
Reply with quote  #2

1498338268
Report to moderator
1498338268
Hero Member
*
Offline Offline

Posts: 1498338268

View Profile Personal Message (Offline)

Ignore
1498338268
Reply with quote  #2

1498338268
Report to moderator
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
May 31, 2014, 03:36:52 PM
 #522

yep that's how ZeroCash and CoinJoin could work together. Both are pretty cool systems.

CoinJoin would be for your day to day payments.

ZeroCash would be for anonymising your savings.

(I'm just projecting here don't know full details) It seems like their plan is to build a layer on top of Bitcoin like how MasterCoin works. And that the ZC ledger tracks the Bitcoin one so you can convert to and from the ZC system. That's really exciting if so.
dewdeded
Legendary
*
Offline Offline

Activity: 924


Monero Evangelist


View Profile WWW
May 31, 2014, 04:41:28 PM
 #523

AFAIK ZeroCash needs a trusted accumulator. So it's just a science prototype and wont become a cryptocurrency, no one will use a cryptocurrency where:

- if an NSA agent contributed to the "trusted setup" there will be no privacy
or
- if an Mark Karpeles guy contributed to the "trusted setup" he can generate/create more coins than announced (as his crime would be invisible in the block chain)



Why use technologies based on trust, when we have trustless ones. Satoshi created Bitcoin specifically with the idea/key feature of not depending on trusting a third party.



Carlton Banks
Legendary
*
Offline Offline

Activity: 1666



View Profile
May 31, 2014, 08:09:02 PM
 #524

maaku, you do actually have to read the post before making OT admonishments

He was asking about Zerocash. Zerocash has nothing to do with CoinJoin, and has it's own thread. I'd happy to discuss it there. In very short summary: Zerocash is not and never has been considered for inclusion on the bitcoin block chain. When the author references bitcoin he means the bitcoin protocol generally.

@Michael_S the point is that you multiple mixes, as well as opportunistic mixes each time you transact. Each mix increases the anonymity set. No one is claiming perfect anonymity a la Zerocash.

Surely a discussion about the way new developments in the Zerocash project relate to Coinjoin actually belong in their own exclusive thread, no? Technically, I mean.

Vires in numeris
anti-scam
Full Member
***
Offline Offline

Activity: 224


View Profile
May 31, 2014, 10:35:02 PM
 #525

In very short summary: Zerocash is not and never has been considered for inclusion on the bitcoin block chain

Considering the billions of dollars of other people's money that's at stake here, that seems like something that needs a public discussion and not a decree by fiat.

Quote from: maaku
When the author references bitcoin he means the bitcoin protocol generally.

Here's a direct quote from page 10 of the paper: "Zerocash can be integrated into Bitcoin or forks of it (commonly referred to as "altcoins"); we later describe how this is done."

Quote from: genjx
(I'm just projecting here don't know full details) It seems like their plan is to build a layer on top of Bitcoin like how MasterCoin works. And that the ZC ledger tracks the Bitcoin one so you can convert to and from the ZC system. That's really exciting if so.

I think that's being considered but I'm not sure if it's their final plan. It seems to me that, given some BTC developers' hostility toward their technology, they'd have an incentive to strike out on their own. As far as I know the infrastructure for Bitcoin sidechains is not yet in place so they can't go that route.

Quote from: dewdeded
AFAIK ZeroCash needs a trusted accumulator. So it's just a science prototype and wont become a cryptocurrency, no one will use a cryptocurrency where:

- if an NSA agent contributed to the "trusted setup" there will be no privacy
or
- if an Mark Karpeles guy contributed to the "trusted setup" he can generate/create more coins than announced (as his crime would be invisible in the block chain)

Why use technologies based on trust, when we have trustless ones. Satoshi created Bitcoin specifically with the idea/key feature of not depending on trusting a third party.

Zerocash needs a "one time trusted setup of public parameters". It's not unique in that sense. Many cryptography systems can be broken if certain constants are chosen in a particular way. Bitcoin itself could potentially be broken if its curve parameters were backdoored in some way (see https://bitcointalk.org/index.php?topic=151120.0). I don't know exactly what the Zerocash team's plan to instill confidence in their public parameters is but it seems like a surmountable complaint.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2226



View Profile
June 01, 2014, 03:03:11 AM
 #526

Bitcoin itself could potentially be broken if its curve parameters were backdoored in some way (see https://bitcointalk.org/index.php?topic=151120.0).
Incorrect.  People have speculated that potentially an attacker powered by non-public mathematical breakthroughs could select parameters in a way to make a system weaker against publicly-unknown attacks which require specific improbable curve characteristics. This is pure conjecture, however— though it's something prudent to be cautious about, it is not a known backdoor vector by itself. The process for selecting curve parameters already excludes known classes of bad curves, if we knew about any other classes we'd exclude those too.  In the case of Bitcoin our parameters were selected in a way where performance considerations removed their degrees of freedom (like the ed25519 parameters were selected), and are all explicable from first principles. In fact, they have an additional property that even if you drop some of the performance characteristics, and increment from the smallest possible parameter requirement the first curve of prime order you find is the one Bitcoin uses. Other cryptosystems also use nothing up my sleeve numbers, where an abundance of caution demands the designers pick them in a way that limit their degrees of freedom but at the same time no one knows of a way where control could be used secretly to do something bad— it's just a good practice, not a backdoor closed.

In the case of the GGPR'12 based SNARKs there is no comparable way to generate the parameters: The creation of the prover/verification keys requires computation using secret values, which— if known— completely compromise the soundness of the proofs. Here the backdoor is very concrete— not theoretical— when you know just a couple of the secrets you can do a few multiplies and have a false proof. Worse, there is no known way to use a nothing up my sleeve number to pick the parameters to convince people that no one could know the secrets. The best you can do is use process, like the CA system does (but potentially way better) to convince people of security.  This isn't insurmountable for _many_ applications, but it is not at all comparable to EC curve parameters, there is nothing in curve parameter selection that looks like a magic number where if the attacker knows it all is lost. As far as I know there nothing like this in widespread use, the nearest parallel I can think of is the backdoor in DUAL_EC DRBG, though in that case the backdoor was a "surprise" and no process to prove that the potential backdoor wasn't weaponized (because it was)— which certantly makes it more concerning. There are a fair number of proposed _theoretical_ cryptosystems which have similar assumptions (e.g. Any of the neat uses of obfuscation involve the obfuscation being established by a trusted party), but I'm not aware of these systems being put into production. One reason for this may be because theoreticians find trusted initialization to be more acceptable than practitioners do— the theoreticians just posit "A spherically honest cow in random-oracle derived motion faithfully creates the parameters", the practitioners are the ones that have to figure out how to approximate the spherical cow using three chickens, a reed-solomon code, and a priest.

Quote
It seems to me that, given some BTC developers' hostility toward their technology, they'd have an incentive to strike out on their own
Funny, I've seen similar disinformation published before— that person was unwilling (unable) to substantiate it— can you do better?   The comments I made on Zerocoin were, I think, reasonably positive— but at the same time the system as it was wasn't suitable for deployment, and was later replaced by a complete reboot with much better performance (also evidence by the fact that no altcoin has deployed it, though they made a nice implementation of the cryptosystem available). I don't think there was anything hostile there, I've spent time with the developers of it and I think they're great guys, ... and I don't know any other developers who have been hostile about it either, so I'd really like to know what you're talking about.

This has really gone off-topic, but I thought leaving the FUD sitting around would be harmful.

Bitcoin will not be compromised
Kiwigoeswest
Newbie
*
Offline Offline

Activity: 13


View Profile
June 01, 2014, 05:45:43 AM
 #527

Interesting read. Perhaps someone can make test QT soon Smiley
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
June 03, 2014, 09:15:33 PM
 #528

Follow-up of discussion from this thread

A careless join is one in which the correct solution is obviously the most plausible. Note that evaluating different solutions to the matrix lends itself well to parallel processing, there is no time limit since everything is permanently recorded in the blockchain, and mass surveillance doesn't require 100% accuracy.

Probably the only way to make CoinJoin useful in real-world situations is to build into the clients the exact same type of analysis tools attackers will use to reverse the joins so that clients can evaluate any proposed join prior to agreeing to it. (That's a good subject for the other thread).

I like your remark about time limit and 100% accuracy. It remembers me an interview of a computer scientist working for an US intel agency. He was explaining how they were building a different paradigm for search: sometimes you ask a question and you don't get an answer because it's just too early. If you don't ask again later, you'll never know the answer. But if you let the question pending, till the "right" data is gathered and aggregated, then you start to get something very efficient.

You can apply the same principle to transaction graph analysis. Even if you're very carefull about the privacy of your transactions, one-time coinjoin is not enough if others participants are less carefull and can be deanonymized later.
For now, systematic coinjoin (as proposed by DarkWallet) seems the most serious option to enhance privacy since it would create a combinatorial explosion and would significantly raise the cost of deanonymisation. But I guess it also comes with a lot of others issues to solve (delay required, constraints on amounts, ...).

Moreover, till now, main heuristics used for analysis of the transaction graph are "quite simple" (tainting, "address reuse" and "change address" patterns) and I guess it's just the first generation (at least which is publicized). I'm quite sure that more elaborated tools (temporal patterns, behavorial patterns) combined with side-channels attacks (data gathered from peripheral systems like exchanges, merchants, ...) could provide stunning results.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 03, 2014, 09:29:15 PM
 #529

Moreover, till now, main heuristics used for analysis of the transaction graph are "quite simple" (tainting, "address reuse" and "change address" patterns) and I guess it's just the first generation (at least which is publicized). I'm quite sure that more elaborated tools (temporal patterns, behavorial patterns) combined with side-channels attacks (data gathered from peripheral systems like exchanges, merchants, ...) could provide stunning results.
The problem is that those tools are all being developed behind closed doors, which gives the attackers an advantage. Too many people think a low taint score displayed on blockchain.info provides them with meaningful protection.

I'll predict though that for all this investment money flowing into Bitcoin startups, not one VC is going to fund investment into open source graph analysis tools that could help individuals measure their privacy and warn them before they do something that will compromise it.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2226



View Profile
June 03, 2014, 09:48:28 PM
 #530

Andytoshi and I spent some time trying to formalize a notion of "coinjoin entropy"— e.g. how many possible mappings of inputs to outputs are possible given the values. A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties.

We didn't actually solve the entropy question for the non-concurrent payment case, it's an interesting question.

Bitcoin will not be compromised
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
June 03, 2014, 09:53:47 PM
 #531

The problem is that those tools are all being developed behind closed doors, which gives the attackers an advantage. Too many people think a low taint score displayed on blockchain.info provides them with meaningful protection.

I'll predict though that for all this investment money flowing into Bitcoin startups, not one VC is going to fund investment into open source graph analysis tools that could help individuals measure their privacy and warn them before they do something that will compromise it.
100% agree.
I'm interested in this subject and I thought about the opportunity to build such a tool for the community since data and technology are available.

But I came up with the following conclusions :
- it seems very difficult to fund a company like this one (well, you could plan to sell a closed product to some agencies like Fincen, banks... but it sounds like a small market)
- human analysts are still required and I'm not sure that many people in the community are ready to invest a lot of time as unpaid volunteers. So it seems difficult to build a sustainable community around an open platform like this one.

BTW, I would be glad to be proven wrong and be funded to build a tool like this one.  Wink


justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 03, 2014, 10:22:32 PM
 #532

well, you could plan to sell a closed product to some agencies like Fincen, banks... but it sounds like a small market
I'm sure there's plenty of money available to fund that.

The question is whether or not you can get funding to produce the tools that let the general public protect themselves from it.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 03, 2014, 10:56:17 PM
 #533

A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties.
So the Payment Protocol should be CoinJoin.
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
June 04, 2014, 06:52:05 PM
 #534

well, you could plan to sell a closed product to some agencies like Fincen, banks... but it sounds like a small market
I'm sure there's plenty of money available to fund that.

The question is whether or not you can get funding to produce the tools that let the general public protect themselves from it.

Agree with that.

Unfortunately, I fear there's an asymmetry which isn't in favor of this kind of project for now.

Projects are funded by entities which have some interest in the project and projects "tracking" users are more appealing to corporations and VC since there's a big data trend in the corporate world with an expected financial ROI. I guess it's not a political or ideological choice. They just do what they're supposed to do: business.

On the other hand, privacy friendly projects have not a clear financial ROI. For now.
Funding this kind of project is more a "militant" choice than a financial one. For now.
Moreover, Bitcoin is still presented as an anonymous and shadowy financial system by a majority of mainstream media, which is far from the reality but does not help people to understand the challenges at stake. I fear it's not specific to Bitcoin and that very few people are really aware of the challenges posed by technologies like internet or cryptocurrencies in term of privacy.

Dark activities have nothing to do with that (sorry eric schmidt). We need to think a new model of society, interconnected, in which a resource (data) has gained a massive increased value without any market mechanism fixing this value. For now.

Sorry for this "philosophical" off-topic (barely checked with google translate - a "free" product provided by Google Inc. -)
anti-scam
Full Member
***
Offline Offline

Activity: 224


View Profile
June 05, 2014, 06:38:50 AM
 #535

Incorrect.  People have speculated that potentially an attacker powered by non-public mathematical breakthroughs could select parameters in a way to make a system weaker against publicly-unknown attacks which require specific improbable curve characteristics. This is pure conjecture, however— though it's something prudent to be cautious about, it is not a known backdoor vector by itself. The process for selecting curve parameters already excludes known classes of bad curves, if we knew about any other classes we'd exclude those too.  In the case of Bitcoin our parameters were selected in a way where performance considerations removed their degrees of freedom (like the ed25519 parameters were selected), and are all explicable from first principles. In fact, they have an additional property that even if you drop some of the performance characteristics, and increment from the smallest possible parameter requirement the first curve of prime order you find is the one Bitcoin uses. Other cryptosystems also use nothing up my sleeve numbers, where an abundance of caution demands the designers pick them in a way that limit their degrees of freedom but at the same time no one knows of a way where control could be used secretly to do something bad— it's just a good practice, not a backdoor closed.

In the case of the GGPR'12 based SNARKs there is no comparable way to generate the parameters: The creation of the prover/verification keys requires computation using secret values, which— if known— completely compromise the soundness of the proofs. Here the backdoor is very concrete— not theoretical— when you know just a couple of the secrets you can do a few multiplies and have a false proof. Worse, there is no known way to use a nothing up my sleeve number to pick the parameters to convince people that no one could know the secrets. The best you can do is use process, like the CA system does (but potentially way better) to convince people of security.  This isn't insurmountable for _many_ applications, but it is not at all comparable to EC curve parameters, there is nothing in curve parameter selection that looks like a magic number where if the attacker knows it all is lost. As far as I know there nothing like this in widespread use, the nearest parallel I can think of is the backdoor in DUAL_EC DRBG, though in that case the backdoor was a "surprise" and no process to prove that the potential backdoor wasn't weaponized (because it was)— which certantly makes it more concerning. There are a fair number of proposed _theoretical_ cryptosystems which have similar assumptions (e.g. Any of the neat uses of obfuscation involve the obfuscation being established by a trusted party), but I'm not aware of these systems being put into production. One reason for this may be because theoreticians find trusted initialization to be more acceptable than practitioners do— the theoreticians just posit "A spherically honest cow in random-oracle derived motion faithfully creates the parameters", the practitioners are the ones that have to figure out how to approximate the spherical cow using three chickens, a reed-solomon code, and a priest.

Thank you for correcting my misleading statement. There are definitely are significant trust differences between the two processes. Your explanation will come in handy as more discussions about Zerocash surface.

Quote from: gmaxwell
I don't think there was anything hostile there, I've spent time with the developers of it and I think they're great guys, ... and I don't know any other developers who have been hostile about it either, so I'd really like to know what you're talking about.

I don't think that you in particular are hostile to anonymity nor am I suggesting that any of the Bitcoin developers have personal issues with any of the Zerocash developers. But I also know that there are many agendas at play in the Bitcoin world and not all of them include the type of anonymity that Zerocash provides.

I still think that there will have to be a public conversation about Zerocash, particularly after its developers have revealed how they plan on instilling confidence in their parameters, but I will save it for another thread.

waxwing
Sr. Member
****
Offline Offline

Activity: 468


View Profile
June 05, 2014, 11:56:45 AM
 #536

Andytoshi and I spent some time trying to formalize a notion of "coinjoin entropy"— e.g. how many possible mappings of inputs to outputs are possible given the values. A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties.

Sound logic, but it's not even necessary - since there is no such thing as "a Bitcoin", it is impossible to make a deterministic linkage between inputs and outputs. If the system was designed to actually transfer distinguishable units ('things') from one account to another, then the many-many mapping of txs wouldn't actually make sense (because somewhere in the guts of the code it would be deciding which bill with which serial number goes to which output, which would mean that de facto it was a set of one-one txs in disguise).

PGP fingerprint 4668 9728 A9F6 4B39 1FA8 71B7 B3AE 09F1 E9A3 197A (use email to contact)
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 05, 2014, 12:03:36 PM
 #537

since there is no such thing as "a Bitcoin", it is impossible to make a deterministic linkage between inputs and outputs.
That is a true, but useless, statement.

As I mentioned before, mass surveillance doesn't require 100% accuracy.
instagibbs
Member
**
Offline Offline

Activity: 114


View Profile
June 05, 2014, 01:01:38 PM
 #538

Andytoshi and I spent some time trying to formalize a notion of "coinjoin entropy"— e.g. how many possible mappings of inputs to outputs are possible given the values. A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties.

We didn't actually solve the entropy question for the non-concurrent payment case, it's an interesting question.

The "entropy" will depend upon the model of attacker. Start by enumerating those.

Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1078


View Profile
June 05, 2014, 03:43:00 PM
 #539

Academic discussions aside, in any case what has been actually implemented in Dark Wallet is that you have two classes of users: people who want to send money now, and people who have coins that they want to mix. The latter don't have any particular requirements on the exact amounts they want mixed, so they copy the amounts the former are sending, guaranteeing that at least two outputs are identical and have two possible senders. Blockchain.info's CoinJoin implementation is similar, with blockchain.info operating maintaining a pool of funds that is used to copy exact output amounts.

Future implementations can and will improve on these concepts, but again, what's implemented now takes output indistinguishably into account and provides reasonably good privacy already.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2226



View Profile
June 05, 2014, 10:26:50 PM
 #540

The "entropy" will depend upon the model of attacker. Start by enumerating those.
The attacker knows everything in the blockchain. The attacker knows the identity of the payer or payee of some small number of transactions. The attacker wants to follow these identified funds forwards or backwards and expand their knoweldge recursively. The CJ users want the attackers analysis to fail, for themselves (most importantly) and for third parties.

I think of two main attack objectives— where the attacker is trying to identify a single user and where success/failure depends on how persuasive the evidence the attacker can extract for that single user.  And one where the attacker is trying to broadly deanonymize everyone in order to feed larger scale analysis. For this latter attack the defender's is successful if they're able to increase the noise level of the analysis by a non-trivial amount at low cost to themselves, e.g. success in this latter cases is completely continuous.

I outlined some more specific attack objectives in the original post— things like people you do business with being able to determine your income, net worth, supplies costs, or prices.

Bitcoin will not be compromised
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!