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

[Kyune]

Can anyone with a decent technical understanding draw some comparisons between Darksend and the approach being utilized in recently-announced Monero (https://bitcointalk.org/index.php?topic=583449.0)?  The latter seems to be aimed at a similar market niche as Darkcoin -- "untraceable payments", "unlinkable transactions", etc.  

[coins101]

Almost everybody who holds this coin has and should have confidence, but comments like "750m market cap this year are realistic" are a little exaggerated. Who seriously think that DRK will go beyond $1500. I hope noone is that delusional

Why not?

At ~ $175 per coin 750m cap is reached at around 4.280.000 coins

This isn't unrealistic. Optimistic - yes, but not unrealistic. Given enough demand for an anonymous coin - no problems with such level and above.

Who would have thought 1-2 ago that bitcoin will be 600-700$ ?

2,5 years ago I could have started mining bitcoins having read and calculated a lot, but I ignored it as at the time it was under electricity cost on my rig. Guess how I feel now   ouch

If it hits $175 and $750m+ this year, I'll be happy to donate, through DarkSend, enough to get a weekend escort of this quality for a lucky random and randy darkcoin holder.



If anyone wants to match that, we can offer two girls for a weekend of a lifetime.

The offer also stands if the winner is a girl and wants to choose a male escort  

Still stands....looking like I might have to pay up on this one 



https://bitcointalk.org/index.php?topic=579976.msg6335710#msg6335710

[GhostPlayer]

Can anyone with a decent technical understanding draw some comparisons between Darksend and the approach being utilized in recently-announced Monero (https://bitcointalk.org/index.php?topic=583449.0)?  The latter seems to be aimed at a similar market niche as Darkcoin -- "untraceable payments", "unlinkable transactions", etc.  

This pretty much sums it up... zero adoption by niche core users.

Algorithm: CryptoNight (64-bit CPU-only)

MINING IS RECOMMENDED ON LINUX ONLY, AS IT YOUR OWN COMPILED BINARIES WILL BE FASTER THAN THE PRE-COMPILED WINDOWS BINARIES!

Mining

Important: CryptoNote can only work on a 64-bit OS.

[Simcom]

Lets break this down to improve clarity:

A wants to send 2 coins to E
B wants to send 3 coins to F

A sends the masternode 10 coins, and address C (C is the change address)
B sends the masternode 10 coins, and address D (D is the change address)

The masternode will mix the coins and output:

2 coins to E
8 coins to C
3 coins to F
7 coins to D

It will be impossible to tell whether A sent coins to E&C or F&D.  It is possible however to say that whoever holds address C sent 2 coins to E.  Now if user A wants to buy something on amazon with DRK, and uses the coins at address C, amazon (or anyone who has compromised amazon's servers) can determine with 100% certainty that user A sent 2 coins to E in the earlier darksend transaction.  If the coins are darksent to amazon then there wouldn't be a problem I guess. Really the coins at address C should be automatically washed after the transaction to maintain anonymity in case the user non-darksends them later on.

Still not seeing any provable link between amount of change received by C and initial transaction between A and E. At least not without full access to the wallet that holds A and C, at which point all else is moot. Must be going blonde...

2+8=10 This proves that whoever holds coins at C darksent 2 coins to E.

No, 2+8=10 proves 2+8=10. Doesn't prove anything else at all.

Please describe the flaw in my logic

C and E are linked on the block explorer because 8+2=10, one is the change address one is the receiving address. If C lightsends DRK to any vendor compromised by law enforcement, they will know that either:

C recieved 8 coins from whoever holds change address E
or
C sent E 2 coins

1. C did not receive 8 coins from E
2. C did not send E 2 coins.
3. Nothing links back to A anyway, as the muxing is off-chain and no record is kept of it.

>1. C did not receive 8 coins from E
>2. C did not send E 2 coins.

By looking at the blockchain you can easily determine that either 1) or 2) is true.

>3. Nothing links back to A anyway

It doesn't matter if nothing links to A, C and E are linked - so the coins are dirty.

>as the muxing is off-chain and no record is kept of it.

The mixing is off-chain but the inputs and outputs are all on the blockchain for everyone to see.

[Minotaur26]

Hey guys, just a silly question, can the ubuntu client run in Linux mint?

[kaene]

Anyone care to share cool software that interacts with Mintpal ?

Their trading API is still private beta, I don't think there is any software able to do it (at least not using their API)

Then how on earth are those instant and multiple sell/buy walls and ramps created? special pals of Mintpal?  

Don't know, could be someone has a bot that uses the website directly, could be that someone has access to the private beta API and coded something, or just many people at once trading ... I saw it too, so I went to their IRC channel to ask for access to the private beta API and the answer was that it was private

[Simcom]

Lets break this down to improve clarity:

A wants to send 2 coins to E
B wants to send 3 coins to F

A sends the masternode 10 coins, and address C (C is the change address)
B sends the masternode 10 coins, and address D (D is the change address)

The masternode will mix the coins and output:

2 coins to E
8 coins to C
3 coins to F
7 coins to D

It will be impossible to tell whether A sent coins to E&C or F&D.  It is possible however to say that whoever holds address C sent 2 coins to E.  Now if user A wants to buy something on amazon with DRK, and uses the coins at address C, amazon (or anyone who has compromised amazon's servers) can determine with 100% certainty that user A sent 2 coins to E in the earlier darksend transaction.  If the coins are darksent to amazon then there wouldn't be a problem I guess. Really the coins at address C should be automatically washed after the transaction to maintain anonymity in case the user non-darksends them later on.

Still not seeing any provable link between amount of change received by C and initial transaction between A and E. At least not without full access to the wallet that holds A and C, at which point all else is moot. Must be going blonde...

2+8=10 This proves that whoever holds coins at C darksent 2 coins to E.

No, 2+8=10 proves 2+8=10. Doesn't prove anything else at all.

Please describe the flaw in my logic

C and E are linked on the block explorer because 8+2=10, one is the change address one is the receiving address. If C lightsends DRK to any vendor compromised by law enforcement, they will know that either:

C was sent 8 coins from whoever holds change address E
or
C sent E 2 coins

His logic is sound. This is something that should get an explanation I believe. There are ways to completely hide it though, as has been discussed. Off-hand, I can think of either: 1. mixing the change a second time; 2. further subdividing the change.

Consider:
Instead of (existing change):
8 to C
7 to D
You have:
6 to C
6 to D
1 to G (belonging to C)
1 to H (also C)
1 to I (belonging to D)

If my logic is sound, you now can only guess which is which. Right?

Yep that would work.  The problem with multiple change addresses though is later if the person sends all of the coins on their change addresses to a new address you could analyze the blockchain and see that all of the change addresses merged into 1 address then work backward and link all of those addresses together in the original darksend.

[dime]

Lets break this down to improve clarity:

A wants to send 2 coins to E
B wants to send 3 coins to F

A sends the masternode 10 coins, and address C (C is the change address)
B sends the masternode 10 coins, and address D (D is the change address)

The masternode will mix the coins and output:

2 coins to E
8 coins to C
3 coins to F
7 coins to D

It will be impossible to tell whether A sent coins to E&C or F&D.  It is possible however to say that whoever holds address C sent 2 coins to E.  Now if user A wants to buy something on amazon with DRK, and uses the coins at address C, amazon (or anyone who has compromised amazon's servers) can determine with 100% certainty that user A sent 2 coins to E in the earlier darksend transaction.  If the coins are darksent to amazon then there wouldn't be a problem I guess. Really the coins at address C should be automatically washed after the transaction to maintain anonymity in case the user non-darksends them later on.

Still not seeing any provable link between amount of change received by C and initial transaction between A and E. At least not without full access to the wallet that holds A and C, at which point all else is moot. Must be going blonde...

2+8=10 This proves that whoever holds coins at C darksent 2 coins to E.

No, 2+8=10 proves 2+8=10. Doesn't prove anything else at all.

You guys are giving him too much information and confusazing him... try it like this..

From the blockchain, you see this
A put in 10 drk
B put in 10 drk

C took out 8 drk
D took out 7 drk
E took out 2 drk
F took out 3 drk

At this point, you know that A and B both sent either 2, 3, 7 or 8 to C, D, E, or F. There's not enough information.

Later on, A sends out 500 coins, which the client sends 492 coins from wallet A and 8 coins from wallet C.

Someone now sees that wallet A and C belong to the same person. So going back the original transaction, they can see A put in 10, but received 8 back, then that means A sent 2 coins to B.
Futher, this reveals B send either 3 dark to F or 7 drk to D.

Presuming nothing is changed, it's easy to write up an algorithm that can go through and reveal all transactions given enough transactions.

However, there are ways to stop this.
1. The more transactions that are the same, the better. So if it was limited to integers, then that'd be easy. If in the original equation, X also send 2 to Y. Then tying C to A would still not tie A to E just yet. There would be one more level of obfuscation. On the other hand, sending in very precise units (3.14159265359) would be bad for trivial reasons.
2. Masternodes could broadcast a certain of transactions along with other fake transactions. Then anonhelper nodes could then send themselves transactions of the same amount to help obfuscate the real transactions and add more fake transactions.

Basically, more precise transactions and less transactions means it will be easier to reveal. Less precise transactions and same payment transactions bundled together mean plausible deniability is maintained.

[Minotaur26]

I think the thelonecrouton understands what you guys are saying, but what he means is that since the conclusion comes from adding the values that is a very good indication of who sent the money but the user still has plausible deniability, so the person that obtained the information couldnt enforce anything like in a court of law or something. At least thats how I am reading it, basically the numbers may add but that officially doesnt prove anything.

[Simcom]

Lets break this down to improve clarity:

A wants to send 2 coins to E
B wants to send 3 coins to F

A sends the masternode 10 coins, and address C (C is the change address)
B sends the masternode 10 coins, and address D (D is the change address)

The masternode will mix the coins and output:

2 coins to E
8 coins to C
3 coins to F
7 coins to D

It will be impossible to tell whether A sent coins to E&C or F&D.  It is possible however to say that whoever holds address C sent 2 coins to E.  Now if user A wants to buy something on amazon with DRK, and uses the coins at address C, amazon (or anyone who has compromised amazon's servers) can determine with 100% certainty that user A sent 2 coins to E in the earlier darksend transaction.  If the coins are darksent to amazon then there wouldn't be a problem I guess. Really the coins at address C should be automatically washed after the transaction to maintain anonymity in case the user non-darksends them later on.

Still not seeing any provable link between amount of change received by C and initial transaction between A and E. At least not without full access to the wallet that holds A and C, at which point all else is moot. Must be going blonde...

2+8=10 This proves that whoever holds coins at C darksent 2 coins to E.

No, 2+8=10 proves 2+8=10. Doesn't prove anything else at all.

You guys are giving him too much information and confusazing him... try it like this..

From the blockchain, you see this
A put in 10 drk
B put in 10 drk

C took out 8 drk
D took out 7 drk
E took out 2 drk
F took out 3 drk

At this point, you know that A and B both sent either 2, 3, 7 or 8 to C, D, E, or F. There's not enough information.

Later on, A sends out 500 coins, which the client sends 492 coins from wallet A and 8 coins from wallet C.

Someone now sees that wallet A and C belong to the same person. So going back the original transaction, they can see A put in 10, but received 8 back, then that means A sent 2 coins to B.
Futher, this reveals B send either 3 dark to F or 7 drk to D.

Presuming nothing is changed, it's easy to write up an algorithm that can go through and reveal all transactions given enough transactions.

However, there are ways to stop this.
1. The more transactions that are the same, the better. So if it was limited to integers, then that'd be easy. If in the original equation, X also send 2 to Y. Then tying C to A would still not tie A to E just yet. There would be one more level of obfuscation. On the other hand, sending in very precise units (3.14159265359) would be bad for trivial reasons.
2. Masternodes could broadcast a certain of transactions along with other fake transactions. Then anonhelper nodes could then send themselves transactions of the same amount to help obfuscate the real transactions and add more fake transactions.

Basically, more precise transactions and less transactions means it will be easier to reveal. Less precise transactions and same payment transactions bundled together mean plausible deniability is maintained.

Yes, stated very well  

[thelonecrouton]

>1. C did not receive 8 coins from E
>2. C did not send E 2 coins.

By looking at the blockchain you can easily determine that either 1) or 2) is true.

>3. Nothing links back to A anyway

It doesn't matter if nothing links to A, C and E are linked - so the coins are dirty.

>as the muxing is off-chain and no record is kept of it.

The mixing is off-chain but the inputs and outputs are all on the blockchain for everyone to see.

>By looking at the blockchain you can easily determine that either 1) or 2) is true.
But neither 1 nor 2 is true. Maybe you got your letters mixed up?

>It doesn't matter if nothing links to A, C and E are linked - so the coins are dirty.
If C is traceable directly from E then you're right, although that still proves nothing, but I thought C received whatever change from a mix, not directly from E in the clear?

>The mixing is off-chain but the inputs and outputs are all on the blockchain for everyone to see.
Someone sent some DRK somewhere. But we don't know where.  Not seeing a problem there, except the timing analysis one.

[thelonecrouton]

I think the thelonecrouton understands what you guys are saying, but what he means is that since the conclusion comes from adding the values that is a very good indication of who sent the money but the user still has plausible deniability, so the person that obtained the information couldnt enforce anything like in a court of law or something. At least thats how I am reading it, basically the numbers may add but that officially doesnt prove anything.

Yes, thank you.

[Simcom]

I think the thelonecrouton understands what you guys are saying, but what he means is that since the conclusion comes from adding the values that is a very good indication of who sent the money but the user still has plausible deniability, so the person that obtained the information couldnt enforce anything like in a court of law or something. At least thats how I am reading it, basically the numbers may add but that officially doesnt prove anything.

Maybe one transaction doesn't prove anything 100%, but if you add up hundreds of darksends from the same address you could potentially mathmatically prove with 99.9999% certainty etc. Plus as dime explains, if sending a large transaction later the wallet will combine your clean coins with your dirty change wallets which will give away even more info.

[luigi1111]

Lets break this down to improve clarity:

A wants to send 2 coins to E
B wants to send 3 coins to F

A sends the masternode 10 coins, and address C (C is the change address)
B sends the masternode 10 coins, and address D (D is the change address)

The masternode will mix the coins and output:

2 coins to E
8 coins to C
3 coins to F
7 coins to D

It will be impossible to tell whether A sent coins to E&C or F&D.  It is possible however to say that whoever holds address C sent 2 coins to E.  Now if user A wants to buy something on amazon with DRK, and uses the coins at address C, amazon (or anyone who has compromised amazon's servers) can determine with 100% certainty that user A sent 2 coins to E in the earlier darksend transaction.  If the coins are darksent to amazon then there wouldn't be a problem I guess. Really the coins at address C should be automatically washed after the transaction to maintain anonymity in case the user non-darksends them later on.

Still not seeing any provable link between amount of change received by C and initial transaction between A and E. At least not without full access to the wallet that holds A and C, at which point all else is moot. Must be going blonde...

2+8=10 This proves that whoever holds coins at C darksent 2 coins to E.

No, 2+8=10 proves 2+8=10. Doesn't prove anything else at all.

Please describe the flaw in my logic

C and E are linked on the block explorer because 8+2=10, one is the change address one is the receiving address. If C lightsends DRK to any vendor compromised by law enforcement, they will know that either:

C was sent 8 coins from whoever holds change address E
or
C sent E 2 coins

His logic is sound. This is something that should get an explanation I believe. There are ways to completely hide it though, as has been discussed. Off-hand, I can think of either: 1. mixing the change a second time; 2. further subdividing the change.

Consider:
Instead of (existing change):
8 to C
7 to D
You have:
6 to C
6 to D
1 to G (belonging to C)
1 to H (also C)
1 to I (belonging to D)

If my logic is sound, you now can only guess which is which. Right?

Yep that would work.  The problem with multiple change addresses though is later if the person sends all of the coins on their change addresses to a new address you could analyze the blockchain and see that all of the change addresses merged into 1 address then work backward and link all of those darksend transactions together in the original darksend.

True, so it sort of takes you back to option 1. remixing the change. Those addresses with only 1 coin in them would be super easy to remix if that was the base unit for normal transaction change. In my mind, remixing this left over change would only reinforce new transactions' anonymity. Is this correct? One would also think there would be a way to mix over several blocks (and masternodes, the current masternode would have to forward its change to the new blocks masternode?) I would think the additional transactions in the new round of mixing would introduce way too many unknowns to have any hope of figuring out.

OTOH, I'm not fully versed on how it all works, so I could be completely wrong.

[dime]

I like that you guys used the term plausible deniability which I was the first to bring into this conversation, so it appears you read SOME part of the my statement, but apparently, you don't have the basic math comprehension to understand it.

I think the thelonecrouton understands what you guys are saying, but what he means is that since the conclusion comes from adding the values that is a very good indication of who sent the money but the user still has plausible deniability, so the person that obtained the information couldnt enforce anything like in a court of law or something. At least thats how I am reading it, basically the numbers may add but that officially doesnt prove anything.

Yes, thank you.

Then you're reading it wrong. Try again. Given the example I used, there is 100% proof A sent to E.

[thelonecrouton]

Later on, A sends out 500 coins, which the client sends 492 coins from wallet A and 8 coins from wallet C.

Someone now sees that wallet A and C belong to the same person.

Gotcha. But this could be solved by simply moving (via darksend) anything in the change address back into the "main" address before sending?

[camosoul]

Plus as dime explains, if sending a large transaction later the wallet will combine your clean coins with your dirty change wallets which will give away even more info.

Coin Control. Explicitly tell it which addresses to use in a given transaction. Feature already exists.

If you have to send someone an amount that would force you to overlap, just send more than one TX being careful not to let them overlap sources.

Also, be your own mixer. Send to self. 20 or so transactions of that nature don't look like one person. Send EVERYTHING to new address in new wallet, etc... Use Tor. Always. OpenBox, VMs...

[humanitee]

Plus as dime explains, if sending a large transaction later the wallet will combine your clean coins with your dirty change wallets which will give away even more info.

Coin Control. Explicitly tell it which addresses to use in a given transaction. Feature already exists.

If you have to send someone an amount that would force you to overlap, just send more than one TX being careful not to let them overlap sources.

Also, be your own mixer. Send to self. 20 or so transactions of that nature don't look like one person. Send EVERYTHING to new address in new wallet, etc... Use Tor. Always. OpenBox, VMs...

Evan mentioned the possibility of master nodes that handle re-denominating.

[dime]

Later on, A sends out 500 coins, which the client sends 492 coins from wallet A and 8 coins from wallet C.

Someone now sees that wallet A and C belong to the same person.

Gotcha. But this could be solved by simply moving (via darksend) anything in the change address back into the "main" address before sending?

You can't at the moment because C only has 8 darkcoins right?

Darksend requires input of 10.

So 8 comes from C, and the remaining 2 come from...? A, or another wallet A owns which sooner or later ties to A.

[Simcom]

True, so it sort of takes you back to option 1. remixing the change. Those addresses with only 1 coin in them would be super easy to remix if that was the base unit for normal transaction change. In my mind, remixing this left over change would only reinforce new transactions' anonymity. Is this correct?

Yep, I think remixing the change is the best option.  Even better would be to remix the change a user defined number of times     This would increase anonymity tremendously because anyone analyzing the blockchain would have no idea when the actual outputs were made, AND there would be less likelyhood of hitting a string of malevolent masternodes.

One would also think there would be a way to mix over several blocks (and masternodes, the current masternode would have to forward its change to the new blocks masternode?) I would think the additional transactions in the new round of mixing would introduce way too many unknowns to have any hope of figuring out.

OTOH, I'm not fully versed on how it all works, so I could be completely wrong.

The masternode wouldn't necessarily have to forward the coins to the next masternode, they could just send it back to the client and have the client darksend the coins out again automatically.