Dead Change - an anonymity issue

[oblox]

I meant.. but it's connected to the origin address.. Can we make it not connected to the origin address?

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.

 

[paperThin]

I meant.. but it's connected to the origin address.. Can we make it not connected to the origin address?

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.

 

[moli]

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.

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?

 

[paperThin]

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.

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.

 

[paperThin]

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?

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!)

 

[Aswan]

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.

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

 

[moli]

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!)

Yes, DRK has the advantage of "plausible deniability" which is cool.

 

[paperThin]

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

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!

 

[Aswan]

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.)

Exactly!

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.

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.

 

[moli]

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.

 

[oblox]

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.

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.

 

[paperThin]

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"]​

 

[oblox]

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"]​

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.

 

[paperThin]

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.

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

 

[oblox]

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

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.

 

[paperThin]

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.

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!

 

[oblox]

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!

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.

 

[oblox]

Bumping this again for exposure so it doesn't get lost under Crouton's rant as this is more pressing.

 

[moli]

Bumping this again for exposure so it doesn't get lost under Crouton's rant as this is more pressing.

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?

 

[oblox]

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?

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.