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

Dead Change - an anonymity issue

Any reason why we aren't discussing stealth addresses. On paper, it seems like a match made in heaven. DS to cause reasonable doubt on who the sender is, stealth addresses to mask the receiver. What's not to like?

Stealth addresses are not nearly as useful as they're made out to be in crypto, they provide no extra anonymity to the payer (the one with the change address issue). They're only useful when posting a payment address in a public forum, because it stops people from being able to tie that public payment address to your actual payments.

In our case, the wallet by default makes a brand new change address to receive the change on. That's pretty much the same thing the stealth address is offering. The problem is, you know the change address is tied to the person who paid.
 
By the way, the denominations are reserved amounts, that's why they have 1 extra duff. If you try to send that amount with the software, it will round down. That's how your wallet tells if a specific input is denominated or not. Amounts like 1, 5, 10, 100DRK are used on the network all of the time, so I didn't want to reserve them.

So this must be the reason it's hard to make the denomination work smoothly. Stupid question, why can't the wallet keep track of which inputs are denominations and how many rounds they haven gone through, and how many times they've been tried to find a suitable mixing partners etc? I'd imagine that would simplify the code a whole lot and allow stuff like mixing some of the denominations "out of turn" if they find partners without having to wait larger denoms to get their mixing depth to the same level and so on.
 
So this must be the reason it's hard to make the denomination work smoothly. Stupid question, why can't the wallet keep track of which inputs are denominations and how many rounds they haven gone through, and how many times they've been tried to find a suitable mixing partners etc? I'd imagine that would simplify the code a whole lot and allow stuff like mixing some of the denominations "out of turn" if they find partners without having to wait larger denoms to get their mixing depth to the same level and so on.

It already can mix out of turn. You'll notice at times with the 500 denom that it will lag behind the more common 1s and 10s in terms of what round it is in. No longer do you need a denomination for each comprising the initial input. Now you can mix your 100s, 10s, and 1s with others with those more common amounts while waiting for people to join in with the 500s.
 
So I think I have a solution to the "dead change" issue.

The most simple solution is not allowing change with anonymous transactions, but that means we need to keep the closest set of denominations for the value a user is going to transfer anonymously. I think the best way to do this is eliminate the two largest denominations. For example, if a user wants to transfer 37.61DRK to another user, they would transfer 10x3DRK, 1x8DRK, that leaves .29DRK that would be donated.

- The mixing process would be about 16x faster, which is a nice plus
- The mixing would be much harder to follow (everyone is using the 2 denomination sets, so the mixing includes many more people at once)
- The max change you could have would be .99DRK, on average it would be 0.5DRK or about $1.
- We could have a list of donation addresses, Development Fund, Masternode Network, P2Pool Development, etc.

If DRK's price goes up, we can just keep denominations about $2 and $20. That way, it's always really quick to mix on the network and the excess change of small purchases is low. Later on when the network is bigger, we could add back in the larger denominations, and when the wallet has larger ones but no smaller ones, it could use Darksend to convert them from 100 to 10x9 + 1x10.
 
Last edited by a moderator:
So I think I have a solution to the "dead change" issue.

The most simple solution is not allowing change with anonymous transactions, but that means we need to keep the closest set of denominations for the value a user is going to transfer anonymously. I think the best way to do this is eliminate the two largest denominations. For example, if a user wants to transfer 37.61DRK to another user, they would transfer 10x3DRK, 1x8DRK, that leaves .29DRK that would be donated.

- The mixing process would be about 16x faster, which is a nice plus
- The mixing would be much harder to follow (everyone is using the 2 denomination sets, so the mixing includes many more people at once)
- The max change you could have would be .99DRK, on average it would be 0.5DRK or about $1.
- We could have a list of donation addresses, Development Fund, Masternode Network, P2Pool Development, etc.

If DRK's price goes up, we can just keep denominations about $2 and $20. That way, it's always really quick to mix on the network and the excess change of small purchases is low. Later on when the network is bigger, we could add back in the larger denominations, and when the wallet has larger ones but no smaller ones, it could use Darksend to convert them from 100 to 10x9 + 1x10.

Wait a minute, I thought bloat was the reason we couldn't break 500s into 100s but now we are breaking 100s and 500s into 10s?
 
Wait a minute, I thought bloat was the reason we couldn't break 500s into 100s but now we are breaking 100s and 500s into 10s?

The Darksend pool currently is set to max 1000DRK, at that size we would have serious bloat problems. But the plan is to limit the Darksend pool to 100DRK. So the bloat problem isn't an issue at all.

We'll also have to limit the "max anonymize" amount in the configuration to something like 500DRK. We don't want people anonymizing 10K DRK.
 
