• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Development Update - July 30th

eduffield

Core Developer
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.

B4tP9t9AaYNZxAmX79fmUMB8feBgGM9CxZTVEL_nLTfRUXHxHcM1YhQuPy15XAeKADp848ysHRrdG90bVRlKlGvEGhPl0lmEhnLfiQW-yNUR4TlUlxFkZzEEDP0UWuo3ew


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

81EiUCo3C-lNgnA5QTlEOQPBMaAPLhnOptGaNWZxnOxD4KBE5s85Newx33WOZ_JYhZ_P2BV2BuFXmGgYzarIoEBOcGitRdQPynsHb7eMbIXlAWFUQ85BBifzRpp5x63RLA


Here you can see the client automatically denominating money:

I-NIrQrQTUPQ1ghG0A3B4LPyE4ABOlJ6rEWIozb60W0nG_y7npr40gMoX9EPlwGMHhNc6r2pMUmHKZ4QhvIv8s3rssWOih7KgQIL8ARxR4KloF6535dXC0GlBRqivBFNRw


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.

bljhZYMYIai601mpoOsyW5cO_ovuCIy4pXHjmxIcfQ__VYbn5d8-YhQfpukBNdk0EO64rHjlfjf7ByTD08wts11ehyimFEPv9IzSCpwCVdVbGNOBkDgD9HzcnH1EC0T3Zw



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.
 
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.
 
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)?
 
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.
 
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.)
 
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.
 
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 ?
 
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.
 
Last edited by a moderator:
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.
 
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.
 
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.
 
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 :grin::grin:
 
It is weird, but I think I'll kind of miss the collective excitement surrounding the forks... well, not really :grin::grin:
There will probably still be a lot of collective excitement when 'enforcing' will be switched on on mainnet!
 
Back
Top