[ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency

[Simcom]

As far as the network is concerned, wallets do not exist, only addresses.  Your wallet just holds all of your addresses and the private keys associated with them.

Back to your original question about timing analysis, look at the bottom figure on page 3 of the whitepaper.  Each user will be placing the same # of coins into the pool (100 for example) - they will also provide a "spare change" address - coins that they don't want to spend but will come back to them.  This is a NEW address that has not been associated with them up to this point.

So lets say 3 people each put in 100 coins

A -> 100 sending 2 coins to D
B -> 100 sending 24 coins to E
C -> 100 sending 56 coins to F

The outputs will be

2 coins to D
98 coins to G
24 coins to E
76 coins to H
56 coins to F
46 coins to I

Now from this we can determine that the current holder of address G sent two coins to D, but it's impossible to determine whether G belongs to the same person as A, B, or C.

A new problem arises though, in that the coins are now sitting on address G, and it can be determined that the holder of those coins sent 2 coins to address D.  There would need to be another level of mixing to ensure that those 98 coins are washed another time - maybe Evan can clarify whether this mixing step happens or if I am misunderstanding something.

The risk is if address G sends money to something like coinbase (or some other site that has your personal info) -> that would expose them as the sender of 2 coins to address D.

Evan can you clarify?

It doesn't work like this, it's far more complex. It seems when I follow a transaction that all the address' balance is spent including 10 DRK which is used for the mixing.

I guess I don't follow.  According to the whitepaper it works as I describe above (as far as I can tell). Do you have a link to the blockchain so I can take a look?

Send 1 DRK to an other wallet via DarkSend and try to follow the money using http://chainz.cryptoid.info/drk/

The whitepaper talks about 100 DRK (10 DRK now) to the pool but it never says if 100 is the total output from the wallet  

I'm relatively certain you are incorrect, darksend transactions look exactly as I describe above and is described in the whitepaper:

http://chainz.cryptoid.info/drk/tx.dws?170313.htm


Inputs
Index   Previous output   Address   Amount
0   cedc64dc17...:5   XicoF7qtngaGXsytQ7h4TNFKMDSJrvUsjY   10.0 DRK
1   cedc64dc17...:7   XicoF7qtngaGXsytQ7h4TNFKMDSJrvUsjY   10.0 DRK
2   b747ec9902...:2   Xb7q4xABWhXYn33aBomrRG9qCjFHYubsax   10.0 DRK

Outputs
Index   Redeemed in   Address   Amount
0   276fa48861...   XgBeKjQDJfZFjYayd4sc3QMbisZKVU8N9E   6.99 DRK
1   2e379e419b...   XvFVnLpfcDA1mEgrNjE6AjsH2VED4wHoun   8.88789 DRK
2   276fa48861...   XpXMrUnmUz88sxt7mzHKgLnKJL6MKenfJT   8.281 DRK
3   14a6fb0220...   XpXMrUnmUz88sxt7mzHKgLnKJL6MKenfJT   3.009 DRK
4   54bd685235...   Xgtv392XNcTvgCQkU5goUK83iFRpoiESej   1.11111 DRK
5   329550ae97...   Xwx4vbsc7JTtVDLDK6isDsdmdmhyst12qZ   1.718 DRK



change address 5 goes with 2
change address 4 goes with 1
change address 3 goes with 0

The coins need to be cleaned another time so as not to be associated with the drksend receiving address

so #3, 4, and 5 need to be cleaned a second time so as not to be associated with the transaction.

[humanitee]

I'm relatively certain you are incorrect, darksend transactions look exactly as I describe above and is described in the whitepaper:

http://chainz.cryptoid.info/drk/tx.dws?d08bcb05760f7291e641b79e6ff9e4986b7c22ecc8ac61bae01c68d04df3246d.htm

It works as you describe. I'm sure this will be solved by either:
1) Multiple sends (users could do this already if they wanted), although recombining is currently problematic
2) Denomination on outputs down to lowest denominated amount

[Kai Proctor]

As far as the network is concerned, wallets do not exist, only addresses.  Your wallet just holds all of your addresses and the private keys associated with them.

Back to your original question about timing analysis, look at the bottom figure on page 3 of the whitepaper.  Each user will be placing the same # of coins into the pool (100 for example) - they will also provide a "spare change" address - coins that they don't want to spend but will come back to them.  This is a NEW address that has not been associated with them up to this point.

So lets say 3 people each put in 100 coins

A -> 100 sending 2 coins to D
B -> 100 sending 24 coins to E
C -> 100 sending 56 coins to F

The outputs will be

2 coins to D
98 coins to G
24 coins to E
76 coins to H
56 coins to F
46 coins to I

Now from this we can determine that the current holder of address G sent two coins to D, but it's impossible to determine whether G belongs to the same person as A, B, or C.

A new problem arises though, in that the coins are now sitting on address G, and it can be determined that the holder of those coins sent 2 coins to address D.  There would need to be another level of mixing to ensure that those 98 coins are washed another time - maybe Evan can clarify whether this mixing step happens or if I am misunderstanding something.

The risk is if address G sends money to something like coinbase (or some other site that has your personal info) -> that would expose them as the sender of 2 coins to address D.

Evan can you clarify?

It doesn't work like this, it's far more complex. It seems when I follow a transaction that all the address' balance is spent including 10 DRK which is used for the mixing.

I guess I don't follow.  According to the whitepaper it works as I describe above (as far as I can tell). Do you have a link to the blockchain so I can take a look?

Send 1 DRK to an other wallet via DarkSend and try to follow the money using http://chainz.cryptoid.info/drk/

The whitepaper talks about 100 DRK (10 DRK now) to the pool but it never says if 100 is the total output from the wallet  

I'm relatively certain you are incorrect, darksend transactions look exactly as I describe above and is described in the whitepaper:

http://chainz.cryptoid.info/drk/tx.dws?d08bcb05760f7291e641b79e6ff9e4986b7c22ecc8ac61bae01c68d04df3246d.htm

Let's take a look at the previous transaction of one of the mixing addresses (Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4) : http://chainz.cryptoid.info/drk/tx.dws?231912.htm

Inputs
Index   Previous output   Address                                          Amount
0   ac1654bc6b...:0   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   10.0 DRK

Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 received a total of 162.26753362 DRK from XenyqcvgMbQ42FPph6eZZttYJEuKJzusSk (a sender) distributed like this :

Index   Redeemed in   Address                                           Amount
0   d08bcb0576...   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   10.0 DRK
1   16dbc9dbff...   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   152.15753362 DRK
2   Not yet redeemed   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   0.11 DRK

The 152.15753362 DRK and the rest of the real DarkSend transaction (10 - x) never came back directly to XenyqcvgMbQ42FPph6eZZttYJEuKJzusSk

[Simcom]

Let's take a look at the previous transaction of one of the mixing addresses (Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4) : http://chainz.cryptoid.info/drk/tx.dws?231912.htm

Inputs
Index   Previous output   Address                                          Amount
0   ac1654bc6b...:0   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   10.0 DRK

Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 received a total of 162.26753362 DRK from XenyqcvgMbQ42FPph6eZZttYJEuKJzusSk (a sender) distributed like this :

Index   Redeemed in   Address                                           Amount
0   d08bcb0576...   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   10.0 DRK
1   16dbc9dbff...   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   152.15753362 DRK
2   Not yet redeemed   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   0.11 DRK

The 152.15753362 DRK and the rest of the real DarkSend transaction (10 - x) never came back directly to XenyqcvgMbQ42FPph6eZZttYJEuKJzusSk

I guess I don't get it.  The whitepaper does not explain this very clearly which is unfortunate.

[Kai Proctor]

Let's take a look at the previous transaction of one of the mixing addresses (Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4) : http://chainz.cryptoid.info/drk/tx.dws?231912.htm

Inputs
Index   Previous output   Address                                          Amount
0   ac1654bc6b...:0   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   10.0 DRK

Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 received a total of 162.26753362 DRK from XenyqcvgMbQ42FPph6eZZttYJEuKJzusSk (a sender) distributed like this :

Index   Redeemed in   Address                                           Amount
0   d08bcb0576...   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   10.0 DRK
1   16dbc9dbff...   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   152.15753362 DRK
2   Not yet redeemed   Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4   0.11 DRK

The 152.15753362 DRK and the rest of the real DarkSend transaction (10 - x) never came back directly to XenyqcvgMbQ42FPph6eZZttYJEuKJzusSk

I guess I don't get it.  The whitepaper does not explain this very clearly which is unfortunate.

Maybe some improvements were implemented following the discussion between Evan and AnonyMint.

[GhostPlayer]

and a good reason for why its closed-source until released as open-source.

[TanteStefana]

a. I like asking 5y/o questions. I know i seem ignorant at the time... but you wouldn't believe where it brought me in life...

b. I read a FASCINATING article yesterday about Larry Page who is brilliant on one hand, and lacked communication skills on the other hand. I strongly recommend it's read although it is long...
http://www.businessinsider.com/larry-page-the-untold-story-2014-4?op=1
 

Wow, I just read that article and it totally inspired me!!  Sent it on to my son.  I'm sure it will inspire him as well   Thanks!

[GhostPlayer]

OMG !! AMD just released a 295x6 card at 2000MH/s under x11 GPU !!!

https://www.youtube.com/watch?v=u5YJsMaT_AE

SELL SELL SELL !!!

[Simcom]

From the whitepaper:

Improved Pool Anonymity
Users  who  want  to  increase  the  anonymity  of  the pools can run scripts to “push” DarkSend
transactions through the pool by sending  money  to themselves with  DarkSend. This will allow
them to take up a space in the pool to ensure the anonymity of other users. If enough users run
scripts  like  this  one,  the  speed  of  transactions  and  the  anonymity  of  the  network  will  be
increased.

The problem I see with this is that it would be really easy to tell which addresses were pushing transactions and which were just using darksend naturally by merely the frequency of the transactions.  ie "pushed" coins will have only been sitting on the address a short while whereas non-pushed darksend transactions will have likely stood still for quite some time.

Maybe we could incorporate this pushing behavior into the masternodes themselves?  There will likely be many hundreds of masternodes (each with 1000 coins), so maybe if a subset (maybe 5-10%) pushed a few coins through darksend every mixing cycle it could create more anonymity.  The big advantage here is that there are so many masternodes with so many coins, each masternode would only have to push a small number of coins infrequently.  This would make it harder to distinguish pushed coins from those that were just sent by darksend naturally.

[TanteStefana]

OMG !! AMD just released a 295x6 card at 2000MH/s under x11 GPU !!!

https://www.youtube.com/watch?v=u5YJsMaT_AE

SELL SELL SELL !!!

OMG, that's one of the funniest things I've ever seen!  LOVE it!

[TanteStefana]

From the whitepaper:

Improved Pool Anonymity
Users  who  want  to  increase  the  anonymity  of  the pools can run scripts to “push” DarkSend
transactions through the pool by sending  money  to themselves with  DarkSend. This will allow
them to take up a space in the pool to ensure the anonymity of other users. If enough users run
scripts  like  this  one,  the  speed  of  transactions  and  the  anonymity  of  the  network  will  be
increased.

The problem I see with this is that it would be really easy to tell which addresses were pushing transactions and which were just using darksend naturally by merely the frequency of the transactions.  ie "pushed" coins will have only been sitting on the address a short while whereas non-pushed darksend transactions will have likely stood still for quite some time.

Maybe we could incorporate this pushing behavior into the masternodes themselves?  There will likely be many hundreds of masternodes (each with 1000 coins), so maybe if a subset (maybe 5-10%) pushed a few coins through darksend every mixing cycle it could create more anonymity.  The big advantage here is that there are so many masternodes with so many coins, each masternode would only have to push a small number of coins infrequently.  This would make it harder to distinguish pushed coins from those that were just sent by darksend naturally.

This is the main reason that we may have DarkSend only transactions.  If all transactions were darksent, we wouldn't have this problem.  Right now, being limited to 10< coins, people can't use darksend for moving their balance without a lot of hassle, so you don't see a lot of DS transactions happening

[Kai Proctor]

From the whitepaper:

Improved Pool Anonymity
Users  who  want  to  increase  the  anonymity  of  the pools can run scripts to “push” DarkSend
transactions through the pool by sending  money  to themselves with  DarkSend. This will allow
them to take up a space in the pool to ensure the anonymity of other users. If enough users run
scripts  like  this  one,  the  speed  of  transactions  and  the  anonymity  of  the  network  will  be
increased.

The problem I see with this is that it would be really easy to tell which addresses were pushing transactions and which were just using darksend naturally by merely the frequency of the transactions.  ie "pushed" coins will have only been sitting on the address a short while whereas non-pushed darksend transactions will have likely stood still for quite some time.

Maybe we could incorporate this pushing behavior into the masternodes themselves?  There will likely be many hundreds of masternodes (each with 1000 coins), so maybe if a subset (maybe 5-10%) pushed a few coins through darksend every mixing cycle it could create more anonymity.  The big advantage here is that there are so many masternodes with so many coins, each masternode would only have to push a small number of coins infrequently.  This would make it harder to distinguish pushed coins from those that were just sent by darksend naturally.

I don't see the problem. The purpose is to unlink the sender and the receiver, using DarkSend (will be) is pretty normal and frequent, the part to hide is "for what".

[Simcom]

From the whitepaper:

Improved Pool Anonymity
Users  who  want  to  increase  the  anonymity  of  the pools can run scripts to “push” DarkSend
transactions through the pool by sending  money  to themselves with  DarkSend. This will allow
them to take up a space in the pool to ensure the anonymity of other users. If enough users run
scripts  like  this  one,  the  speed  of  transactions  and  the  anonymity  of  the  network  will  be
increased.

The problem I see with this is that it would be really easy to tell which addresses were pushing transactions and which were just using darksend naturally by merely the frequency of the transactions.  ie "pushed" coins will have only been sitting on the address a short while whereas non-pushed darksend transactions will have likely stood still for quite some time.

Maybe we could incorporate this pushing behavior into the masternodes themselves?  There will likely be many hundreds of masternodes (each with 1000 coins), so maybe if a subset (maybe 5-10%) pushed a few coins through darksend every mixing cycle it could create more anonymity.  The big advantage here is that there are so many masternodes with so many coins, each masternode would only have to push a small number of coins infrequently.  This would make it harder to distinguish pushed coins from those that were just sent by darksend naturally.

I don't see the problem. The purpose is to unlink the sender and the receiver, using DarkSend (will be) is pretty normal and frequent, the part to hide is "for what".

The problem I see is that it will be easy to identify who are the "pushers" if they are pushing with high frequency. It would be much harder to differentiate the pushers and non-pushers if there were multiple mixing steps because even normal non-pushed transactions would move on the blockchain several times.

[kaene]

It then compares the changes that occurred in those addresses in the last 2.5min [from its previous check] and knows exactly who transferred coins to whom.

Because it doesn't know who had them in the first place. It doesn't know if it's the same person sending to self.

Darksend moves in blocks of fixed size and provides change back on new addresses.

The blockchain keeps track of all of that anyway, why does a person have to be NSA? It's all in the blockchain...  Why monitor? I don't get it. I think you just have a fundamental lack of understanding in how any crypto coin works. I'm not even sure where to start in trying to help you understand. Not an insult... You just don't have enough basic knowledge to have this conversation.

That's kind of condescending. You could have just said, "an attacker can query the blockchain rather than constantly monitoring balances", and then answered his question. I thought it was a good question -- how does darksend protect against a timing analysis?

I think the answer is in making similar-sized payments (denomination of XX DRK) + using a time delay for batching multiple transactions together.

A third party will see accounts being reduced and increased by similar sizes. For example 100 people will be losing 10 DRKs and 100 people will be gaining 10 DRKs. So you don't really know who sent to who.

Right, but I can Darksend 7.289375 DRK to you, and I will get 2.710625 DRK change, and both of those amounts will be recorded in the blockchain. A timing analysis could trivially link the two addresses sending/receiving those two amounts that add to 10 DRK.

Short explanation is that your wallet will receive the change, but not in the same address that was used to send it.

[Simcom]

It then compares the changes that occurred in those addresses in the last 2.5min [from its previous check] and knows exactly who transferred coins to whom.

Because it doesn't know who had them in the first place. It doesn't know if it's the same person sending to self.

Darksend moves in blocks of fixed size and provides change back on new addresses.

The blockchain keeps track of all of that anyway, why does a person have to be NSA? It's all in the blockchain...  Why monitor? I don't get it. I think you just have a fundamental lack of understanding in how any crypto coin works. I'm not even sure where to start in trying to help you understand. Not an insult... You just don't have enough basic knowledge to have this conversation.

That's kind of condescending. You could have just said, "an attacker can query the blockchain rather than constantly monitoring balances", and then answered his question. I thought it was a good question -- how does darksend protect against a timing analysis?

I think the answer is in making similar-sized payments (denomination of XX DRK) + using a time delay for batching multiple transactions together.

A third party will see accounts being reduced and increased by similar sizes. For example 100 people will be losing 10 DRKs and 100 people will be gaining 10 DRKs. So you don't really know who sent to who.

Right, but I can Darksend 7.289375 DRK to you, and I will get 2.710625 DRK change, and both of those amounts will be recorded in the blockchain. A timing analysis could trivially link the two addresses sending/receiving those two amounts that add to 10 DRK.

Short explanation is that your wallet will receive the change, but not in the same address that was used to send it.

Yes but that means that the extra "change" is dirty (ie can be linked to the original darksend transaction) - and therefore should be cleaned a second time right?

[thelonecrouton]

It then compares the changes that occurred in those addresses in the last 2.5min [from its previous check] and knows exactly who transferred coins to whom.

Because it doesn't know who had them in the first place. It doesn't know if it's the same person sending to self.

Darksend moves in blocks of fixed size and provides change back on new addresses.

The blockchain keeps track of all of that anyway, why does a person have to be NSA? It's all in the blockchain...  Why monitor? I don't get it. I think you just have a fundamental lack of understanding in how any crypto coin works. I'm not even sure where to start in trying to help you understand. Not an insult... You just don't have enough basic knowledge to have this conversation.

That's kind of condescending. You could have just said, "an attacker can query the blockchain rather than constantly monitoring balances", and then answered his question. I thought it was a good question -- how does darksend protect against a timing analysis?

I think the answer is in making similar-sized payments (denomination of XX DRK) + using a time delay for batching multiple transactions together.

A third party will see accounts being reduced and increased by similar sizes. For example 100 people will be losing 10 DRKs and 100 people will be gaining 10 DRKs. So you don't really know who sent to who.

Right, but I can Darksend 7.289375 DRK to you, and I will get 2.710625 DRK change, and both of those amounts will be recorded in the blockchain. A timing analysis could trivially link the two addresses sending/receiving those two amounts that add to 10 DRK.

Short explanation is that your wallet will receive the change, but not in the same address that was used to send it.

Yes but that means that the extra "change" is dirty (ie can be linked to the original darksend transaction) - and therefore should be cleaned a second time right?

Where is the discoverable link between user A sending DRK to user B and user A receiving change in a new wallet address? I thought that bit was off-chain?

[humanitee]

Where is the discoverable link between user A sending DRK to user B and user A receiving change in a new wallet address? I thought that bit was off-chain?

The link is math. You wouldn't know who received 7.28 and who received 2.72, but those two added together would be 10 DRK, meaning they were from the same original address.

[Icebucket]

I think people are selling darkcoin to move into dogecoin because of the halvening!

Last halving didn't do much for the price if I recall correctly.

It actually fell...

So what's everyone's predictions for the near future? Waiting to see some movement due to RC2 release? Going to try and short DRK?

Short term prediction: The market will remain unpredictable due to whale movements.

Indeed.  Perhaps I should have used the term "plans"... I'm guessing the overwhelming majority would say hold.  I don't see us hitting 0.003 again (maybe not even close) so I don't see much opportunity to short, I think it would be too risky.  Evan could release RC2 anytime.

Guys lets try to keep the speculation contained on this thread https://darkcointalk.org/forums/speculation.34/

The freenode IRC channel is also a hotbed of speculation http://webchat.freenode.net/?channels=%23darkcoin

Regards
the Janitor   

[Simcom]

It then compares the changes that occurred in those addresses in the last 2.5min [from its previous check] and knows exactly who transferred coins to whom.

Because it doesn't know who had them in the first place. It doesn't know if it's the same person sending to self.

Darksend moves in blocks of fixed size and provides change back on new addresses.

The blockchain keeps track of all of that anyway, why does a person have to be NSA? It's all in the blockchain...  Why monitor? I don't get it. I think you just have a fundamental lack of understanding in how any crypto coin works. I'm not even sure where to start in trying to help you understand. Not an insult... You just don't have enough basic knowledge to have this conversation.

That's kind of condescending. You could have just said, "an attacker can query the blockchain rather than constantly monitoring balances", and then answered his question. I thought it was a good question -- how does darksend protect against a timing analysis?

I think the answer is in making similar-sized payments (denomination of XX DRK) + using a time delay for batching multiple transactions together.

A third party will see accounts being reduced and increased by similar sizes. For example 100 people will be losing 10 DRKs and 100 people will be gaining 10 DRKs. So you don't really know who sent to who.

Right, but I can Darksend 7.289375 DRK to you, and I will get 2.710625 DRK change, and both of those amounts will be recorded in the blockchain. A timing analysis could trivially link the two addresses sending/receiving those two amounts that add to 10 DRK.

Short explanation is that your wallet will receive the change, but not in the same address that was used to send it.

Yes but that means that the extra "change" is dirty (ie can be linked to the original darksend transaction) - and therefore should be cleaned a second time right?

Where is the discoverable link between user A sending DRK to user B and user A receiving change in a new wallet address? I thought that bit was off-chain?

There is no link to wallet address A, but there IS a link to the change address (let's call that address C).

After darksend is complete, if the user purchased goods with address C on a site that contained personal information - he would be outing himself as the user who performed the darksend transaction to user B (above). The change address needs to be sent back through a second wash to remove the link between C and B.

[thelonecrouton]

Where is the discoverable link between user A sending DRK to user B and user A receiving change in a new wallet address? I thought that bit was off-chain?

The link is math. You wouldn't know who received 7.28 and who received 2.72, but those two added together would be 10 DRK, meaning they were from the same original address.

But in order to put that math together, you would already have to know sent amount, who it was sent to and where it was sent from.

At that point user(s) A/B is/are already chained up in a dark concrete room having a very unpleasant day.