The Darksend pool currently is set to max 1000DRK, at that size we would have serious bloat problems. But the plan is to limit the Darksend pool to 100DRK. So the bloat problem isn't an issue at all.
YAY!! Thanks, Evan! :smile:
 
Sounds like a winning concept eduffield.

Possibly also a "re-anonomize" option for those who wish to keep a bank of anonymized funds and they can just "re-up" their anon with a single click, say if they recently spent 50 of their 100 mixed DRK
 
The Darksend pool currently is set to max 1000DRK, at that size we would have serious bloat problems. But the plan is to limit the Darksend pool to 100DRK. So the bloat problem isn't an issue at all.

We'll also have to limit the "max anonymize" amount in the configuration to something like 500DRK. We don't want people anonymizing 10K DRK.
Sounds like a winner to me. Is there a way as is to look at the completion variable (or whatever the qt client is referencing to display 100%) and issue a walletlock command when it reads 100% being that darksend is done? That way the wallet is not just sitting there unlocked for anyone to tamper with.
 
eduffield and Aswan, since yesterday I've been testing this "dead change" on Testnet by spending the changes but so far I still don't see the transactions lead back to the origin address... Am I missing something?

EDIT: OHHH I see... just found my answer... When I spend a change by itself, it can not lead to the origin but when I spend an amount more than the change, it takes the change and the non-anonymous DRK and yes, the transaction leads straight to the origin address...
 
Last edited by a moderator:
Sounds like a winning concept eduffield.

Possibly also a "re-anonomize" option for those who wish to keep a bank of anonymized funds and they can just "re-up" their anon with a single click if they just spent 50 of their 100 mixed DRK
Your simple click is hitting the "Start Darksend" button. ;)
 
- The max change you could have would be .99DRK, on average it would be 0.5DRK or about $1.
- We could have a list of donation addresses, Development Fund, Masternode Network, P2Pool Development, etc.

I would NOT make that mandatory (imagine what happens when DRK goes back to its all time high or more...I would certainly NOT donate ~$16 for each change).

And there WILL be lots of questions by Joe Average.
If I would be new to Darkcoin (and crypto in general) I would most probably avoid a coin which spends my change.

Scratch last statement, I would _certainly_ avoid that coin because I would suspect some kind of scam.

Make it low priority so it gets spend last, and _offer_ to "donate it or spend at your own risk" via pop-up and enough information for the end-user to make an educated decision.
 
I would avoid making a transaction by mixing non-anonymized DRK with anonymized DRK. I think we had discussions before that the "No Preference" feature was dangerous and had to go. At this point, I'm wondering if there should be one wallet for no DS and one wallet for DS that would anonymize all coins in that wallet, because when all DRKs are anonymized, and if you make a tx that has leftover change, the change doesn't lead back to the origin address.

I also agree with crowning that there should be no mandatory to make people donate. There has to be a way to avoid this "dead change" problem easily.
 
Last edited by a moderator:
I would NOT make that mandatory (imagine what happens when DRK goes back to its all time high or more...I would certainly NOT donate ~$16 for each change).

And there WILL be lots of questions by Joe Average.
If I would be new to Darkcoin (and crypto in general) I would most probably avoid a coin which spends my change.

Scratch last statement, I would _certainly_ avoid that coin because I would suspect some kind of scam.

Make it low priority so it gets spend last, and _offer_ to "donate it or spend at your own risk" via pop-up and enough information for the end-user to make an educated decision.
The problem is that even with warning, the average person will ultimately end up using that change paying for something forward (combined with anon coins) and as such, it will pass through the system unmasking previously anon. transactions. Perhaps it's also worth looking into adding micro denominations, 0.10 and 0.01. But then you are running into bloat issues again.
 
It's hard to explain but I like both ideas - to donate and not :confused:
While DRK is relatively small - it's ok and even fun but imagine "mandatory donations" (ouch, that term actually sucks) when we hit LTC in marketcap... or even BTC... nobody will like that. That same logic also applies to denoms values.

However let me throw some ideas at this:
So let's say you had 100 anon DRKs and you spent 16 (10 + 6x1) and no change there, all good.
Then you try to spend another 16 but this time you don't have needed denoms, too bad, you have change.

But Evan said mixing will be 16x faster... Soooo....
Could wallet simply restrict this and just ask if you want to quickly anonymize another 10 DRKs to have enough denoms to be able to pay that amount?
Or maybe wallet could even ask you to "replenish" anon amount just when you spend some? Or even do this automatically?
 
Last edited by a moderator:
It's hard to explain but I like both ideas - to donate and not :confused:
While DRK is relatively small - it's ok and even fun but imagine "mandatory donations" (ouch, that term actually sucks) when we hit LTC in marketcap... or even BTC... nobody will like that. That same logic also applies to denoms values.

