Author

Topic: Does Darkcoin's DarkSend trust model actually work? (Read 1182 times)

legendary
Activity: 1176
Merit: 1036
Dash Developer
I just read the Darkcoin white-paper - it is good to see a coin implementing distributed mixing at a protocol level (as far as I understand it, the mixing is done partly at a protocol (using scripts), partly at a client level). However, I may be missing something, but I don't see the trust model being proposed being as solid as suggested. Network discipline is achieved through the arbitration of miners - the last two miners to work on the block decide whether a master node or whatever has handled the transaction properly, and if they both decide he/she hasn't they can take a forfeit from him (which is effectively held in deposit). The paper suggests that collusion between miners would be discouraged because: "In that case the pools users would learn of this and stop using that pool." - but this just doesn't ring true. Relying on pool members (who are making a profit from their pool's dishonesty) to make an ethical decision to switch pools? The users actually submitting the transactions - unless Darkcoin's infrastructure is substantially different from Bitcoin's - will have no say over who does and doesn't get to mine the block with their transaction on it, and so can't choose not to use certain miners; the only mode of volition available to them is to not use the coin, and it's a mode they'll willingly subscribe to. As I say, I may be missing something, but it looks like miner collusion can not be prevented.

Also, especially in the early days when uptake is low, the system seems to be relying on users voluntarily running scripts to send dummy payments to their own addresses, in order to fill up the slots in joined transactions, increasing anonymity and getting those transactions turning around faster. This seems not only highly optimistic, but also otiosely resource intensive - as well as accelerating difficulty increase and potentially shortening the march to the altcoin gallows. Though this be a pedantic grievance, and I'm certain in practice there shouldn't be too many problems if such scripts are by default enabled at a client level.

Lastly, forgive my ignorance, but the white-paper mentioned nothing about how those issuing transactions keep the exact recipient of their transactions secret from the master node - though I'd be very surprised if there isn't a mechanism for that built in; the details are probably in the CoinJoin paper.


Thanks for the questions. It does seem like you're missing something. Although, it might not be your fault. The whitepaper is definitely out of date. We've done a lot of work at tweaking the trust model so that it can't be exploited. I'll try to explain how it works briefly, then hopefully if I get time I can revisit the whitepaper soon.

- Masternodes don't have any power over the transactions. They just coordinate the signing. All parties must sign in order for the transaction to be valid. So there's no way to cheat and take the money.
- Users submit collateral. At a later phase if a user doesn't provide the signature as agreed, the transaction will fail. Without colateral this could be done over and over bringing the system to a halt.
- Masternodes have the ability to take the collateral transaction if they wish, but it's paid to the bounty fund. So it doesn't benefit them, it just benefits the community. This removed the incentive to cheat and take the money.

There's no relying on pools at all anymore. Payments to masternodes are done with a voting system embedded into the blockchain. It would take 51% of the mining power to pay the wrong masternode, or another party (because the last few miners to solve blocks must agree on who should be paid)

Transaction currently require 3 parties to be created, so there's a short wait. There are no fake transactions to make that quicker, although this could be done. There's usually 5 or so transaction per 2.5 minutes, so the network should be able to function pretty efficiently under these requirements.

Hoping that helps . Thanks,

Evan
hero member
Activity: 658
Merit: 500
I'm surprised no one's responded to this. Any DRK dev people wanting to comment or allay R160K's concerns? (eduffield or InternetApe perhaps?)
newbie
Activity: 18
Merit: 4
I just read the Darkcoin white-paper - it is good to see a coin implementing distributed mixing at a protocol level (as far as I understand it, the mixing is done partly at a protocol (using scripts), partly at a client level). However, I may be missing something, but I don't see the trust model being proposed being as solid as suggested. Network discipline is achieved through the arbitration of miners - the last two miners to work on the block decide whether a master node or whatever has handled the transaction properly, and if they both decide he/she hasn't they can take a forfeit from him (which is effectively held in deposit). The paper suggests that collusion between miners would be discouraged because: "In that case the pools users would learn of this and stop using that pool." - but this just doesn't ring true. Relying on pool members (who are making a profit from their pool's dishonesty) to make an ethical decision to switch pools? The users actually submitting the transactions - unless Darkcoin's infrastructure is substantially different from Bitcoin's - will have no say over who does and doesn't get to mine the block with their transaction on it, and so can't choose not to use certain miners; the only mode of volition available to them is to not use the coin, and it's a mode they'll willingly subscribe to. As I say, I may be missing something, but it looks like miner collusion can not be prevented.

Also, especially in the early days when uptake is low, the system seems to be relying on users voluntarily running scripts to send dummy payments to their own addresses, in order to fill up the slots in joined transactions, increasing anonymity and getting those transactions turning around faster. This seems not only highly optimistic, but also otiosely resource intensive - as well as accelerating difficulty increase and potentially shortening the march to the altcoin gallows. Though this be a pedantic grievance, and I'm certain in practice there shouldn't be too many problems if such scripts are by default enabled at a client level.

Lastly, forgive my ignorance, but the white-paper mentioned nothing about how those issuing transactions keep the exact recipient of their transactions secret from the master node - though I'd be very surprised if there isn't a mechanism for that built in; the details are probably in the CoinJoin paper.
Jump to: