Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 6168. (Read 9724097 times)

Yes, everything that runs on Ubuntu can be run in Linux Mint.

Huge buy walls on cryptsy and mintpal 

Yep, but I think eventually there will be pools of 100, 10, 1, .1 -  anything below .1 could just be paid to the masternode as a fee for the mixing.

Plus we don't really want to go too low with the pool sizes because this would increase the amount of "dust" in the network.

Less manual intervention is cool and convenient, but sometimes there's no substitute for good old fashioned taking the bull by the horns while knowing what you're doing. That is the barrier to all crypto; too lazy to think about it.

I've added tagging of some key addresses in the CryptoID Darkcoin Explorer

Currently pools & Cryptsy are tagged.
The tagging involves some "guesstimation", consider its findings partial ie. it won't (can't) know all the funds/addresses.

If you want to help and have active accounts at other exchanges (ie. with not too recent deposits/withdrawals), feel free to PM me some details about addresses or transactions

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.


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.

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.

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

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

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

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.


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

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.

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.

Yes, thank you.

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

Yes, stated very well  

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.

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.

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.

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