However let me throw some ideas at this:
So let's say you had 100 anon DRKs and you spent 16 (10 + 6x1) and no change there, all good.
Then you try to spend another 16 but this time you don't have needed denoms, too bad, you have change.

But Evan said mixing will be 16x faster... Soooo....
Could wallet simply restrict this and just ask if you want to quickly anonymize another 10 DRKs to have enough denoms to be able to pay that amount?
Or maybe wallet could even ask you to "replenish" anon amount just when you spend some? Or even do this automatically?
Just my two duffs, I think that mandatory donating change is not a good solution.

As the technical aspect of Darkcoin is not my forte, I don't have any solutions to offer, but I will add that this would not be popular.

Please take your time with this one, and reach a solution that encompasses all DRKs, and doesn't need to leave out change. This will be attacked by our competitors, and with good reason.

We are marketing ourselves as true anon, not 95% anon (keep the change). This is very important!

Good luck, and maybe we need to go back to TestNet...
 
You can't go on testnet until you have a solution implemented to test.

I think the only real way around this issue is to have the micro denominations (0.10 and .01) at the expense of bloating the chain (now, if you are bloating the chain, then perhaps it's worth looking into ring sigs). Anything beyond that perhaps treated as dust for donation but again, it's a dangerous slope to go down to have mandatory donations. Certainly, things will need to be adjusted as the price of DRK increases. The unfortunate thing is that without the donations to get rid of the microchange, the risk that it's used on the network in further anon transactions increases dramatically. The end user wants simple.

Perhaps this is why other privacy-centric coins opted not to go the coinjoin route because the viability of it truly remaining anonymous is hard to implement. Seems like for every 3 steps forward, we are having to go backwards more than half. Another idea is trying to build on the coinshuffle concept.
 
I would NOT make that mandatory (imagine what happens when DRK goes back to its all time high or more...I would certainly NOT donate ~$16 for each change).

And there WILL be lots of questions by Joe Average.
If I would be new to Darkcoin (and crypto in general) I would most probably avoid a coin which spends my change.

Scratch last statement, I would _certainly_ avoid that coin because I would suspect some kind of scam.

Make it low priority so it gets spend last, and _offer_ to "donate it or spend at your own risk" via pop-up and enough information for the end-user to make an educated decision.
Just my two duffs, I think that mandatory donating change is not a good solution.

As the technical aspect of Darkcoin is not my forte, I don't have any solutions to offer, but I will add that this would not be popular.

Please take your time with this one, and reach a solution that encompasses all DRKs, and doesn't need to leave out change. This will be attacked by our competitors, and with good reason.

We are marketing ourselves as true anon, not 95% anon (keep the change). This is very important!

Good luck, and maybe we need to go back to TestNet...


Agree on above except for the educated decision , Joe average will probably be surprised to see that he is obliged to donate after having paid an anon amount , theoretically if you would make a lot of anon payments you will end up donating hundreds of DRK , or am I wrong by thinking that each partial coin cannot be used anon anymore even though combined they are more then 1 Drk again ?
 
Hello,

I think I have found a flaw with Darksend mixed coins anonymity which I am going to call "Dead change" in reference to Zombies which, if they stay dead, it's fine, but once they start moving they are gonna infest everyone whos in the same room/town with them.
If this issue is already known under another name - so be it :)

First of all, the issue with Darksend being marketed as a strong anonymity feature is that a lot of people will use darksend and therefore neglect other things to protect their identity. Once there is problem with Darksend, the anonymity might be broken completely because of that.
However, Darksend also wants to be an easy to use feature that people do not need to know much about in order to use it. Because of this, there has to be clear how many funds are anonymous and how many are not. With the current implementation, this is not the case.

