Quote from: pbremen01 on June 21, 2014, 08:23:24 PM

Quote from: AlexGR on June 21, 2014, 07:59:37 PM

Quote from: pbremen01 on June 21, 2014, 05:26:06 PM

Quote from: mrhorse1 on June 21, 2014, 05:18:03 PM

Quote from: Waldozaur12 on June 21, 2014, 05:16:19 PM

It seems to me that bad guys behind others coins like DRK and BC want to destroy this amazing coin.

Screw dark and BC but at least DRK has been honestly trying and just hyping with BS and deleting any analysis of their concept like crypt coin has done (http://www.reddit.com/r/CryptCoin/comments/28e8be/security_analysis_of_cryptcoins_cryptcast_feature/)

Do you have any link to the analysis of their (DRK) concept?

To the best of my knowledge:

Dark uses modified coinjoin with game theory addition.

Plain coinjoin with blind signatures is problematic in DOS scenarios as the attacker can't be punished and the transactions halt forever (that was the first DarkSend implementation back in February). It's also problematic in that inputs / outputs can be co-related as recently evidenced.

DarkSend uses non-blind signing (the node knows what is being transacted) to solve the DoS issue (attacker penalized by losing transaction collateral) but it represents a regression (probably temporary) in terms of anonymity. To solve the mapping-the-transactions issue, two layers have been proposed.

1) make the nodes expensive to acquire, otherwise a bad actor could flood the network with his nodes and map everything (1000 DRK requirement to buy a node). As more nodes are acquired price goes up and creates a positive feedback loop that escalates the price even more. Thus the bad actor will the require immense capital to acquire the vast majority of the nodes.

2) multiple DarkSends through the nodes. In this way even if a bad actor controls 40% of the network nodes, 5 darksends reduce the problem to 0.4 x 0.4 x 0.4 x 0.4 x 0.4 = 1% to get a mapped transaction. IF you do it 10 times even more.

As for (2) an anonymity upgrade plans to replace the necessity for multiple darksends (undisclosed details)

To solve the issue of coinjoin input-output matching, DRK uses a homogenizing denomination pool of 10 coins where all inputs are 10. The plan was to use multiple denomination pools (1-10-100-1000 etc) but there is a problem encountered in the need to send more coins. Imagine if you want to send 600 coins and you need to input 1000 coins. So the denomination pools will be redesigned to account for that issue or dealt with another way.

Problems pending for fix are

a) Change can still be linked for common ownership. This is planned to be fixed in upcoming RCs (denominated change or something like that)
b) Strong IP obfuscation has to be merged (I2P) otherwise network broadcasts betray the user anyway
c) The 10 DRK limit of the denominating pool has to be lifted but at the same time preserve homogeneity of input or find an alternate way to deal with input/output matching.
d) Masternode payments (they get 20% of the mining income for providing the anonymity service / mixing) are glitching and presenting fork issues
e) A way to conceal who is transacting what must be found so that the Masternode doesn't know as a way to eliminate the need for multiple DarkSends which would bloat the blockchain.
f) Traffic on the network will have to increase when everything is done, so that mixing can occur - otherwise with no DarkSends there can be no mixing.
g) The code has to be reviewed by third parties to fix outstanding issues or security holes (later RCs)

Wow, thanks for your detailed answer. I will study this for sure. Where did you get such large amount of implementation details?

Let's just say I've read ~2000 pages of the DRK thread (I've been following DRK since late January).