Dead Change - an anonymity issue

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
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:

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
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. ;)
 

crowning

Well-known Member
May 29, 2014
1,414
1,997
183
Alpha Centauri Bc
- 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.
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
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:

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
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.
 

UdjinM6

Official Dash Dev
Core Developer
Dash Core Team
May 20, 2014
3,639
3,537
1,183
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:
  • Like
Reactions: TaoOfSatoshi

TaoOfSatoshi

Grizzled Member
Jul 15, 2014
2,841
2,649
1,183
Dash Nation
www.dashnation.com
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...
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
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.
 

miningpros

New Member
Jun 6, 2014
27
19
8
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 ?
 

paperThin

Member
Jun 13, 2014
106
19
68
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:

JGCMiner

Active Member
Jun 8, 2014
364
217
113
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 agree mandatory "donations" is a really REALLY bad idea. If we are going to go with an idea like this, then the best bet is to keep things as they are and just add a 0.1 denomination. If somebody tries spend change then give a warning and the OPTION to donate.

Also, are we sure there is no way to remix dead change with other peoples dead change in some sort of special Darksend pool?

As I see it, the current idea of removing big denominations, capping max anon coins, and forced donations... all of these things seem like a MAJOR step backwards and is going to be very hard to swallow. I think most would rather sacrifice a bit of hard disk space for the blockchain than to cripple Darksend in the nature that is being discussed and then on top of that forcing donations.

Let's spend a good long time thinking about things before making this change. A mistake could really hurt the coin.
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
If somebody tries spend change then give a warning and the OPTION to donate.
A warning isn't enough... the average person will say fuck it and send the coins anyone. The second that change is used as is, linkages start forming. I wouldn't mind hearing from Aswan in regards to paper's idea about the change jars.
 
  • Like
Reactions: paperThin

JGCMiner

Active Member
Jun 8, 2014
364
217
113
A warning isn't enough... the average person will say fuck it and send the coins anyone. The second that change is used as is, linkages start forming. I wouldn't mind hearing from Aswan in regards to paper's idea about the change jars.
Ok. Then they slit their own wrist... That is still better than forcing "donations" on EVERYBODY.

As far as I understand you can only hurt yourself with your dead change. Spending dead change willfully in the face of a warning is the same as using Bitcoin or not bothering to ever turn on Darksend. Why do we care?
 

Aswan

Member
Jun 26, 2014
68
216
73
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 am sorry for this being the 2nd Darksend flaw I had to point out in such a short time, but I think the coinjoin route is the right one, it's just not easy to get everything covered.

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
Micro denominations are useful for a variety of reasons, including paying Darksend fees. I am not sure the "randomly cashing in collateral" implementation is bullet proof. I'd like to know how this "random" is determined. When cashed, the collateral is a miners fee and miners as well as MNs profit from fees so they are incentivized to cash as many collaterals as possible. But that is another problem (if it is one at all, depends on how "random" is determined).

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...
It's still an anonymity issue even is the change is only spent by itself, because that way it link together the purchase it is used on plus the one that created it.


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!
While I think that the donation solution is not a bad one, I have to agree that making is mandatory is a no-go from a marketing point of view.
Also, yes, Darkcoin is being marketed as a an anonymous coin and not a 95% anonymous coin in case you don't want to donate your change, which is why a solution not requiring you to donate your change would be better.
However, this can be as easy as naming is a "fee" instead of a donation and adjusting the fee so that there never actually exists a change (it would instead be donated as a miners fee). That way, there would be no direct beneficiary of such a donation, just a "Darksend network cost".


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.
Yes, if the dead change amount is one that can exactly be re-denominated into darksend denominations without a leftover, this is possible. It would also be possible to donate the leftover or to make the leftover a miners fee in order to get the same result.

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?
This is a really interesting idea and when I first read it I thought this was the perfect solution. However, I kept thinking and came up with some problems:

What you suggest is simply Darksend mixing your dead change with other people with the special case that all inputs are non-anonymous and that at least 2 inputs belong to the same person.
Unfortunately, in this special case, Darksend is not quite as strong as it usually is.
Because all inputs are non-anonymous, this system is vulnerable to a falsification investigation.
An example:
There are 2 Participants (to make it easy) in such a dead change re-denomination Transaction (DCRD-Tx?), each one putting in 2 dead changes, resulting in 4 inputs.
One of the inputs was an output of a Tx that has been used to purchase something the investigator wants to know the buyer of (what a sentence :D). He knows the buyer has at least 2 inputs in the transaction because thats how DCRD-Txs work. He also knows there can only be 1 other person participating in this Tx.
So he starts looking at the 3 other inputs and starts to investigate. If he can link only 2 of them together, he knows the last one belongs to the person he is looking for.
So how does he link 2 together? It certainly won't always work just as spending dead change doesn't always compromise your anonymity, it's just possible that it does.
2 Inputs could be linked together in case their parent Txs send coins to the same receiver (an exchange, a gambling site, a hidden marketplace etc.) or if one if the changes leads to the identity of a person that proofs it owns the other input as well.
Now ofc thats only with the minimum amount of people and the minimum amount of input. If there are 8 people with 2-4 inputs each, averaging 24 inputs, it's a lot harder.... but not impossible.
So why is this not a general problem of Darksend? The answer is it certainly can be but normal Darksend mixing is inherently different.
In Darksend mixing, you first anonymize your coins and then spend them, making the investigator go back on the transaction chain in order to try to find you.
DCRD-Txs attempt to anonymize your coins after you used them trying to cut the links (which in normal Darksend mixing don't exist yet at the time of mixing).
That way DCRD transactions don't have the option of multiple layers (like Darksend mixing does). Imagine Darksend only doing 1 round. It't like that but there's a reason the client required at least 2.

However, the concept is quite nice and if already improves anonymity, even if it's not at Darksend levels (yet). I think it has great potential and might be the route to go to fix the dead change issue. Maybe it just needs a little tweaking.
Another downside is you REALLY have to be careful with your leftover change from a DCRD-Tx sind it can de-anonymize all the purchases of all the parent transactions of all the inputs you used in it, and this chain will never be broken if it is reused. Maybe at some point there would be a donation taking place.

Coinjoin is so interesting... and I hope your idea can be further developed into a good solution to the problem. Implementing it would definitely improve anonymity, I just don't think it's enough since it's far from Darksend level anonymity.

Also thanks for supporting my request for whole numbers in DS denominations.

Edit: I forgot to mention that because one DCRD-Tx per 2 changes can take place for you, you will only get one masternode, which makes malicious masternodes really scary, which is another reason why with Darksend, there are multiple mixing instances.

A warning isn't enough... the average person will say fuck it and send the coins anyone. The second that change is used as is, linkages start forming. I wouldn't mind hearing from Aswan in regards to paper's idea about the change jars.
There you go :)
 

crowning

Well-known Member
May 29, 2014
1,414
1,997
183
Alpha Centauri Bc
I am sorry for this being the 2nd Darksend flaw I had to point out in such a short time,
Sorry? We have to give you a big THANK YOU for this. Please find more!

Whatever is fixed NOW can't break Darkcoins neck once it is REALLY widely used.



It would also be possible to donate the leftover or to make the leftover a miners fee in order to get the same result.
I like the idea (no matter if it goes to the miners or the Masternodes), and wording it "fee" is a good idea.

Because all inputs are non-anonymous, this system is vulnerable to a falsification investigation.
Just a quick idea (I don't yet had my first coffee today, so my brain is still in sleepy mode): what if a Darksend transaction requires(!) already anonymised change?
 
  • Like
Reactions: Raico

Aswan

Member
Jun 26, 2014
68
216
73
Just a quick idea (I don't yet had my first coffee today, so my brain is still in sleepy mode): what if a Darksend transaction requires(!) already anonymised change?
I am not sure I understand you here. The Darksend mixing process has no problem with all inputs being non-anonymous in the first iteration because there are more to follow and the critical spending will only happen after several instances.
A transaction using only coins that have been freshly anonymized by Darksend will always be an anonymous transaction.

So do you mean a mixing transaction or the transaction that happens after the mixing with "Darksend transaction"?

Anyway, this wouldn't change the problems with paperThins solution.


yeah big Thank You Aswan!!
Thanks :)
 
Last edited by a moderator:
  • Like
Reactions: Raico

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
Definitely don't apologize Aswan for finding flaws, it's worthwhile knowing about them now before any sort of marketing initiative and/or adoption happens. Going back to Paper's coinjar idea, you already addressed the fact that about parties up to 8, but what if that was increased even farther. What if the minimum needed to be 25 or even 50 participants with at least 2 inputs (some obviously having more from more microchange build up). The change could be locked from spending (either the same way things are locked during the DS process or from the masternodes). And since this change can't be spent, it would be a natural event over time for there to be enough parties to pool their jars. As this happens with the amount of participants needed being so high and a certain threshold needed for the jar to get to, you will have some people contributing more than the arbitrary minimum (not sure if this helps or hurts the concept from a standpoint of linkages).

Other than that idea, I wouldn't mind hearing your thoughts on Coinshuffle either as an addition to the darksend mixing process or an additional at final send process. https://darkcointalk.org/threads/coinshuffle.3029/
 

TaoOfSatoshi

Grizzled Member
Jul 15, 2014
2,841
2,649
1,183
Dash Nation
www.dashnation.com
"can not be anonymized"

I find this difficult to accept. Give Evan enough time and he WILL find a solution. I don't like the look of that pop-up at all, and if I saw it on one of my transactions, I would wonder what I was doing using a coin that doesn't provide near 100% anonymity. That should always be our focus!

I just wish I could contribute technically, but I have complete confidence in Mr. Duffield.
 

paperThin

Member
Jun 13, 2014
106
19
68

Aswan,

Thank you for taking the time to consider my approach. If I could bother you for with more questions.
(Let's assume that DS is improved to use whole numbers for this discussion.)​
Large Change:
Regarding "dead change" greater than 1.0. (i.e. 4.87 drk from a single transaction)... Do you see an method to strip off the whole numbers 4.0 drk using the current methods (darksend denominate) and leave the 0.87 as dead change? Im my earlier post, I assumed that this was possible using standard Darksend mixing based on your other posts.
Aswan:
"The problem in UdjinM6s example would be that 5 non-anonymized coins won't fully go into a Darksend pool. Instead, 4x 1.00000001 DRK would go into the Darksend, leaving a dead change of 0.99999996 DRK behind, which can never be spent due to it being smaller than the smallest denomination."


From this, I understand that while not implemented currently, the wallet could be set up to strip off the whole numbers of DRK and leave dead change always less than 1.0. As long as this change (less than 1.0) is isolated in the wallet and "locked", then nothing is contaminated. This does not sound like a major overhaul in the design. Do you agree?
Small Change (i.e. the change jar)
  • So assuming that all "dead change" is less than 1.0 (if the above "Large Change" theory is ok), then it is safe to say that a standard 5 DRK "full jar" would always contain at least 6 "dead addresses" (i.e. 0.99 x 6 as the least number of addresses, but potentially many more).
  • (One advantage to this is that no one would have a fortune tied up in dead change.)
  • If the change jar mix occurs between at least 3 users, I do not see a difference between this method and the first round of a typical darksend denominate. Do you agree on this point?
  • It seems that the existing software development would need very little alteration since the general theory is the same as darksend. The trick is to let it happen (all three people mixing) in the same transaction.
  • Another critical point is that the "change" (less than 1.0) from the "jar mix" must return to the jar to be mixed on the next "jar mix". Also, the returned whole numbers (in this example 5 DRK = 1,1,1,1,1) should be run through darksend denominate a number of rounds.
  • (Another advantage is that this method does not require a 0.1 denomination. That is, if bloating is a problem.)
(My whole goal here is to find a way to "revive" zombie change as usable and anonymous. First, to find a path to show it can be done. Later, a way to enforce it through the wallet. A method that "works sometimes" is useless. It has to work in all cases. Thank you for pointing out weaknesses in your earlier post.)
Aswan:
There are 2 Participants (to make it easy) in such a dead change re-denomination Transaction (DCRD-Tx?)...


I know you were just making a simple example to explain. I think that 3 participants would always be required. Also, as mentioned above a higher number of transactions each. I think the existing darksend denominate would have all the weaknesses you mention if it only handled 2 users with 2 transactions each. Please indulge me and explain why "jar mix" would be weaker than a single round of darksend denominate.
Aswan:So why is this not a general problem of Darksend? The answer is it certainly can be but normal Darksend mixing is inherently different.
In Darksend mixing, you first anonymize your coins and then spend them, making the investigator go back on the transaction chain in order to try to find you.
DCRD-Txs attempt to anonymize your coins after you used them trying to cut the links (which in normal Darksend mixing don't exist yet at the time of mixing).
That way DCRD transactions don't have the option of multiple layers (like Darksend mixing does). Imagine Darksend only doing 1 round. It't like that but there's a reason the client required at least 2.


Agreed on your second point ("doing 1 round"). The first point about darksend working because it anonymizes and then spends (in that order) is only half of the equation. A person must "sandwich" both sides of a transaction (before and after) with some form of "mixing" in order to protect identity. This is true of any crypto coin. An investigator can use either a forward or backward search to link transactions. Your excellent thread has fired up discussion on backward searching which was for the most part not discussed here. Thank you for helping the ThinkTank come up with ideas to improve the coin. I really appreciate your efforts.
Regarding malicious masternodes, I think this is an equal problem for any mixing not just "jar mixing". Remember, everyone has to mix "round 1" (first round) when they bring coins into their wallet. At that point, if they happen to get a malicious node they are just as exposed as a "jar mix". The master node could keep a record of where those coins came from.

Regarding the "other user" revealing their transitions (i.e. volunteering their identity and transactions openly on the web) this is the same problem as darksend denominate. By process of elimination, the other users can expose an unknowing victim. Is this really different (in a single round) from darksend denominate?

Finally (wow sorry about the long post!!!) regarding donations. It is my opinion that the donation idea would be fine for a coin like DODG but DRK is not destined for that kind of a "feel good" coin. We want to be bitcoin 2.0. We want it to be what everyone wishes bitcoin really could be. We should strive to find a real solution to make this coin useful and "liquid" to the smallest denominations. Imagine DRK at US$10 (not that hard to imagine) and purchasing an item for $2. Now you have to donate $8? That's not a good currency! (I realize you could use non-anonymous coins, but I am making a point.) We want this to work just like it should. Anonymous like cash. If there is a way to do it... let's find it!


 
Last edited by a moderator:

Aswan

Member
Jun 26, 2014
68
216
73

Aswan,

Thank you for taking the time to consider my approach. If I could bother you for with more questions.
(Let's assume that DS is improved to use whole numbers for this discussion.)​
Large Change:
Regarding "dead change" greater than 1.0. (i.e. 4.87 drk from a single transaction)... Do you see an method to strip off the whole numbers 4.0 drk using the current methods (darksend denominate) and leave the 0.87 as dead change? Im my earlier post, I assumed that this was possible using standard Darksend mixing based on your other posts.
Aswan:
"The problem in UdjinM6s example would be that 5 non-anonymized coins won't fully go into a Darksend pool. Instead, 4x 1.00000001 DRK would go into the Darksend, leaving a dead change of 0.99999996 DRK behind, which can never be spent due to it being smaller than the smallest denomination."


From this, I understand that while not implemented currently, the wallet could be set up to strip off the whole numbers of DRK and leave dead change always less than 1.0. As long as this change (less than 1.0) is isolated in the wallet and "locked", then nothing is contaminated. This does not sound like a major overhaul in the design. Do you agree?
I'll try to answer your whole post tomorrow. It's kinda late and I gotta walk the dog, but what you described is is exactly what I suggested. Dead change that is bigger than the smallest denomination can re-enter the Darksend pool, but it has to do so alone (you cannot use multiple dead changes in the same Tx without possibly compromising anonymity. However, with your jar mix suggestion it might still be viable if enough people and outputs participate in such a Tx).
However, once the remaining possible denominations are stripped off the change, there will be a new change that cannot be stripped anymore. This is the problematic one.
Maybe I wasn't clear on what I meant or maybe you missread something, but I am sure we both agree here.

If the initial big change can enter the Darksend pool on it's own, then thats perfectly fine. But you still have to deal with the leftover.

Good night and I'll try to answer the rest tomorrow :)
 

paperThin

Member
Jun 13, 2014
106
19
68
I'll try to answer your whole post tomorrow. It's kinda late and I gotta walk the dog, but what you described is is exactly what I suggested. Dead change that is bigger than the smallest denomination can re-enter the Darksend pool, but it has to do so alone (you cannot use multiple dead changes in the same Tx without possibly compromising anonymity. However, with your jar mix suggestion it might still be viable if enough people and outputs participate in such a Tx).
However, once the remaining possible denominations are stripped off the change, there will be a new change that cannot be stripped anymore. This is the problematic one.
Maybe I wasn't clear on what I meant or maybe you missread something, but I am sure we both agree here.

If the initial big change can enter the Darksend pool on it's own, then thats perfectly fine. But you still have to deal with the leftover.

Good night and I'll try to answer the rest tomorrow :)
Thanks Aswan and have a good night. I will be out until late Sunday night... I look forward to reading your response.

Yes, it seems we are in agreement on most points, I just needed to be sure. My secondary points are useless if the primary assumptions do not hold up.

Thanks for lending your time and insight!!
 

Aswan

Member
Jun 26, 2014
68
216
73
Sorry for the late reply, I had a lot to do :)

Definitely don't apologize Aswan for finding flaws, it's worthwhile knowing about them now before any sort of marketing initiative and/or adoption happens. Going back to Paper's coinjar idea, you already addressed the fact that about parties up to 8, but what if that was increased even farther. What if the minimum needed to be 25 or even 50 participants with at least 2 inputs (some obviously having more from more microchange build up). The change could be locked from spending (either the same way things are locked during the DS process or from the masternodes). And since this change can't be spent, it would be a natural event over time for there to be enough parties to pool their jars. As this happens with the amount of participants needed being so high and a certain threshold needed for the jar to get to, you will have some people contributing more than the arbitrary minimum (not sure if this helps or hurts the concept from a standpoint of linkages).
You are right that more participants increase the anonymity with this jar solution. However, if there is a malicious masternode used to do this Tx, there might be a problem.

Other than that idea, I wouldn't mind hearing your thoughts on Coinshuffle either as an addition to the darksend mixing process or an additional at final send process. https://darkcointalk.org/threads/coinshuffle.3029/

I got the paper and will read it, then report back.

I know you were just making a simple example to explain. I think that 3 participants would always be required. Also, as mentioned above a higher number of transactions each. I think the existing darksend denominate would have all the weaknesses you mention if it only handled 2 users with 2 transactions each. Please indulge me and explain why "jar mix" would be weaker than a single round of darksend denominate.
It's true that only 2 Participants in Darksend are just as weak.
Also, I do not think that the jar mix would be weaker than a single round of darksend (if the amount of participants is the same in both).
This is the reason why the client required you to do at least 2 rounds of DS (more is obviously better).
The coin jar mix is only ever a single Tx, thus not allowing for more anonymity than a single round of DS.

However, more participants can increase the anonymity of the jar mix, making it an interesting solution that would be hard to get rolling (since you really need a lot of inputs to make it nearly as save as 4-5 rounds of DS.

Agreed on your second point ("doing 1 round"). The first point about darksend working because it anonymizes and then spends (in that order) is only half of the equation. A person must "sandwich" both sides of a transaction (before and after) with some form of "mixing" in order to protect identity. This is true of any crypto coin. An investigator can use either a forward or backward search to link transactions. Your excellent thread has fired up discussion on backward searching which was for the most part not discussed here. Thank you for helping the ThinkTank come up with ideas to improve the coin. I really appreciate your efforts.
Thanks :)

Regarding malicious masternodes, I think this is an equal problem for any mixing not just "jar mixing". Remember, everyone has to mix "round 1" (first round) when they bring coins into their wallet. At that point, if they happen to get a malicious node they are just as exposed as a "jar mix". The master node could keep a record of where those coins came from.
Say I just bought some DRK with my bitcoin on an exchange and withdrew them to my DRK wallet. Now those DRK could, by asking the exchange for the information, be traced back to the BTC address I fundet the exchange with and from there through the BTC network or if traced the other way, someone knows I bought DRK.

if I sent those coins into the DS pool and they start the first round, then that person is not sure anymore which outputs are mine and which aren't (except for the leftover that is returned by DS in the first DS TX).
If the Tx hit a malicious masternode, it it might still be known which coins are mine.
Up until here, it's the same chances as the jar mixing with 3 participants. However, there are more rounds to come and it is unlikely they all hit a malicious masternode.
Eventually the link will be broken during the mixing process.
Then, afterwards, when the link was broken, there comes the purchase that should not be linked to me. And it won't (provided I know how to deal with dead change).

Regarding the "other user" revealing their transitions (i.e. volunteering their identity and transactions openly on the web) this is the same problem as darksend denominate. By process of elimination, the other users can expose an unknowing victim. Is this really different (in a single round) from darksend denominate?
There is no difference between the jar mix and a single round of DS in that regard. However, the client required at least 2 rounds of DS, while more is obviously better.

Finally (wow sorry about the long post!!!) regarding donations. It is my opinion that the donation idea would be fine for a coin like DODG but DRK is not destined for that kind of a "feel good" coin. We want to be bitcoin 2.0. We want it to be what everyone wishes bitcoin really could be. We should strive to find a real solution to make this coin useful and "liquid" to the smallest denominations. Imagine DRK at US$10 (not that hard to imagine) and purchasing an item for $2. Now you have to donate $8? That's not a good currency! (I realize you could use non-anonymous coins, but I am making a point.) We want this to work just like it should. Anonymous like cash. If there is a way to do it... let's find it!
I agree that a solution not requiring a donation would be nice, but it is also possible to not call it a donation, but instead a fee that is used to protect anonymity (which it actually is). This Fee could not go to an address, but simply not appear in an output, thus resulting in a miners fee, which in turn help the miners and the masternodes. I think it's not a bad thing.

Regarding the DRK price rising: there can always be a smaller DS denomination introduced as price rises, so this fee could always be reasonably small.


Regarding bloating, there's mini-blockchain, dunno how hard that would be to implement though.

Blockchain pruning is something that probably doesn't fit into the thread, but once finished here, we could start a bloating discussion :)
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
Sorry for the late reply, I had a lot to do :)

I agree that a solution not requiring a donation would be nice, but it is also possible to not call it a donation, but instead a fee that is used to protect anonymity (which it actually is). This Fee could not go to an address, but simply not appear in an output, thus resulting in a miners fee, which in turn help the miners and the masternodes. I think it's not a bad thing.
Could you explain how this could not go to an address? It sounds similar to the fee 0.0125 before.
 

Aswan

Member
Jun 26, 2014
68
216
73
Could you explain how this could not go to an address? It sounds similar to the fee 0.0125 before.
Because the fee is paid by parts of the actual transaction(the leftover that would otherwise be change) and is not a separate input (like in the old DS)
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
Because the fee is paid by parts of the actual transaction(the leftover that would otherwise be change) and is not a separate input (like in the old DS)
Okay... Is it possible for Evan to separate the "dead change" and give it a new address separate completely without any trace to the origin address? Like a brand new address coming from mining... So users can still use the change and do whatever they want with it?
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
Okay... Is it possible for Evan to separate the "dead change" and give it a new address separate completely without any trace to the origin address? Like a brand new address coming from mining... So users can still use the change and do whatever they want with it?
Change already gets a fresh address unless specified during the send.
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
Change already gets a fresh address unless specified during the send.
I meant.. but it's connected to the origin address.. Can we make it not connected to the origin address?