Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 6169. (Read 9724097 times)
April 28, 2014, 02:58:30 PM
Hey guys, just a silly question, can the ubuntu client run in Linux mint?
April 28, 2014, 02:45:48 PM
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.
April 28, 2014, 02:27:42 PM
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.
Quote
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.
April 28, 2014, 02:26:52 PM
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
ouchIf 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://bitcointalksearch.org/topic/m.6335710
April 28, 2014, 02:23:33 PM
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.
April 28, 2014, 02:23:07 PM
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.
April 28, 2014, 02:15:38 PM
More seriously, it's more an assumption than something you deduce from the previous example. (https://bitcointalksearch.org/topic/m.6440861)
April 28, 2014, 02:14:45 PM
No, 2+8=10 proves 2+8=10. Doesn't prove anything else at all.
Simcom, just give up. lol.
Please tell me you understand this, lol.
BTW, i'm not a techie but I think your solution above with many change addresses of 1drk each is neat.
April 28, 2014, 02:13:05 PM
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?
April 28, 2014, 02:10:49 PM
No, 2+8=10 proves 2+8=10. Doesn't prove anything else at all.
Simcom, just give up. lol.
Please tell me you understand this, lol.
Yes.
Thank god lol.
April 28, 2014, 02:09:35 PM
No, 2+8=10 proves 2+8=10. Doesn't prove anything else at all.
Simcom, just give up. lol.
Please tell me you understand this, lol.
Yes.
April 28, 2014, 02:06:58 PM
No, 2+8=10 proves 2+8=10. Doesn't prove anything else at all.
Simcom, just give up. lol.
Please tell me you understand this, lol.
April 28, 2014, 02:05:58 PM
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
April 28, 2014, 02:05:34 PM
No, 2+8=10 proves 2+8=10. Doesn't prove anything else at all.
Simcom, just give up. lol.
April 28, 2014, 01:57:25 PM
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.
April 28, 2014, 01:55:11 PM
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, or received 8 coins from whoever holds address E.
April 28, 2014, 01:47:11 PM
Regardless, the wallet should be passphrase protected at startup for anyone to see anything at all.
April 28, 2014, 01:40:01 PM
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.
He would only be outed if the attacker was in possession of his unencrypted wallet, with both the sending address and the receiving change address providing that information. Can't see how change address C is linkable to sending address A by inspecting the blockchain? If it is, then you're right of course, I'm often a dunce.
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.
Alternatively it could be set up like this:
A wants to send 2 coins to X
B wants to send 3 coins to Y
A sends the masternode 10 coins, and address C,D,E,F,G,H,I,J (8 different change addresses)
B sends the masternode 10 coins, and address K,L,M,N,O,P,Q (7 different change addresses)
The masternode will mix the coins and output:
2 coins to X
3 coins to Y
1 coin each to C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q
That would solve the problem completely, but you would be able to determine who the recipients are.
Even better would be:
2 coins to X
3 coins to Y
2 coin each to C,D,K
3 coins each to E,M,N
1 coin to H,Q
Then you wouldn't even be able to tell who are the intended receiving addresses.
April 28, 2014, 01:36:45 PM
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...
Jump to: