Development Update - July 30th

[eduffield]

Darksend+ Progress:

We’re making steady progress on Darksend+ and testing is coming closer to an end.

The GUI now supports sending any amount instantly and anonymously. All you have to do is let the client automatically denominate your funds by leaving it open. Currently mixing depth can be configured with a command line option, but a configuration option in the GUI will be added as work progresses.

The user now has the option to select whether not they would like to send only coins which have been anonymized by Darksend+, only coins which have NOT been anonymized by Darksend+, or a mix of both.

Using coincontrol, you can now see how many times specific inputs have passed through the Darksend process:

Here you can see the client automatically denominating money:

We’re in the process of removing all of the bugs in the software. This was a complete rewrite of the system, which has put us slightly behind schedule for release (a complete rewrite was not what we originally intended to do). As it stands currently, we have a few issues left to address before we can release RC4 on mainnet:

• Ensure that Darksends have at least 1 of each input and so that unique change addresses are used, further improving anonymity
• Add functionality for locked wallets to prompt the user to temporarily decrypt the wallet so that funds can be denominated
• Daemons need to deal with encrypted wallets
• Rewrite all functions that send money so that they only use denominated money or non-denominated money
• Track down an unknown bug causing Darksend collateral to be taken from users during the auto-denomination process. Darksend uses collateral to prevent malicious users from joining a Darksend transaction and then failing to sign. In this case, the client is refusing to sign because it believes there is missing data in the transaction when there is not (or the Masternode is not compiling the transaction correctly and the user is correct not to sign).
• Complete testing on the Masternode voting system
• Add auto-detection of wallets from pools and exchanges in order to disable Darksend

Considering all of the work that needs to be done, we’re looking at a release in early August.

IP Obfuscation:

IP Obfuscation is a critical part of the anonymity package that Darkcoin will bring to bear. Though completion and release of RC4 is our primary concern at the moment, we do have a working roadmap for the implementation of IP obfuscation.

Here’s how it works:

Anyone on the Darkcoin network will be able to communicate securely by using the Masternode network and our encrypted transit system. A user who would like to transmit a payment securely will encrypt the message in such a way that only specific Masternodes can decrypt it.

The user’s client will select three Masternodes, then use the privkey from each of those nodes to wrap the message it wishes to send in three successive encrypted containers. These containers can only be decrypted by their associated Masternodes.

Once wrapped in these three containers, the client will send the encrypted package to the Masternode that corresponds to the outermost encryption layer (Masternode 1). Upon receiving it, Masternode 1 will decrypt the outermost layer in order to learn the identity of the second Masternode in the sequence. Masternode 1 will then relay the message to Masternode 2, which will decrypt the 2nd encryption layer and learn the identity of the third Masternode in the sequence. Masternode 2 forwards the package on to Masternode 3, which decrypts the innermost encryption layer, gaining access to message itself. Masternode 3 then broadcasts the message to the network, and far as the network is concerned, that is where the message originated.

With this envelope encryption system, Masternode 1 is not able to determine which Masternode will ultimately broadcast the message. Similarly, Masternode 3 is unable to determine the identity of either the first Masternode in the sequence or of the original sender.

Darkcoin.io Overhaul:

We’ve been looking at ways to keep the official website darkcoin.io more up to date. Fernando (from the darkcointalk boards) is heading up an effort to overhaul the site, with the following goals in mind:

• Move the site from Github to Wordpress
• Bring the theme in line with current Darkcoin properties
• Engage more people to maintain and update the website. By using Wordpress, we hope to enable non-developers to work on the site so that devs can concentrate on coding Darkcoin.
• Streamline the overall structure of darkcoin.io
• Aim for release of the new site with a timescale measured in weeks vs. months

Please feel free to join the discussion and offer your feedback here: http://goo.gl/LkqrlZ

Wallet Overhaul:

DRKLord, Minotaur, Raze et al continue their efforts on refinement of the Darkcoin wallet UI, and they are closing in on a completed design. Its release will likely be separate from RC4. You can follow their efforts and offer your feedback here: http://goo.gl/1yFUEb.

 

[clayop]

Will you also apply I2P or TOR to masternodes? And in my opinion, as whitepaper of RAZOR points out, IP-address matching may be one of our concern.

 

[defunctec]

Will you also apply I2P or TOR to masternodes? And in my opinion, as whitepaper of RAZOR points out, IP-address matching may be one of our concern.

Masternodes will Obfuscate your ip.

 

[daaarkcoins]

IP-address matching may be one of our concern.

As I can only guess what you mean by "IP-address matching", I'd say that the proposed IP obfuscation mechanism solves that. It's actually the concept of Tor ported to the masternode network.

 

[clayop]

Thanks for wise answers to a stupid question

 

[ichigo13]

Some questions that I need clarification :
1. Will the coins be anonymized once and then sit in the wallet or will they be joining anonymity rounds at specific intervals ?
2. Will the anonymization process cost a fee to the users or will it be free cause it is build-in?
3. Is there a way for the Masternode number 2 at the IP obfuscation to link to the original user since he got the information from Masternode 1 and knows that the message is going to Masternode 3 that is going to publish that message ? Basically can anyone see the original IP of the user from Masternode 1 except from M1 (if that information is actually relayed to M1)?

 

[daaarkcoins]

3. Is there a way for the Masternode number 2 at the IP obfuscation to link to the original user since he got the information from Masternode 1 and knows that the message is going to Masternode 3 that is going to publish that message ? Basically can anyone see the original IP of the user from Masternode 1 except from M1 (if that information is actually relayed to M1)?

The only way for MN 2 to know the IP of the sender is by MN 1 deliberately telling it. In the same way MN 3 can only know the sender's IP if MN 1 and MN 2 passed on that information. So for the sender to be exposed all 3 MNs would have to be compromised / owned by the same entity.
But as the 3 MNs are chosen by the sender, one can apply certain selection criteria to make that scenario less likely. This problem applies to Tor and I2P as well and they have some nifty methods (that can be ported to DRK) to mitigate the risk of choosing an all-compromised chain of nodes.

 

[fusecavator]

Some questions that I need clarification :
1. Will the coins be anonymized once and then sit in the wallet or will they be joining anonymity rounds at specific intervals ?
2. Will the anonymization process cost a fee to the users or will it be free cause it is build-in?
3. Is there a way for the Masternode number 2 at the IP obfuscation to link to the original user since he got the information from Masternode 1 and knows that the message is going to Masternode 3 that is going to publish that message ? Basically can anyone see the original IP of the user from Masternode 1 except from M1 (if that information is actually relayed to M1)?

The coins will be mixed at intervals until they've been mixed a certain amount of times, then they will just sit.

Standard fees apply to mixing I think.

Masternode 1 will know where the user is connecting from, but won't know anything about what drk addresses are involved, as it is only receiving the address of another masternode, and a chunk of encrypted data to pass on. Masternode 2 won't know anything about the user or transaction since it only is connecting to m1 and m3, and it's data only decrypts to what m3 to use, and another chunk of encrypted data to pass on. Masternode 3 will know what drk addresses are involved, but not where the user connected from.

The onion routing is a nice touch, although it'd be nicer if mn 1 and 2 wouldn't know if they where the first or second stage, although I don't see that happening as the user most likely isn't registered as a mn also, so the user could easily be seen as not a masternode. An option to force a mn1 of your choice would be a nice touch though, so you can always use one you trust(ex your own.)

 

[ichigo13]

The coins will be mixed at intervals until they've been mixed a certain amount of times, then they will just sit.

Standard fees apply to mixing I think.

Ok nice. What is the standard fee btw?

Masternode 1 will know where the user is connecting from, but won't know anything about what drk addresses are involved, as it is only receiving the address of another masternode, and a chunk of encrypted data to pass on. Masternode 2 won't know anything about the user or transaction since it only is connecting to m1 and m3, and it's data only decrypts to what m3 to use, and another chunk of encrypted data to pass on. Masternode 3 will know what drk addresses are involved, but not where the user connected from.

The onion routing is a nice touch, although it'd be nicer if mn 1 and 2 wouldn't know if they where the first or second stage, although I don't see that happening as the user most likely isn't registered as a mn also, so the user could easily be seen as not a masternode. An option to force a mn1 of your choice would be a nice touch though, so you can always use one you trust(ex your own.)

The only way for MN 2 to know the IP of the sender is by MN 1 deliberately telling it. In the same way MN 3 can only know the sender's IP if MN 1 and MN 2 passed on that information. So for the sender to be exposed all 3 MNs would have to be compromised / owned by the same entity.
But as the 3 MNs are chosen by the sender, one can apply certain selection criteria to make that scenario less likely. This problem applies to Tor and I2P as well and they have some nifty methods (that can be ported to DRK) to mitigate the risk of choosing an all-compromised chain of nodes.

Recently there was an "attack" on the Tor network by researchers that tried to see if they could anonymize Tor users. I was just worried about the IP obfuscation so that we don't inherit open holes from the Tor network (even though I am not sure in what way the "attack" on Tor was conducted and if it is inheritable by adopting the same style on our IP obfuscation).

Thank you for your answers btw.

 

[george9178]

Will the RC4 need a harkfork?If need, will it fail again?

 

[5kmi]

Info regarding the Tor "attack" https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack

And no... No need for hardforks now.... Our amazing devs created the spork!

 

[tungfa]

So we stay on Spork for the long run, no need to go to Fork (hard or soft) ???
I believe and read (really do not know enough about all this to be honest) that we need a hard fork eventually ?
Any truth in this ?

 

[5kmi]

Spork="soft" fork. Update will be released, once a large majority updates or "complies" with the new network standards, the update can be "enforced" (soft fork) with minimal risk to the network. As far as I understand it anyway.... Someone feel free to correct me or elaborate.

 

[acidburn]

But the soft fork would mean any features won't work at time of release surely?

 

[coltan]

So what? Do you prefer a hard fork?

 

[vertoe]

But the soft fork would mean any features won't work at time of release surely?

There are no changes to the block reward subsidity, difficulty or payouts or whatever. So we wont need any fork soon. Lean back and relax. The forks are already behind us.

 

[daaarkcoins]

Spork="soft" fork. Update will be released, once a large majority updates or "complies" with the new network standards, the update can be "enforced" (soft fork) with minimal risk to the network. As far as I understand it anyway.... Someone feel free to correct me or elaborate.

The act of enforcing IS a hard fork. The difference is that we don't need clients to update at the time of the fork so it is much easier to deal with any problems in case they occur.

 

[vertoe]

The act of enforcing IS a hard fork. The difference is that we don't need clients to update at the time of the fork so it is much easier to deal with any problems in case they occur.

technical speaking yes, but introducing the changes much earlier without enforcing them is a well prepared soft fork with low impact on the network.

 

[fernando]

There are no changes to the block reward subsidity, difficulty or payouts or whatever. So we wont need any fork soon. Lean back and relax. The forks are already behind us.

It is weird, but I think I'll kind of miss the collective excitement surrounding the forks... well, not really

 

[BelStar]

It is weird, but I think I'll kind of miss the collective excitement surrounding the forks... well, not really

There will probably still be a lot of collective excitement when 'enforcing' will be switched on on mainnet!

 

[tungfa]

i am generally excited about all this
but i only posted that fork question, as i understood it was kind of a problem.
Spork or Hardfork senario, but if you guys tell me to chill and live with the Spork,
so i will ....>>
and did not want to distract from the great update from the MASTA himself (above) ...>

 

[orbitboy]

As I can only guess what you mean by "IP-address matching", I'd say that the proposed IP obfuscation mechanism solves that. It's actually the concept of Tor ported to the masternode network.

and without any equivalent of a browser footprint to track.

EDIT : I'm looking for a few thousand burly workers to commence a 400/500 year, multi-generational project in building a group of huge monstrous monolithic stone structures in various parts of the world honoring his Galactic Prime Duffness. I'll be drawing up plans shortly.

 

[crowning]

IP Obfuscation:
[...]
The user’s client will select three Masternodes, then use the privkey from each of those nodes to wrap the message it wishes to send

I would prefer to use the public key...

 

[5kmi]

I would prefer to use the public key...

I had this thought as well. How would the user client acquire the privkeys of these masternodes without risking the security of the given masternodes?

 

[nj47]

I would prefer to use the public key...

Well ECDSA encryption (what darkcoin and bitcoin use) is not the same as an asymmetric encryption such as PGP, which you may be more familiar with. You cannot give someone a bitcoin public address and have them use that to encrypt a message. You can, however, encrypt a message with the private key and decrypt it with the public key.

I had this thought as well. How would the user client acquire the privkeys of these masternodes without risking the security of the given masternodes?

Evan didn't mean the same private key associated with the actual masternode address itself I would not imagine.

eduffield If my assumptions were correct, I would be curious and slightly concerned with the performance impact this could have on masternodes. This would mean masternodes would readily be accepting incoming connections which would force them to use a non-trivial amount of processing power to decrypt. This may open up a new DDOS vector. As for mitigation, you could just rate-limit how many incoming connections you would be willing to accept, but then instead of the MN itself being DDOS'ed, the network would be DDOS'ed and there would be no room for valid entries.

IP obfuscation is an interesting problem because it is so _easy_ to solve on an individual level but so challenging to solve on a protocol level. However I do think it is important to solve on a protocol level. Whatever can be done to make the process as seamless for the user is critical.

I did have one potential alternative solution I came up with a while back, though my implementation is only high-level and I am not confident all the details would click in reality. However, the way I see it, the darkcoin network, as a whole, essentially is a P2P mesh. When you broadcast a transaction, you send it to any node, who then forwards it on again and again. However, this mesh network could be utilized slightly more. Instead of openly broadcasting a transaction to the network, what we could do would be to attach another variable (HOP_COUNT_REMAINING) to a transaction and only broadcast it to one node. When a node receives the transaction, it decrements HOP_COUNT_REMAINING, and sends it to another node. Because the starting HOP_COUNT_REMAINING is random, no one, not even the original node who received the transaction, would have any idea at which point in this chain they were. And not until the hop count reached 0 would the transaction actually be pushed onto the open network as a transaction. There clearly are some issues with this, but it is just something to think about!

 

[yidakee]

I would prefer to use the public key...

MN privkeys are not the same as the wallet's. The command "masternode genkey" issues the masternode an identifier to the network. The flag is "masternodeprivkey=" and only serves that purpose

 

[fusecavator]

Ok nice. What is the standard fee btw?

It can vary depending on the size of the transaction data, so there is no simple answer for this.

Recently there was an "attack" on the Tor network by researchers that tried to see if they could anonymize Tor users. I was just worried about the IP obfuscation so that we don't inherit open holes from the Tor network (even though I am not sure in what way the "attack" on Tor was conducted and if it is inheritable by adopting the same style on our IP obfuscation).

Thank you for your answers btw.

The attack you are referring to is not likely. In that attack, malicious nodes nodes were encoding identifiers into a spot in the header of data being sent. Other malicious nodes would later be able to decode that data to identify that it was the same chunk seen earlier. When the attacker had a lot of nodes, this allowed the attacker to find out what user ip was connecting to service ip, but only when both the first and last nodes were owned by the attacker. The attacker still couldn't read any of the data being sent, they could only see that a connection occurred. Since the attack is about abusing the ability to encode some data into headers, the problem is not with the idea, but the implementation.

In the darkcoin version, the protocol will most likely be much simpler than tor, which results in less places to attempt to hide things, and should be easier to secure. Without a place to stash data, in order to identify an ip to an address, the attacker would have to own all masternodes involved(3 for obfuscation + selected masternode). Since coins are mixed several times before being used, even if the attacker was to get lucky and have a transaction go through only nodes owned by them, it wouldn't likely tell them much, as it would only be one step of mixing they see. For an attacker to be lucky enough to see a whole set of mixing cycles for some coins, they'd have to own a significant portion of all masternodes, which would be very costly.

 

[illodin]

Because the starting HOP_COUNT_REMAINING is random, no one, not even the original node who received the transaction, would have any idea at which point in this chain they were. And not until the hop count reached 0 would the transaction actually be pushed onto the open network as a transaction. There clearly are some issues with this, but it is just something to think about!

The first node would know the originator because it's not any of the masternodes?

 

[nj47]

The first node would know the originator because it's not any of the masternodes?

Nope, I wasn't talking about masternodes, I was talking about normal wallets. It has to be normal wallets instead of masternodes for that reason

 

[Carrot]

OMG this stuff is getting crazy complicated. I can see surely now where the boys get separated from the men in the sense that the coins that are intellectually unchallenging, but market blingy scam thingy rich will die soon and this coin will thrive. With emerging markets and ecosystems so rich in thought provoking ideas and innovation this Darkcoin is going to bring what the world has yet to see. Dang this is just plain exciting. Thanks for letting me buy enough at first to be a part of this, and contribute to what I am certain will be part of the future.