Pages:
Author

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

staff
Activity: 4172
Merit: 8419
Bitcoin itself could potentially be broken if its curve parameters were backdoored in some way (see https://bitcointalksearch.org/topic/why-did-bitcoin-choose-secp256k1-over-secp256r1-151120).
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.
sr. member
Activity: 476
Merit: 251
COINECT
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://bitcointalksearch.org/topic/why-did-bitcoin-choose-secp256k1-over-secp256r1-151120). 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.
legendary
Activity: 3430
Merit: 3071
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.
legendary
Activity: 1232
Merit: 1011
Monero Evangelist
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.



legendary
Activity: 1232
Merit: 1076
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.
legendary
Activity: 905
Merit: 1011
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.
sr. member
Activity: 278
Merit: 250
Bitcoin-Note-and-Voucher-Printing-Empowerer
Hope that this thread is appropriate:

I think the wide perception that CoinJoin (or DarkCoin) as such brings full anonymity is wrong.

I tried to write an educational memo to illustrate why only using CoinJoin (or DarkCoin) does not yet guarantee anonymity.

You can find it here: http://de.scribd.com/doc/227369807
sr. member
Activity: 476
Merit: 251
COINECT
The promised update to the original Zerocoin/Zerocash paper (http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf) has been released and it claims to reduce the size of a Zerocash transaction to under 1 kB and the time to verify a coin's spending transaction to under 6 ms. I have not fully read the paper yet, but am wondering if anyone has investigated these claims and whether or not these improvements would fully remove the barriers that previously prevented the protocol's integration into Bitcoin?

I am posting this here since I assume that there is a reasonable degree of overlap between those interested in Zerocash and those interested in CoinJoin. I apologize if this has already been addressed but I have been away for a while and am trying to catch up. I know that Peter Todd is advising the Zerocash team so I'm sure he has some valuable insight.

It sounds exciting from what I've heard, but it probably won't go into Bitcoin directly. We need to keep Bitcoin's consensus pure and untouched. We don't nearly know enough.

I find this response a bit confusing. In what way would Zerocash affect Bitcoin's consensus, assuming a one-to-one conversion rate? As for not knowing nearly enough, the whitepaper is pretty detailed and still seems to make provisions for including the protocol directly into Bitcoin. I don't mean to be argumentative, but I consider truly anonymous payments to be a "killer feature" that could very negatively affect Bitcoin's value if it lags behind. Of course there's no rush but it would seem prudent to me to start collecting a bounty.
legendary
Activity: 1232
Merit: 1076
The promised update to the original Zerocoin/Zerocash paper (http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf) has been released and it claims to reduce the size of a Zerocash transaction to under 1 kB and the time to verify a coin's spending transaction to under 6 ms. I have not fully read the paper yet, but am wondering if anyone has investigated these claims and whether or not these improvements would fully remove the barriers that previously prevented the protocol's integration into Bitcoin?

I am posting this here since I assume that there is a reasonable degree of overlap between those interested in Zerocash and those interested in CoinJoin. I apologize if this has already been addressed but I have been away for a while and am trying to catch up. I know that Peter Todd is advising the Zerocash team so I'm sure he has some valuable insight.

It sounds exciting from what I've heard, but it probably won't go into Bitcoin directly. We need to keep Bitcoin's consensus pure and untouched. We don't nearly know enough.
legendary
Activity: 3430
Merit: 3071
anti-scam: off-topic. please use the zerocash thread.

maaku, you do actually have to read the post before making OT admonishments
legendary
Activity: 905
Merit: 1011
anti-scam: off-topic. please use the zerocash thread.
sr. member
Activity: 476
Merit: 251
COINECT
The promised update to the original Zerocoin/Zerocash paper (http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf) has been released and it claims to reduce the size of a Zerocash transaction to under 1 kB and the time to verify a coin's spending transaction to under 6 ms. I have not fully read the paper yet, but am wondering if anyone has investigated these claims and whether or not these improvements would fully remove the barriers that previously prevented the protocol's integration into Bitcoin?

I am posting this here since I assume that there is a reasonable degree of overlap between those interested in Zerocash and those interested in CoinJoin. I apologize if this has already been addressed but I have been away for a while and am trying to catch up. I know that Peter Todd is advising the Zerocash team so I'm sure he has some valuable insight.
legendary
Activity: 1522
Merit: 1000
www.bitkong.com
Pretty interesting OP. I find the complexity hinders from anonymity.
newbie
Activity: 13
Merit: 0
There is absolutely no reason to use fixed units. It adds no anonymity, and increases blockchain traffic.

This surprised me. Surely a transaction with inputs 5,5,5,5 and outputs 5,5,5,5 will have better privacy characteristics than one with inputs 15, 5 and outputs 1,2,3,14?  Or am I misunderstanding what "fixed units" mean?
legendary
Activity: 1232
Merit: 1076
ok thanks for the clarification, makes sense now.
caedes also gave me a similar explanation.
legendary
Activity: 905
Merit: 1011
Here's how we did it in the initial CoinJoin implementation we made.

* There's an anonymous chatroom (pre-negotiated shared secret in public room) accessible over Tor.
* Some dudes submit various outputs.
* Some dudes submit various inputs.
* Server replies back with a tx.
* Some dudes submit valid signatures.

If you are not linking outputs to inputs in the submission (say, by signing the request containing the outputs with the keys of the inputs), then you are leaving the protocol vulnerable to very easy to execute denial of service attacks. If you do close that DoS hole by signing the outputs with the inputs, then the sever operator at the very least knows the linkages and could log this information.

The solution, as explained in the OP, is blinding: link the inputs to the blinded outputs, and later anonymously reveal the outputs and the unblinded signature from the server. Then the participants know that the output was one of the original blinded outputs (because the server signed it), but they don't know which one. Even in a two-party mix with a facilitating server, the server doesn't know which output belongs to whom. If there is a DoS withholding of a signature at the end, the honest participants can elect to back out and reveal their blinding factors, thereby demonstrating their own linkages and preventing themselves from being DoS banned.

BTW, blinding is super easy to do. Using RSA it like a half-dozen lines of code.

We also did it for fixed units.

There is absolutely no reason to use fixed units. It adds no anonymity, and increases blockchain traffic.
newbie
Activity: 44
Merit: 0
Darkwallet does indeed implement coinjoin, albeit using a centralized matchmaking service to setup the mixes.

Just to clarify, we (darkwallet) don't exactly use a centralized matchmaking service, nor did we do at any point (as I would define it anyways). We did use a centralized matchmaking server in our first proof of concept on this thread.

The current scheme works on top of any chat service, where we initially integrated a simple chat in our lobby and now it's the same lobby but the channels exist in a p2p network of all gateways so clients can connect to any gateway or gateways seed from any other gateway.

You are right otherwise we don't yet use ring or blind signatures at the moment, so restricted to 2 party coinjoins, but the general design is done so we can (more or less) easily implement more complex coinjoin protocols.

cheers!
legendary
Activity: 1232
Merit: 1076
Please stay on topic.

@genjix, I think you misunderstood my point about multiple parties. Without blinding or ring signatures or other crypto magic, it is not possible to have multiple participants where the other participants don't know which outputs correspond with which participants (the exception for 2 users is simply that if there is only one other person participating, then obviously whatever outputs are not yours are his, not matter what fancy crypto is used). This is important because CoinJoin is useful for far more than mere mixing. Joint transactions are also the mechanism by which matching donations or crowdfund campaigns can be organized (see Mike Hearn's Lighthouse app), exchange transactions of colored coin assets can be arranged, and various cross-chain atomic trade protocols. Scaling up these applications to multiple participants without loss of privacy is very important.

