Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

Dead Change - an anonymity issue

Discussion in 'Development Tech Discussion' started by Aswan, Nov 20, 2014.

Tags:
  1. oblox

    oblox Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,032
    Likes Received:
    537
    Trophy Points:
    183
    Maybe coins get coinshuffled back? That way, the mixing and sending process is the same but the only change revolves around implementing a coinshuffle protocol for all change. Although I am unsure if the other change inputs (output from the initial send) need to be from others at the same time.
     
  2. paperThin

    paperThin Member

    Joined:
    Jun 13, 2014
    Messages:
    106
    Likes Received:
    19
    Trophy Points:
    68
    The issue is that it is tied by the transaction, not the address. To break this connect would change the basic theory of blockchain. (ie destroy the previous amount and reissue the amount to a new address.) Plus, the amount would be the same and thus suspicious.
     
  3. moli

    moli Grizzled Member

    Joined:
    Aug 5, 2014
    Messages:
    3,261
    Likes Received:
    1,837
    Trophy Points:
    1,183
    Ok, paperThin, now this leads to my next question. I may sound silly and crazy here but this has been in my mind for some time. What if someone can create a crawler to crawl the blockchain and connects all the transactions leading back to the origin?
     
  4. paperThin

    paperThin Member

    Joined:
    Jun 13, 2014
    Messages:
    106
    Likes Received:
    19
    Trophy Points:
    68
    If the client requires(forces) 2 rounds of DS mixing, then the process "jar mix" could simply be the first round of DS... the client could automatically DS mix the resulting whole numbers to the required (2x) or more times as the user specifies.
     
  5. paperThin

    paperThin Member

    Joined:
    Jun 13, 2014
    Messages:
    106
    Likes Received:
    19
    Trophy Points:
    68
    Easy to do. The blockchain is public so the crawler is basically already there. The part that makes it anonymous is 2 parts.
    • First, there (should not be) any connection to someone's personal ID and the address. (Bitcoin has this)
    • Second, by mixing our balances between many people (using the same denominations 1, 10, 100 etc), the effort to backtrack leads to more difficult to trace at each layer. (DRK has this)
    (Hey, I'm no expert, but this is how I understand it!)
     
  6. Aswan

    Aswan Member

    Joined:
    Jun 26, 2014
    Messages:
    68
    Likes Received:
    216
    Trophy Points:
    73

    Of course there is nothing stopping darksend denominations from further being used in the darksend anonymization process.
    In fact I took it as granted that we both think that would be a natural thing to do. But that doesn't change anything.
    The transaction in question (the one you dont want to be linked to your name) happened before the jar mix process, making the jar mix Tx the gateway to the Tx in question. What you do after the jar mix Tx doesn't change anything regarding the traceability of the Tx in question when following the dead change up to the jar nix Tx.

    But I still think your solution is good if there are a lot of participants (50+ at leave, each providing 2+ inputs).The only problem is the fact that a single malicious masternode could cause problems
     
  7. moli

    moli Grizzled Member

    Joined:
    Aug 5, 2014
    Messages:
    3,261
    Likes Received:
    1,837
    Trophy Points:
    1,183
    Yes, DRK has the advantage of "plausible deniability" which is cool.
     
  8. paperThin

    paperThin Member

    Joined:
    Jun 13, 2014
    Messages:
    106
    Likes Received:
    19
    Trophy Points:
    68
    I think follow regarding the single TX being the issue here. Providing I did a 4x DS mix prior to all private transactions. Then I did several separate private transactions. Then the "jar mix". Finally 4x DS mix with the whole numbers and put the dead change aside. Now, spending the whole numbers is not a problem, but the weakness was the one transaction at the point of the jar mix. The issue is not connected with past spending (pre 4x) and not connect with future spending (post 4x), but the problem is the linking of the private transactions together in that single tx, right?
    (I just want to make sure I am on the right track.)

    I originally had thought that 3 participants would be enough. Am I correct to think that normal DS mixing is with 3 participants? Maybe 3 participants could be enough to have "plausible deniability" (as moli pointed out), but not really very secure. 50 participants would be much better. I can imagine that 50 people x 6 transactions (minimum) would be mixed well. I understand your point about the malicious node. Since it happens all in one transaction it is more exposed. A single entity (malicious node) would know exactly which dead change came in together.

    Thanks again for your input. I am going to chew on this idea a bit and see if I can come up with anything!
     
  9. Aswan

    Aswan Member

    Joined:
    Jun 26, 2014
    Messages:
    68
    Likes Received:
    216
    Trophy Points:
    73
    Exactly!

    Normal DS is 3 participants per round right now. It can be increased once there are enough people using it but right now, it would take way too long with more than 3 ppl being required.
    However, since there are multiple rounds it's fine.
    Of course more participants would be better. the jar mix would be risky with 3 participants since it's only one round. With more participants I think it could work, but we need to fix the malicious masternode issue.
     
  10. moli

    moli Grizzled Member

    Joined:
    Aug 5, 2014
    Messages:
    3,261
    Likes Received:
    1,837
    Trophy Points:
    1,183
    Hm... I just checked through my Testnet wallet and see that the "Payment to Yourself" fee 0.10 does not show up in my transactions. Unless you look at the PTY fee transaction ID from your wallet, you can't see that this fee is tied to your origin address, because it's not showing up on any of my transactions. This is testnet, but it should be the same like on mainnet. Could someone else check also to make sure, thanks.

    I'm thinking if this is the case, can Evan make the change to be similar to PTY fee? and this will be solved? Thanks.
     
  11. oblox

    oblox Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,032
    Likes Received:
    537
    Trophy Points:
    183
    That's going to the miners and is added to the block reward. There isn't a way to break it and be able to have the change come back to you in that case.
     
  12. paperThin

    paperThin Member

    Joined:
    Jun 13, 2014
    Messages:
    106
    Likes Received:
    19
    Trophy Points:
    68
    Oblox,

    I posted this on the v.16 thread... do you know these answers?

    Hey All,

    I have 2 stupid questions if someone could enlighten me!
    1. How does the new DS mix work so that the fees are zero? Who pays the TX fees?
    2. I left my liquidity provider on all weekend and had 39 "Darksend Denominates". Why do my inputs show only "9 rounds"?
    I did 8 rounds DSD on the inputs (Friday) and then started up "liquidity mode" for the weekend. I expected to see 47 rounds this morning, but it only shows 9. I can clearly see in the blockchain that a "round" is occuring (I get a new address with no outputs).
    Thanks in advance!
    [EDIT: I am not asking for a detailed explanation of the code... just the big picture of "how it works"]​
     
  13. oblox

    oblox Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,032
    Likes Received:
    537
    Trophy Points:
    183
    1. Fees are accessed randomly to anyone using darksend. The longer you have it running, the higher the chance you have at getting hit with a random fee.
    2. What L.P. setting did you use? As a liquidity provider, it will randomly choose an amount to anonymize and number of rounds. After hitting 100%, it will send to a new address and start the process over.
     
  14. paperThin

    paperThin Member

    Joined:
    Jun 13, 2014
    Messages:
    106
    Likes Received:
    19
    Trophy Points:
    68
    1. Thanks! Got it!
    2. As LP, it sets the rounds to 999999 automatically. I definitely went 37 rounds because I can look at any one of those transactions. A DSD definitely occurred each time...and a new address each time. It's just that the "# of rounds" shown on my inputs list stayed at 9. I can see all the transactions timestamp and the TX numbers to see they did occur.

    Thanks for the feedback
     
  15. oblox

    oblox Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,032
    Likes Received:
    537
    Trophy Points:
    183
    The LP setting of 37 doesn't mean 37 rounds. It means it will attempt to darksend every 37 blocks, unless Evan adjusted the setting.
     
  16. paperThin

    paperThin Member

    Joined:
    Jun 13, 2014
    Messages:
    106
    Likes Received:
    19
    Trophy Points:
    68
    No, I had 37 "darksend denominates" in my transaction ledger over the weekend. That is 37 separate DSD transactions. (I think I had the liquidity set to 30.) Meanwhile, I had no fees charged at all. Love it!
     
  17. oblox

    oblox Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,032
    Likes Received:
    537
    Trophy Points:
    183
    Ah, yeah, 30 should be somewhere around every 30 blocks it will attempt a DS. Awesome that you ran it that long and didn't get hit. Now if we can resolve this issue as it relates to change, we can move on to instantx.
     
  18. oblox

    oblox Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,032
    Likes Received:
    537
    Trophy Points:
    183
    Bumping this again for exposure so it doesn't get lost under Crouton's rant as this is more pressing.
     
    • Like Like x 2
  19. moli

    moli Grizzled Member

    Joined:
    Aug 5, 2014
    Messages:
    3,261
    Likes Received:
    1,837
    Trophy Points:
    1,183
    I'm wondering if Evan can make any amount under 1 DRK to pair and mix (don't have to be an exact number)... Can it solve the issue?
     
  20. oblox

    oblox Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,032
    Likes Received:
    537
    Trophy Points:
    183
    Well, you could have denominations all the way down to .10, .01, .001, etc at the expense of bloating the chain. At some point, I do believe dust (my definition of anything .001 or lower) should just be sent to the network for the miners/masternodes.
     
  21. paperThin

    paperThin Member

    Joined:
    Jun 13, 2014
    Messages:
    106
    Likes Received:
    19
    Trophy Points:
    68
    I have a couple ideas, but I need to put them together as concisely as I can so that Aswan can destroy them better ;)
    ... still thinking on it!
     
  22. Propulsion

    Propulsion The buck stops here.

    Joined:
    Feb 26, 2014
    Messages:
    1,008
    Likes Received:
    467
    Trophy Points:
    183
    Dash Address:
    XerHCGryyfZttUc6mnuRY3FNJzU1Jm9u5L
    Is anyone still using Aswan? I haven't used that in months.

    Wow mixed up a username with software.

    moli I believe going under 1 drk would cause tremendous bloat.
     
    #82 Propulsion, Nov 25, 2014
    Last edited by a moderator: Nov 25, 2014
    • Like Like x 1
  23. moli

    moli Grizzled Member

    Joined:
    Aug 5, 2014
    Messages:
    3,261
    Likes Received:
    1,837
    Trophy Points:
    1,183
    Propulsion! What should we do?! :)
     
  24. Propulsion

    Propulsion The buck stops here.

    Joined:
    Feb 26, 2014
    Messages:
    1,008
    Likes Received:
    467
    Trophy Points:
    183
    Dash Address:
    XerHCGryyfZttUc6mnuRY3FNJzU1Jm9u5L
    Not sure. A developer would know better. It's an interesting problem.
     
  25. paperThin

    paperThin Member

    Joined:
    Jun 13, 2014
    Messages:
    106
    Likes Received:
    19
    Trophy Points:
    68
    Aswan,

    [Edit: This is not going to work as presented.... but maybe it will spark an idea with someone else that can improve it.]

    Coming back with a second idea... (not "Jar Mix")

    First I need to be clear that I understand this correctly:
    There is some exposure from a single malicious masternode (as the system exists today) at the point of a private purchase if that specific masternode happens to be the one receiving the transaction. Is that right? What is the exposure? Is it just the IP address of the person making the transaction request? Is there any other identifying characteristics? (Of course I realize the blockchain in/out address, but the whole world is able to see that.)​
    Assuming above is correct, then the malicious masternode (using Jar Mix) is able to link 2 completely separate transactions because the user is asking to consolidate them to a single address. This lets a malicious masternode "know and remember" both that the two (output) addresses are linked and where the funds were directed to (input). Other masternodes on the network may see the result to the mix, but only that one MN knows exactly how things were shuffled.

    OK, assuming I have no inaccuracies above, I am presenting a new idea here (new for me):
    Unlike the "Jar Mix" idea, this one requires quite a bit of change in how the Masternodes operate. (That's a negative to this idea.)
    Also, let's assume that DSD is "fixed" to use whole numbers. :)
    • The key here is: All Masternodes only return whole number change on the first step. For example a purchase of 7.25 is made with a 10 DRK address. The buyer receives 2 DRK back in that same transaction while the seller receives the whole 7.25. (0.75 DRK stays with the Masternode for now.)
    • (The 2.0 DRK change is perfectly safe for remixing by the user.)
    • The 0.75 held by the Masternode goes into one(1) of five(5) addresses held by the Masternode. These addresses should rotate new ones in and abandon old ones.
    • The Masternode waits 1, 2, or 3 blocks and then sends 0.75 from any of the 5 addresses to a user address (separate and unused address) through another masternode.
    Of course this Masternode is aware of the complete transaction (Outputs and Inputs), but it is only a single transaction (not 2 linked together) and the rest of the network is not able to detect this as "returned change".
    • I see a weakness here that exposes "strange change" (ie 0.12345 DRK). This would be easy to spot later in the blockchain.
      • Could the MN break the change into pieces and send it from 2 separate addresses?
    • A masternode would be able to shutdown and "keep the change", but it would always be less than 1 DRK that the user would lose. The user would get the bulk of the change (ie whole numbers) in the same transaction, so losses would not be too great. Would it be worthwhile for malicious nodes to startup, steal change, shut down, restart with new ID... etc?
     
  26. oblox

    oblox Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,032
    Likes Received:
    537
    Trophy Points:
    183
    I don't believe this is a worry with the system as is. To do so, you are essentially removing your entry into the masternode list until the new vin is confirmed by a number of blocks equal to approx. the number of outstanding masternodes on the network. By doing so, you are pocketing "change" at the expense of being included in payouts of the block reward until reconfirmed and added back to the list for round robin style selection.

    The change going to a masternode that continues to flow onward to other masternodes randomly is an interesting take. But if it isn't combined at some point, isn't it just a matter of a bread trail to be followed before it returns to an address owned by the same person that sent the change?
     
    • Like Like x 1
  27. paperThin

    paperThin Member

    Joined:
    Jun 13, 2014
    Messages:
    106
    Likes Received:
    19
    Trophy Points:
    68
    Yes, you are right.
    My thought was that if several people are receiving small change back to new addresses then it would be difficult to tell which change corresponded with with each user. By breaking the amounts in pieces, it adds complexity, but probably not enough.
    Simple example: If change due is 0.40 (user 1) and 0.60 (user 2), then 5 payments of 0.20 to 5 separate addresses (2 addresses of user 1 and 3 addresses of user 2).
    But I agree, your point is right... not easy to follow, but does leave a trail of bread crumbs. Still working on it... I have a different idea...
     
  28. oblox

    oblox Well-known Member

    Joined:
    Aug 6, 2014
    Messages:
    1,032
    Likes Received:
    537
    Trophy Points:
    183
    In your example about evening out change, I see that, but aren't you essentially creating another denomination. If you are going to send micro amounts (less then 1 DRK), aren't you better off introducing a 0.10 denomination overall into the darksend process?

    What if change is accumulated on the masternodes, that continues to flow masternode to masternode after getting combined into new addresses. The masternodes as a consensus lock the last address from the ability to withdrawal and the client keeps track of how much change they are suppose to get back until it gets above a threshold to allow denominations to come back. It doesn't solve an issue if the masternode containing all the coins goes offline even though the masternode consensus should prevent those funds from being able to be sent anywhere other than where the consensus tells them to go. Probably oodles of flaws in there.

    The other idea is using the reference nodes but then again, you are introducing a centralized aspect, even if change is small.
     
  29. eduffield

    eduffield Core Developer

    Joined:
    Mar 9, 2014
    Messages:
    1,084
    Likes Received:
    5,319
    Trophy Points:
    183
    • Like Like x 2
  30. paperThin

    paperThin Member

    Joined:
    Jun 13, 2014
    Messages:
    106
    Likes Received:
    19
    Trophy Points:
    68
    Thanks Evan!