Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

Development Update - July 30th

Discussion in 'Official Announcements' started by eduffield, Jul 30, 2014.

  1. eduffield

    eduffield Core Developer

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,319
    Trophy Points:
    183
    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.

    [​IMG]

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

    [​IMG]

    Here you can see the client automatically denominating money:

    [​IMG]

    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.

    [​IMG]


    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.
     
    • Like Like x 33
  2. clayop

    clayop Member

    Joined:
    May 13, 2014
    Messages:
    77
    Likes Received:
    29
    Trophy Points:
    58
    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.
     
  3. defunctec

    defunctec Member

    Joined:
    Jul 11, 2014
    Messages:
    103
    Likes Received:
    36
    Trophy Points:
    78
    Masternodes will Obfuscate your ip.
     
    • Like Like x 1
  4. daaarkcoins

    daaarkcoins Member

    Joined:
    May 21, 2014
    Messages:
    95
    Likes Received:
    40
    Trophy Points:
    68
    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.
     
    • Like Like x 1
  5. clayop

    clayop Member

    Joined:
    May 13, 2014
    Messages:
    77
    Likes Received:
    29
    Trophy Points:
    58
    Thanks for wise answers to a stupid question ;)
     
    • Like Like x 1
  6. ichigo13

    ichigo13 Member
    Masternode Owner/Operator

    Joined:
    Jul 6, 2014
    Messages:
    41
    Likes Received:
    29
    Trophy Points:
    58
    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)?
     
  7. daaarkcoins

    daaarkcoins Member

    Joined:
    May 21, 2014
    Messages:
    95
    Likes Received:
    40
    Trophy Points:
    68
    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.
     
    • Like Like x 2
  8. fusecavator

    fusecavator Member

    Joined:
    Jun 4, 2014
    Messages:
    40
    Likes Received:
    38
    Trophy Points:
    58
    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.)
     
    • Like Like x 3
  9. ichigo13

    ichigo13 Member
    Masternode Owner/Operator

    Joined:
    Jul 6, 2014
    Messages:
    41
    Likes Received:
    29
    Trophy Points:
    58
    Ok nice. What is the standard fee btw?

    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.
     
    • Like Like x 1
  10. george9178

    george9178 New Member

    Joined:
    May 22, 2014
    Messages:
    15
    Likes Received:
    0
    Trophy Points:
    1
    Will the RC4 need a harkfork?If need, will it fail again?
     
  11. 5kmi

    5kmi Member

    Joined:
    Jul 21, 2014
    Messages:
    41
    Likes Received:
    19
    Trophy Points:
    58
  12. tungfa

    tungfa Administrator
    Dash Core Team Foundation Member Masternode Owner/Operator Moderator

    Joined:
    Apr 9, 2014
    Messages:
    8,809
    Likes Received:
    6,689
    Trophy Points:
    1,283
    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 ?
     
  13. 5kmi

    5kmi Member

    Joined:
    Jul 21, 2014
    Messages:
    41
    Likes Received:
    19
    Trophy Points:
    58
    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.
     
    #13 5kmi, Jul 31, 2014
    Last edited by a moderator: Jul 31, 2014
    • Like Like x 2
  14. acidburn

    acidburn Active Member

    Joined:
    May 26, 2014
    Messages:
    467
    Likes Received:
    175
    Trophy Points:
    113
    But the soft fork would mean any features won't work at time of release surely?
     
  15. coltan

    coltan New Member

    Joined:
    Jul 7, 2014
    Messages:
    8
    Likes Received:
    1
    Trophy Points:
    3
    So what? Do you prefer a hard fork?
     
  16. vertoe

    vertoe Three of Nine

    Joined:
    Mar 28, 2014
    Messages:
    2,574
    Likes Received:
    1,656
    Trophy Points:
    1,283
    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.
     
  17. daaarkcoins

    daaarkcoins Member

    Joined:
    May 21, 2014
    Messages:
    95
    Likes Received:
    40
    Trophy Points:
    68
    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.
     
    • Like Like x 1
  18. vertoe

    vertoe Three of Nine

    Joined:
    Mar 28, 2014
    Messages:
    2,574
    Likes Received:
    1,656
    Trophy Points:
    1,283
    technical speaking yes, but introducing the changes much earlier without enforcing them is a well prepared soft fork with low impact on the network.
     
    • Like Like x 3
  19. fernando

    fernando Powered by Dash
    Dash Core Team Foundation Member Moderator

    Joined:
    May 9, 2014
    Messages:
    1,528
    Likes Received:
    2,056
    Trophy Points:
    283
    It is weird, but I think I'll kind of miss the collective excitement surrounding the forks... well, not really :D:D
     
  20. BelStar

    BelStar Member

    Joined:
    Apr 17, 2014
    Messages:
    76
    Likes Received:
    86
    Trophy Points:
    58
    There will probably still be a lot of collective excitement when 'enforcing' will be switched on on mainnet!
     
  21. tungfa

    tungfa Administrator
    Dash Core Team Foundation Member Masternode Owner/Operator Moderator

    Joined:
    Apr 9, 2014
    Messages:
    8,809
    Likes Received:
    6,689
    Trophy Points:
    1,283
    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) ...>
     
    #21 tungfa, Jul 31, 2014
    Last edited by a moderator: Jul 31, 2014
    • Like Like x 1
  22. orbitboy

    orbitboy New Member

    Joined:
    Mar 9, 2014
    Messages:
    35
    Likes Received:
    12
    Trophy Points:
    8
    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.
     
  23. crowning

    crowning Well-known Member

    Joined:
    May 29, 2014
    Messages:
    1,428
    Likes Received:
    2,005
    Trophy Points:
    183
    I would prefer to use the public key...
     
  24. 5kmi

    5kmi Member

    Joined:
    Jul 21, 2014
    Messages:
    41
    Likes Received:
    19
    Trophy Points:
    58
    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?
     
  25. nj47

    nj47 Guest

    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.

    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!
     
    • Like Like x 4
  26. yidakee

    yidakee Well-known Member
    Foundation Member

    Joined:
    Apr 16, 2014
    Messages:
    1,812
    Likes Received:
    1,168
    Trophy Points:
    283
    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
     
    • Like Like x 2
  27. fusecavator

    fusecavator Member

    Joined:
    Jun 4, 2014
    Messages:
    40
    Likes Received:
    38
    Trophy Points:
    58
    It can vary depending on the size of the transaction data, so there is no simple answer for this.

    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.
     
    • Like Like x 3
  28. illodin

    illodin Member

    Joined:
    Apr 26, 2014
    Messages:
    122
    Likes Received:
    71
    Trophy Points:
    78
    The first node would know the originator because it's not any of the masternodes?
     
    • Like Like x 1
  29. nj47

    nj47 Guest

    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
     
  30. Carrot

    Carrot Member

    Joined:
    May 26, 2014
    Messages:
    64
    Likes Received:
    21
    Trophy Points:
    48
    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.
     
    • Like Like x 3

Share This Page