Re: [ANN][DRK] DarkCoin | First Anonymous Coin | First X11 | First DGW | RC4 Testing
Unless I have to register on the forums of DRK and ask there, I would like to get some input from Evan or some developer on this.
Anyone considering this FUD or something is an ignorant idiot. This is just objective input from another developer who obviously has high knowledge.
There are two things that concern me:
1. Outputs can still be linked to addresses. If you send 20 DRK and it sends all these other outputs along with it to obfuscate, the 20 DRK still ends up in someone's address. That this can be observed on the blockchain means that analysis is easy, and we all know how often people leak addresses associated with their wallet (eg. posting it up for giveaways etc. etc.) This is an immutable problem in any Bitcoin-forked cryptocurrency that exists, as the solution (stealth addresses computed w/random data) has to be enforced for every transaction from the genesis block. If you enforce it halfway through you're stuck with old outputs that don't use stealth addresses, which makes it exceedingly complex to ensure the anonymityset is not at-risk.
2. Masternodes are an Achilles' heel. Let us say that there are 10 000 masternodes on the network. Their IP addresses and the port they operate on is, by necessity, known to the network. Let's assume that an attacker controls 5 masternodes of the 10 000. Let's also assume that each of the masternodes on the network is on a dedicated server (none of them use a VPS, because a VPS could be trivially owned by the host operating system) and each of these servers is on a 1gbps unmetered, dedicated port (clearly not the case right now, but I'm talking about a future time). How hard would it be for an attacker to knock the other 9995 masternodes off the network, leaving theirs as the only accessible masternodes (and thus not only earning them all the fees, but giving them perfect insight into transactions moving within their controlled group)? Well, NTP amplification attacks have let attackers launch 400Gbps attacks against a single machine from a sole 2mbps connection. SNMP has a theoretical 650x amplification factor. All an attacker needs to do is max out the unmetered port in an obvious attack, and the datacenter will have to react. Even straight up LOIC-style / botnet SYN floods to the port that the masternode has open will lead to the the DC null-routing traffic to that box, typically for 6 hours whilst they wait for the attack to stop. Mitigating this is an extremely difficult and expensive operation for each masternode to individually undertake, and not all DCs will even be able to provide DDoS mitigation at this level. An unsophisticated attacker using extremely traditional tools can knock all of the masternodes off the network except those they control. This is a threat to anonymity.
Incidentally, the other problem with masternodes that nobody seems to have thought of is that the limited number of them will mean they're in direct competition with each other. It is in a masternode operator's financial interests to make life difficult for the rest of them - DDoS attacks, reporting the box to the datacenter, anything that can knock a single competitor off the masternode network means more fees for the remaining masternodes. This is different to PoW mining where, for instance, knocking the pools offline doesn't mean you'll get more transaction fees, as miners always have backup pools. I'm not sure how sustainable this is as a system if it unmistakably pitches operators against each other to fight for fees. Given the cost and capital required to own a masternode, it's appreciable that this will happen as a natural result of wanting to maximise masternode profits.
1. Outputs can still be linked to addresses. If you send 20 DRK and it sends all these other outputs along with it to obfuscate, the 20 DRK still ends up in someone's address. That this can be observed on the blockchain means that analysis is easy, and we all know how often people leak addresses associated with their wallet (eg. posting it up for giveaways etc. etc.) This is an immutable problem in any Bitcoin-forked cryptocurrency that exists, as the solution (stealth addresses computed w/random data) has to be enforced for every transaction from the genesis block. If you enforce it halfway through you're stuck with old outputs that don't use stealth addresses, which makes it exceedingly complex to ensure the anonymityset is not at-risk.
2. Masternodes are an Achilles' heel. Let us say that there are 10 000 masternodes on the network. Their IP addresses and the port they operate on is, by necessity, known to the network. Let's assume that an attacker controls 5 masternodes of the 10 000. Let's also assume that each of the masternodes on the network is on a dedicated server (none of them use a VPS, because a VPS could be trivially owned by the host operating system) and each of these servers is on a 1gbps unmetered, dedicated port (clearly not the case right now, but I'm talking about a future time). How hard would it be for an attacker to knock the other 9995 masternodes off the network, leaving theirs as the only accessible masternodes (and thus not only earning them all the fees, but giving them perfect insight into transactions moving within their controlled group)? Well, NTP amplification attacks have let attackers launch 400Gbps attacks against a single machine from a sole 2mbps connection. SNMP has a theoretical 650x amplification factor. All an attacker needs to do is max out the unmetered port in an obvious attack, and the datacenter will have to react. Even straight up LOIC-style / botnet SYN floods to the port that the masternode has open will lead to the the DC null-routing traffic to that box, typically for 6 hours whilst they wait for the attack to stop. Mitigating this is an extremely difficult and expensive operation for each masternode to individually undertake, and not all DCs will even be able to provide DDoS mitigation at this level. An unsophisticated attacker using extremely traditional tools can knock all of the masternodes off the network except those they control. This is a threat to anonymity.
Incidentally, the other problem with masternodes that nobody seems to have thought of is that the limited number of them will mean they're in direct competition with each other. It is in a masternode operator's financial interests to make life difficult for the rest of them - DDoS attacks, reporting the box to the datacenter, anything that can knock a single competitor off the masternode network means more fees for the remaining masternodes. This is different to PoW mining where, for instance, knocking the pools offline doesn't mean you'll get more transaction fees, as miners always have backup pools. I'm not sure how sustainable this is as a system if it unmistakably pitches operators against each other to fight for fees. Given the cost and capital required to own a masternode, it's appreciable that this will happen as a natural result of wanting to maximise masternode profits.
Anyone considering this FUD or something is an ignorant idiot. This is just objective input from another developer who obviously has high knowledge.
Very good questions. I'm excited that we're starting to see some higher level questions again.
1.) Payee addresses are arguably the less important aspect of privacy. As the sender, it's more important to protect your identity. The other side can simply be addressed by generating a new change address per payment. Between the two of these the system would be completely anonymous. Also, after receiving payment, your client will prepare the funds again, increasing their anonymity.
2.) There's not a perfect solution to this yet, but Masternode operators have an interest in getting more darkcoin and keeping their existing inventment as valuable as possible. By attacking the network, they would cause harm to their investment. Also, the client is resistant to DDOS attack currently and masternode operators are instructed to close all other ports and have some kind of DDOS protection.
As a longer term solution, we could not broadcast the IPs of masternodes, but an identifier. Users could then say they want to broadcast to that masternode, but not actually connect to it. This would hide the identities and create a much more robust system.
+1 Great idea for the identifiers. We should expect more attacks and prepare for all possible eventualities. I had to fend off a hacking attempt already right after announcing the plans for the charity and have switched to cold storage for now. They also announced it is now illegal to create a charity to eliminate or prevent poverty in Canada around that time and after consultation with a few lawyers it looks like we are going non profit at least for now. The website is completed and we are just waiting on legal protection before hosting it. Thanks for your understanding and patience.
For 2): could a periodic shifting proxy be incorporated and automatically assigned into the client, that way the identifier could stay the same and the IP address vulnerability could be virtually eliminated by switching it regularly to another one. This could also protect from physical attacks on locations hosting master nodes by confusing anyone looking for them? Also, it would probably be confusing tring to attack masternodes who's IP addresses are shifting every few minutes at randfom intervals.
Maybe eventually for clients a permission could also be granted to automatically modify parameters on machines hosting the clients to maximize and assure security or the system since what is needed is quite standard, even possibly automatically setting up a proxy system based on the masternodes system, for example when a masternode shifts to a new proxy it shares that proxy setup with the clients that are connected, that way clients could also randomly shift IP of the systems they are connected to....
musing thoughts... Thanks!