Re: [ANN][XCO] XCoin | New Secure Hashing Algorithm (cpu only)
It appears the technical design of this DarkCoin is fundamentally flawed and can't be fixed.
There must be some proof that senders sent transactions for all peers on the network to verify before they can accept the block and begin working on the next block solution. Such proof must exist otherwise balances could be stolen by rogue peers.
Thus I must assume you are doing a CoinJoin-like proof for all senders that in that block. And I assume these proofs are transmitted with the block, even if you purge them later (using a proof-of-work chain such as in the mini block chain design).
The problem is that CoinJoin is subject to denial-of-service attack in that if any sender fails to sign in the second step, then no senders can send.
Thus CoinJoin can't scale to a larger number of senders joined. It works best with a few senders and the probability of denial-of-service (rogue sender) is low.
Did you even read the CoinJoin thread carefully?
There is a second insoluble flaw that CoinJoin does nothing to obscure IP address and thus you have no anonymity against powerful entities.
P.S. I don't have time to read 300 pages of this thread to find out if you already addressed this issue. Please give me a link to any prior reply.
Wow, it's that open eh?
Still, this example implies that one could still link up the amounts of the transactions to find the end users. How unique are transaction amounts, and how hard would it be to hide that level? Is there a breaking up of the payment so that the amounts are harder to compare or something? Or am I missing something due to the simplification of the explanation?
Still, this example implies that one could still link up the amounts of the transactions to find the end users. How unique are transaction amounts, and how hard would it be to hide that level? Is there a breaking up of the payment so that the amounts are harder to compare or something? Or am I missing something due to the simplification of the explanation?
Yes, you could still use the transaction amounts to track money through the system. This combined with some logic to use common transaction amounts or some other logic like that in the wallet could definitely help. Even with the problems, having coinjoin implemented directly into the client is a huge step in the right direction.
And timing analysis too.
Hi, I don't want your question to go unanswered, but I'm hardly the person to answer. I'm doing two things at once here and can't look up the posts our developer made at the moment, it'll take a lot of digging to find them. However, our developer, I believe, works in bank security, and seems to know a lot about cryptography. He has explained things in semi simple to understand terms on this thread, and one thing he is not doing is a simple adaptation of coinjoin. I hope he sees your question, and answers it soon. Glad you are challenging him and I look forward to hearing what you have to say once you get the information
Also, regarding ip addresses and other ways of detection, darksend was never said to be bullet proof, but to at least afford a person reasonable privacy. Nobody here, despite recent talk, ever condoned illegal activities with this coin, and doing such things with it would hardly be risk free. Those that don't understand that, I can't help.