I think it is.

Here's how we did it in the initial CoinJoin implementation we made.

* There's an anonymous chatroom (pre-negotiated shared secret in public room) accessible over Tor.
* Some dudes submit various outputs.
* Some dudes submit various inputs.
* Server replies back with a tx.
* Some dudes submit valid signatures.

We also did it for fixed units.
legendary
Activity: 905
Merit: 1011
Please stay on topic.

@genjix, I think you misunderstood my point about multiple parties. Without blinding or ring signatures or other crypto magic, it is not possible to have multiple participants where the other participants don't know which outputs correspond with which participants (the exception for 2 users is simply that if there is only one other person participating, then obviously whatever outputs are not yours are his, not matter what fancy crypto is used). This is important because CoinJoin is useful for far more than mere mixing. Joint transactions are also the mechanism by which matching donations or crowdfund campaigns can be organized (see Mike Hearn's Lighthouse app), exchange transactions of colored coin assets can be arranged, and various cross-chain atomic trade protocols. Scaling up these applications to multiple participants without loss of privacy is very important.
legendary
Activity: 1232
Merit: 1076
The problem here is that you don't know the difference between reality and projection. Your apocalypse fantasy (bitcoin=plutonium) is something you should be talking about with a therapist - it has nothing to do with Bitcoin.
At worst it is an exaggerated analogy. The analogy relates to the newness of the technology. Bitcoin is based in math theory and the technology is accessible to all. Just because we have a technology, does that mean everyone should be allowed to use it? Does that go for any technology? Howabout drug manufacturing? Howabout explosives? Should anyone be able to do anything they want without restrictions?

Your morals are not my morals. Who is the decider? Do you support a free and open internet?
And yes, I definitely would like cheap medicinal knock off drugs flooding into the markets, and more kids playing with explosives and becoming scientists. Maybe you want to arrest people who write virus coding tutorials also?

Your mistake is thinking that compliance buys curries you special favour... but at the risk of what? There are bigger things at stake here. Bitcoin is not unmovable code and math, it is consensus. It's imperative we develop this technology, strong, resilient and decentralised. Part of my goal is getting people to think and question things they've held as true. I think we can inspire an ideal through symbolic acts of disobedience, inspiring courage in others to stand with us.

As you demonstrated in your post, the threat is real and here. The world has changed and it's time to adapt, survive and thrive. Either that or go extinct the way of the dinosaurs. And you know what? Maybe that threat you saw was more imagined than you realised. And maybe those threats, just maybe they were a paper tigers and fears unfounded. We will always be on the right side of history because we are about humanity. Dynamism, love, art, energy, change, passion, reality, risk, colour, soul.

http://cultureandempire.com/

Pages:
Jump to: