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.  |
|
|
|
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 |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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? |
|
|
|
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. |
|
|
|
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. |
|
|
|
Let's take a look at the previous transaction of one of the mixing addresses (Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4) : http://chainz.cryptoid.info/drk/tx.dws?231912.htmInputs
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. |
|
|
|
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.htmInputs 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. |
|
|
|
He probably just takes note of when coins are sent from address A to B then back to A, he assumes A and B are the same person. |
|
|
|
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? |
|
|
|
Btw, I got an idea just now: It would be an interesting twist if one could send to two addresses instead of one, in a single transaction, with the sent amount being broken into two randomly sized parts. For example I send you 16 DRK and you get 5.4 DRK in one address and 10.6 DRK in another. You still got 16 but it's in two addresses so noone can corelate my 16 output and your receiving of ..5.4 and 10.6. If a further layer is added (for practical purposes) to treat these addresses as one (for the sender and receiver) it could also be quite easy to use. Kind of meta-addresses that overlap/include the sending/receiving addresses.
ok -- but with a timing analysis, the number of transactions in (let's say) a 60 second window will be relatively few, so it's not too hard to reconstruct what really happened, especially with uncommon amounts (e.g. I send you 16.023957). [Note- i don't know what is chain pooling that you mentioned...] When someone here ran a script to calculate the rich-list (many pages back), I remember he/she managed to correlate between different addresses as being part of the same wallet. So if I understand correct, what AlexGR suggested sounds intriguing, but 'hackable'. My question is- what if we take it further and instead of having the transactions divided between several addresses, it ius divided into several 'wallets' that reside on the same qt, feed from the same blackchain dat, but each having a separate wallet.dat file/keys ? 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? |
|
|
|
OK I found both wallet.dat files so take old dat and copy then paste into new dark coin wallet or dark coin wallet.dat
First thing you do is backup both wallets.dat files Then install a new wallet from darkcoin.io. Launch new wallet for the first time. Now take turns dropping your backup wallet.dat files into appdata/roaming/darkcoin folder to see which one matches the address with the coins. Once you've found the right wallet.dat just let the wallet sync and your coins will appear. |
|
|
|
Anybody have teamviewer willing to help me get my oldwallet n sync with new wallet I have over 200 coins in wallet stuck I tried to send my coins from old to new but the wallet never synced?
this small venture is paid of course, reasonable offers please If you tell us what you've done so far someone can probably help you for free... well ive downloaded the new wallet just now, doesn't show the darkcoin that was in the old xcoin wallet. About a month ago I tried to send my darkcoin from my old xcoin wallet into the new darkcoin wallet that I downloaded at the time, after the new wallet synced and didn't show the coin in it. Ive asked a few times here on this thread and had gotten the same answer to find the appdata file which ive finally found today.(LOL) Now I don't remember what to do with it, as well as not knowing which appdata darkcoin file this is, the old or the new? Can you see your balance in the blockchain if you enter either address? http://chainz.cryptoid.info/drk/No nothing for either(old xcoin wallet stuck at 10 weeks behind) can only see what was received from pools when I was mining with cpu on old wallet. they in the old address though? Does it (the blockchain explorer) show them leaving for somewhere? shows nothing leaving only in on old coin wallet You need to find the wallet.dat file for that old xcoin wallet. copy it - make a backup of that file. Then install a new wallet, in the appdata/roaming folder paste in your xcoin wallet.dat - then open the new wallet, your coins will be there If you somehow managed to delete that original xcoin wallet.dat file - your coins are gone forever. |
|
|
|
Apologies if this has been answered before.
If I have 3000 Dark and want to create 3 masternodes, Do I need to put 1000 Dark into 3 separate wallets on 3 separate servers.
Or can I have all 3000 dark sitting in 1 wallet on a secured server and I will get 3 tickets/chances to allow me to be selected as a masternode during the random selection process?
Thanks!!!
You need to have 3 separate wallets w/ three different static IPs |
|
|
|
|
105 BTC buy wall on mintpal
|
|
|
|
missing DRK coins sent to poloniex from mintpal and crypsy, anyone else have this problem? their on the blockchain but nowhere to be found and poloniex say they dont have them? odd  The blockchain doesn't lie. Push poloniex for your coins, send them a link to the blockchain. |
|
|
|
|
Show Posts
