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

Dark Wallet article in Wired Magazine:

‘Dark Wallet’ Is About to Make Bitcoin Money Laundering Easier Than Ever

http://www.wired.com/2014/04/dark-wallet/?mbid=social_fb

instresting

Your next task is to update the chart with the plans Evan has for RC3  

Denomitated change addresses! 

My head hurts.....   

Ok, here is another attempt:



Remember, I'm just trying to put down what I believe Evan is actually doing

Yes if it we knew for sure that each 10 coins came from a separate wallet, there would be a big problem with the logic. But because multiple inputs can come from the same wallet and hopefully the denominization will be semi-random, so the logic is sound.  If X+Y+V+Z+A shows up in a darksend, A is not necessarily outed because even though X+Y+V+Z adds up to 7.5 and there was a 2.5 output, it is possible that the Joe&Suzie transactions came from the same wallet and we are actually looking at W+K+G+H+A not X+Y+V+Z+A.  It would be impossible to differentiate between X+Y+V+Z+A and A+W+K+G+H because both of these possible "change" combinations add up to 7.5    It is quite an eloquent solution actually.

There is still the problem evan mentions: if only one instance of a denomination is present it will be easy to out that person, but this seems like it would be an unlikely event once there are more than 4-5 people participating in the pool. Evan could even completely ablate this problem by coding it so that the darksend mixing won't start until there are at least 2 of every denomination represented.

No. This is wrong and people shouldn't practice it. Bitcoin is fine with 10 minute block as well.

Yah, I don't have it right yet... Ugh! I think the layers of Masternodes was to obfuscate the IP address which might be snooped out by a Masternode.  So I'm guessing, the first Masternode can only receive the coin and pass on the instructions to another Masternode, so that no Masternode can have all the information?  Maybe several Masternodes will pass the funds and instructions along so that the possibility of having control of enough Masternodes to retain the information is pretty much nil.  Then the final MasterNode, who can only know the IP address of the last MasterNode, is allowed to "open" the instructions, and sends the amounts to their recipients.

  I'll post another flow chart in a moment which might be how Evan is doing this or going to do this??

This is the thing.  It already seems to work this way.  I've used DarkSend to send funds to a second wallet via an address1.  When I try to see the balance afterwards of address1, I get 0, but I can see in my wallet that the funds have arrived.  I'm trying to understand what happens so that I can get this flowchart to be correct!

Genius is a too strong word. He i just a developer, a real one. DRK might be one of the top coins, it surely has potential.

out of curiousity, is there any chance in reducing the block time for 2.5mins? There are alot of coins that have much faster block times now which would lend to be better accepted as a currency for every day purchases in the future.

This really is brilliant and completely removes the problems we've been brainstorming about (or I'm just tired again (always have an excuse )). Too bad there's not a practical way of implementing it, right? Right? 

I was in the middle of going through this very logic myself, when I refreshed and saw your post.

I agree with the basic analysis: this proposed method seems to me to be flawless unless and until the largest change holder sends from all his change addresses associated with a particular DarkSend simultaneously with balance from his "main" address.

I'm still going to have to think about it more, because what if we DON'T consider the last sentence in your 3rd paragraph? Aren't we still *potentially* impacting anonymity?

I'm falling asleep right now, but I can't think of how you could actually secure this if the largest change holder did what you describe above. Even additional mixing wouldn't help as you could just track inputs and outputs all the way back once John did the bad deed.

I guess my point is: there's probably a large chance of additional "noise" being created that would make our potential analysis of John's coins impossible, but what if in a particular case this noise doesn't exist?

Or I'm just tired.

I spent a decent amount of time thinking about how to denominate the receiving address as well.  One solution I thought of, is not nearly as fancy as what you describe but sort of works.  You could just have the recipient provide a concatenated list of addresses from his wallet than can be used to do denominate the transaction.  This could be called a "Dark" address or something else equally silly  . and would look something like this:

ABCDEFGHIJK

where each letter represents a different address in the receiving wallet. The "Dark" address would be long as fuck, but it would get the job done - on the blockchain there would be no record of a special "Dark" address ever existing, only the individual addresses, A, B, C etc.

Ok, well I think this is a great solution, definitely the best idea proposed so far.  I have spent several hours thinking about ways to break it but I can't seem to come up with an Achilles heel.

A couple suggestions off the top of my head.  I think it would help if there was some randomness added to the way things are denominated. Ie sometimes 1.5 is denomated 1+0.5 - sometimes it is denominated 1+0.25+0.1+0.1+.05 sometimes it is denominated 0.5+0.5+0.5.  This would make it substantially harder to figure out what is going on in the blockchain

My other concern is that whoever gets the biggest amount of change is put in a precarious position.  In the above example this would be John. If John sends X+Y+V+Z+A he is outing A as the sender to C.  Even if John Darksends these coins he is still outing address A. Then once he outs himself, Joe (as the second largest change recipient (7DRK) is at risk of outing himself if he sends (or darksends) W+K+J+E. I suppose this whole scenario is a non-issue if we consider that more than one transaction can be sent into the pool from the same wallet, so it would be impossible to tell for certain who got the most change, as someone could have submitted multiple transactions and received 20,30,40 change coins to the same wallet.  

Seriously though, this is a fantastic solution, I'm relatively certain the logic is sound, and the level of anonymity will be very high. I'll sleep well tonight for sure

Anyone know why it takes sgminer 45 minutes to start mining Darkcoin.

I am using XUBUNTO


Each and every time takes 45 mins to start.

So in your example, the "change" is also being mixed through several masternodes along with the actual balance of the tx. This, along with further denomination of the "change" before it comes back to your wallet as Evan stated above, would be enough to break the trail?

Ok, I tried my hand at a flow chart again.  I'm not sure this is accurate, but I think it works this way ??  

I'm taking partial credit for it!  

This is similar to what I was trying to achieve with stealth sending, minus the denomination of receiving addresses. Usually users want to send to a pre-existing address, optimally DarkSend would be able to denominate the receiving party's amount as well. Stealth addresses allow you to generate infinitely many addresses from one receiving address. Sadly, the only way to see if you have coins in a stealth address is to have the private keys in memory which destroys cold storage completely. You would not be able to see whether or not someone had sent you coins. Without stealth sending though, the master node would have to issue new addresses which cannot happen for obvious reasons. If someone can think of a way to fully denominate the receiving party's amount it would push the coin into complete darkness. When combined with Evan's I2P implementation Dark would be as anonymous/private as possible.