Imagine mixing some coins (let's make it 20 Coins for this example, so thats 2 x 10.00000001 DRK). You now go ahead and spend 15 coins on something that you really cannot afford to be linked to you in any way. Fair enough, you can do that, but that will create a transaction using the 20.00000002 Coins, giving 15 of the to whoever you buy something from and giving 5.00000002 back to you as change. This change is "Dead Change".

It is highly important to keep in mind that the change (the 5.00000002 coins) is now tied to the purchase. Whatever you do with those coins can be traced back to your 15 coins purchase. Say you want to send them to an exchange, buy something else from another site etc. You have to be really careful what you do with them. Putting them on an exchange might lead to the exchange getting questioned about what you did with them. They might (have to) tell someone that you exchanged them to Bitcoins and that you sent your bitcoins to address X which belongs to.. lets say, coinbase, which has your real name etc. and suddenly your identity is tied to the purchase.
Another scenario would be that you just want to send all your DRK to your new wallet and you think it doesn't matter which funds you use because you will re-mix them before using anyway, so you combine mixed and non-mixed funds which ties the 15 coins purchase to your actual address that is probably associated with you. All because that 5.00000002 coins dead change was in there.
And there are a lot more things that can happen because of this.

As with Zombies, dead better stays dead. If you but it into a room (a transaction) with healthy (anonymized, unused) people (denominations), they are all gonna be infested (tied to a purchase / de-anonymized).
It's even worse. Unlike Zombies, Dead changes can infest each other if being used in a chain or if being combined resulting in even less anonymity / more ties to purchases.

The problem is that the dead change shouldn't be in the "anonymous coins pool" anymore. But they cannot be in the normal pool as well because then they might get used in a transaction with your non-mixed coins which is even worse. The question is, is it enough to have a 3rd pool for change?
The answer is no, because in crypto, Zombies infest each other. The change of several transactions would link them all together when being spent. Thats just as bad as leaving it in the "anonymous coins pool". Potentially even worse.
So the dead change that cannot be spent because otherwise the anonymity of the spending transaction might be compromised.

In the current implementation this can be prevented by not created change of mixed coins at all. This can be done by using up the whole input either by paying larger fees or by sending more DRK that one is supposed to. If money is sent to an exchange, send 100.00000001 anonymized coins instead of 100 or 95. Send 10.00000001 coins instead of 8.5 etc.

But thats not a good solution, it's just what we have to work with right now. In the example with the 5.00000002 Coins dead change, this change could re-enter Darksend mixing with other already mixed funds in order to make 4 x 1.00000001, which would leave 0.99999998 DRK of dead change behind while the rest is being re-anonymized.
However, the 0.99999998 DRK won't ever be spendable without possibly breaking anonymity. It can be donated though, if it's the only input of the donation Tx.

This is why I AGAIN suggest denomination convertibility. That means making the Darksend denominations be 1, 10, 100 etc instead of 1.00000001, 10.00000001 etc. Also, smaller denominations like 0.1 would be nice to have.
That way Dead change that accumulates over time can easily be re-anonymized without bloating the blockchain too much by combining 10 dead change re-anonymized denominations into the next bigger one. With the current implementation that is not possible as it would leave behind 0.00000009 DRK.
With denomination convertibility, there wouldn't be a leftover.

I hope there will be something implemented to prevent this from happening in the future. If not my solution suggestion, then hopefully something better.

Thanks for reading,
Aswan


Aswan,
I follow your discussion and agree with your request for whole numbers (1,10,100 etc). It is more anonymous if they are indistinguishable from other non-darksend transactions. Outside observers would not know if blockchain transactions were purchases or a person mixing.

It seems that the idea of "dead change" can be handled through more darksend mixing if the numbers are whole and large. i.e. 5 drk "dead change" could be remixed if whole numbers were used to darksend mix. (making 1,1,1,1,1 remixed drks) It looks like this is still up for debate on how to resolve, but definitely solvable.

Regarding your 0.99 problem. I have a suggestion that I would like to hear your thoughts. What if...
  • The "zombie" change was in the third category "dead change". This would be listed separately in the GUI as you suggested.
  • I understand and agree that this "dead change" cannot be remixed with other dead change without exposing information.
  • Here is my suggestion...
    • Save these change addresses in a separate category and let them build up (ie .99 , .85, .02 etc)
    • Each one of them would have their own address so no mixing problem yet.
    • Let the "dead change jar" build up to a standard amount in all people's clients. (ie 3, 5 or even 1 dark) Let's use 3 in this case.
    • It would not need to be an exact even amount because that would be unlikely to occur.
    • Here comes the magic...
      • Now my "dead change jar" is full (ie 3.12 drk)
      • I would wait until other clients are ready to mix "jars". Let's say 2 other people have jars "full" (3.2 and 3.3 drk)
      • We all "pour" our change into a single address (of course the masternode handles this) <--- the big jar
      • Then the masternode returns each of us our change (I would get 1, 1, 1 and 0.12 dark back from the masternode in 4 addresses.) You can see each person would get a similar return.
      • It would be difficult for an outside observer to know which of the "dead change" transactions were tied to me, especially if I then darksend denominated the 1,1,1 and dumped the 0.12 back in the "dead change jar".
      • More people mixing "jars" together or a larger "full jar" amount (ie 5 drk) improves anonymity.
      • This method causes little bloat to the blockchain
  • Your thoughts?
  • Anyone's thoughts?
 
Last edited by a moderator:
Back
Top