Author

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

hero member
Activity: 658
Merit: 500
Dark Wallet is set to launch this week: http://blogs.wsj.com/digits/2014/04/29/dark-wallet-for-managing-bitcoin-arrives-this-week/

I wonder if this centralized solution will fall flat on its face and expose the need for a decentralized anonymous currency? Could be good for Darkcoin.
My 2-cents analogy for Dark Wallet:
About 15 years ago, I was exposed to several radical start-ups in Israel in the fields of betting and forex.
At the time, html looked pale, whereas Flash was really pushing the limits in user experience, animation, etc.

It took time to understand an apparent paradox-
People liked very much the betting and financial presentation of markets in Flash, but apparently where not loading money to their account. At the time, the general thought was it's because people are afraid to give their credit-cards or don't trust the companies...

It took some time until the 'dime fell'. The reason was that people where not trusty of Flash as means to transfer their credit-card details. It was too shinny. Like a honeypot...
When 2 groups of people were offered the choices - an html page for entering their credit-card details (with a secure https lock etc.), or a Flash interface, the numbers were overwhelmingly favorable to html.  

Fast forward to 2014 - Dark Wallet:
From the little I understand, DarkWallet is a plugin for browsers...
I believe people do not trust plug-ins with their money, in the same manner as they did not trust flash.

To strengthen my argument above, I can stress that I've seen more than a few start-ups in the past decade that deal in NFC (Near Field Communications), and other types of mobile payments and eCash. Al have failed... and it wasn't because of the technology.
 



Nice. I never thought about this in the way you have clearly stated. I like your read on the situation. I, myself, would not trust money going through a plugin. Heck, I barely like plugins. I dare say I would fall in with the html group over flash. Very interesting and thought provoking.
sr. member
Activity: 336
Merit: 250
omg ! check this article, i really hope they will not implement the X11 to their ASIC miners

Today, Flower Tech is thrilled to announce several significant accomplishments in our Scrypt ASIC development. Our customers will receive the absolute best in performance, power and value when it comes to Scrypt mining solutions. Our engineering team at Ensilica has made substantial progress on our ASIC, and continue to progress steadily with development as we work towards tape-out. We once again are able to provide the highest performance Scrypt ASIC with the lowest power consumption on the market.
First and foremost, in order to provide our customers with the best value in performance mining hardware, we will be upgrading the Orchid and all customers’ Orchid orders, present and future, to 60 MH/s and will remain at our highly competitive price of $1,900 USD. Our brand new, high-performance miner, the Lilac, will hash at a rate of 300MH/s with the market-best pricing of only $7900.00 USD, hailing in at a market-topping cost per kH of $0.0263 / (kH/s). This ensures the Lilac is the absolute best in performance per dollar on the Scrypt mining market. Lilac pre-orders will be first come first served and will ship according to priority in qeueu. Any existing Orchid customers who wish to upgrade to the Lilac will be given the option to do so and are asked to send an email to [email protected] with an upgrade request.

We are pleased to announce our updated power specifications for the Flower Tech 28nm ASIC. Our skilled engineers have managed to achieve incredibly low power usage for each Flower Technology chip, with numbers tested and confirmed at slightly under 1.8 watts per mega-hash. This milestone is achieved through M.A.S.T. (Massive Array of Scrypt Threads) technology, aimed to minimize consumer power usage and necessary cooling, keeping monthly power bills low and allowing you to mine at a highly efficient rate with maximum performance.

Finally, we are thrilled to announce a huge milestone in both ASIC development and the Scrypt mining community. The Flower Technology ASIC is now capable of mining Scrypt-N in addition to Scrypt proof-of-work coins. This will future-proof your purchase for expanded mining options and increased versatility. Examples of Scrypt-based coins you can mine with our machines includes Litecoin, Dogecoin, Mastercoin, Darkcoin, Isracoin, Auroracoin, Feathercoin, while examples of Scrypt-N coins you can mine with our machines includes Vertcoin, execoin, GPUcoin, CaiShen and PANDA.

Here at Flower Tech we will continue to set the bar in performance, power-saving and versatility. We appreciate the support we have gathered from the community, and will continue to work to improve our units as we work progress towards tape-out.
[30/04/2014 06:56:56] Atef DRIRA: ALSO: WE HAVE SECRETLY BEEN WORKING TO IMPLEMENT SUPPORT FOR SCRYPT-N SUPPORT UP TO N=16384!!!  We have been successful and now our ASIC is capable of mining any Scrypt-N coins such as Vertcoin


But Darkcoin is not a scrypt-based.  I highly doubt their asic would work with x11. If asics did come it would definitely drive to block reward down to 5 and probably help the price that way... so it probably wouldnt be that bad tbh.  Even though I love mining x11 Sad
full member
Activity: 224
Merit: 100
Blah blah pre-order our ASICs they are the best...never heard that before  Roll Eyes
sr. member
Activity: 910
Merit: 260
omg ! check this article, i really hope they will not implement the X11 to their ASIC miners

Today, Flower Tech is thrilled to announce several significant accomplishments in our Scrypt ASIC development. Our customers will receive the absolute best in performance, power and value when it comes to Scrypt mining solutions. Our engineering team at Ensilica has made substantial progress on our ASIC, and continue to progress steadily with development as we work towards tape-out. We once again are able to provide the highest performance Scrypt ASIC with the lowest power consumption on the market.
First and foremost, in order to provide our customers with the best value in performance mining hardware, we will be upgrading the Orchid and all customers’ Orchid orders, present and future, to 60 MH/s and will remain at our highly competitive price of $1,900 USD. Our brand new, high-performance miner, the Lilac, will hash at a rate of 300MH/s with the market-best pricing of only $7900.00 USD, hailing in at a market-topping cost per kH of $0.0263 / (kH/s). This ensures the Lilac is the absolute best in performance per dollar on the Scrypt mining market. Lilac pre-orders will be first come first served and will ship according to priority in qeueu. Any existing Orchid customers who wish to upgrade to the Lilac will be given the option to do so and are asked to send an email to [email protected] with an upgrade request.

We are pleased to announce our updated power specifications for the Flower Tech 28nm ASIC. Our skilled engineers have managed to achieve incredibly low power usage for each Flower Technology chip, with numbers tested and confirmed at slightly under 1.8 watts per mega-hash. This milestone is achieved through M.A.S.T. (Massive Array of Scrypt Threads) technology, aimed to minimize consumer power usage and necessary cooling, keeping monthly power bills low and allowing you to mine at a highly efficient rate with maximum performance.

Finally, we are thrilled to announce a huge milestone in both ASIC development and the Scrypt mining community. The Flower Technology ASIC is now capable of mining Scrypt-N in addition to Scrypt proof-of-work coins. This will future-proof your purchase for expanded mining options and increased versatility. Examples of Scrypt-based coins you can mine with our machines includes Litecoin, Dogecoin, Mastercoin, Darkcoin, Isracoin, Auroracoin, Feathercoin, while examples of Scrypt-N coins you can mine with our machines includes Vertcoin, execoin, GPUcoin, CaiShen and PANDA.

Here at Flower Tech we will continue to set the bar in performance, power-saving and versatility. We appreciate the support we have gathered from the community, and will continue to work to improve our units as we work progress towards tape-out.
ALSO: WE HAVE SECRETLY BEEN WORKING TO IMPLEMENT SUPPORT FOR SCRYPT-N SUPPORT UP TO N=16384!!!  We have been successful and now our ASIC is capable of mining any Scrypt-N coins such as Vertcoin
sr. member
Activity: 291
Merit: 250
Dark Wallet is set to launch this week: http://blogs.wsj.com/digits/2014/04/29/dark-wallet-for-managing-bitcoin-arrives-this-week/

I wonder if this centralized solution will fall flat on its face and expose the need for a decentralized anonymous currency? Could be good for Darkcoin.
My 2-cents analogy for Dark Wallet:
About 15 years ago, I was exposed to several radical start-ups in Israel in the fields of betting and forex.
At the time, html looked pale, whereas Flash was really pushing the limits in user experience, animation, etc.

It took time to understand an apparent paradox-
People liked very much the betting and financial presentation of markets in Flash, but apparently where not loading money to their account. At the time, the general thought was it's because people are afraid to give their credit-cards or don't trust the companies...

It took some time until the 'dime fell'. The reason was that people where not trusty of Flash as means to transfer their credit-card details. It was too shinny. Like a honeypot...
When 2 groups of people were offered the choices - an html page for entering their credit-card details (with a secure https lock etc.), or a Flash interface, the numbers were overwhelmingly favorable to html.  

Fast forward to 2014 - Dark Wallet:
From the little I understand, DarkWallet is a plugin for browsers...
I believe people do not trust plug-ins with their money, in the same manner as they did not trust flash.

To strengthen my argument above, I can stress that I've seen more than a few start-ups in the past decade that deal in NFC (Near Field Communications), and other types of mobile payments and eCash. Al have failed... and it wasn't because of the technology.
 


legendary
Activity: 1790
Merit: 1100
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

newbie
Activity: 37
Merit: 0
sr. member
Activity: 336
Merit: 250
My head hurts.....  Cheesy  Grin

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

Denomitated change addresses!  Grin
full member
Activity: 280
Merit: 100
The Future Of Work
full member
Activity: 280
Merit: 100
The Future Of Work
Ok, here is another attempt:



Remember, I'm just trying to put down what I believe Evan is actually doing
sr. member
Activity: 336
Merit: 250
I spent a fair amount of time thinking about the discussion with dime, humanitee, luigi1111, camosoul and others yesterday about the anonymity of Darksend.  I suspected that the logic behind darksend as currently implemented was not sound, and I thought it would be best to determine how exactly darksend was working, and do an in-depth analysis of a mixing cycle and the transactions that follow mixing.

...

Best,
Sim

Wow! This is great. About 400+ pages ago I talked about having a different kind of pool for change outputs only. Put in all of your change outputs and you'll get new fresh clean inputs of 10DRK. The client could automatically do this after each darksend, which would also get you new inputs for the next round.

I'm currently embedded in patching stratum and p2pool to support the masternode payments, which is why I haven't been around. It takes a lot of work to make something so different from anything else out there, dare I say, revolutionary?


On second thought, I'm not sure this solves the problem.  My understanding is that you want to accumulate the dirty change in the wallet until it breaches a certain amount (say 10 for example), then it is washed in a "change only" wash with a bunch of "10" transactions.  The problem I see is that even the clean coins could be linked to the original transaction.  Just to explain:

John darksends 2 coins from A to C, gets 8 back as change on address X
a few days later..
John darksends 8 coins from B to D, gets 2 back as change on address Y

Y+X are submitted to the change mixing pool (10 coins), and come out "clean" at address Z.

The problem is that the coins at address Z are not clean really, they are "suspect", they could have possibly participated in any darksends that generated the dirty coins that composed the "change washing" pool.

Now when Johns wants to spend coins from A, B, and Z in the same transaction.

So if John wants to send coins from A+B+Z in one transaction, the fact that Z participated in a pool that contained X and Y is enough to expose A and B as the original participants in the darksend transaction.

Really it leaves us at the same position that we were at previously after the original darksends.

I hope that made sense.

I came up with a way better solution to this issue than my previous idea. Plus it's already supported by DarkSend, I'll just enforce it in RC3

John darksends 2.5 coins from A to C, gets 7.5 back as change on address X, Y, V, Z  (X = 5DRK, Y = 1DRK, V = 1DRK, Z=0.5DRK )
Joe darksends 3 coins from E to G, gets 7 back as change on address W, K, J  (W = 5DRK, K = 1DRK, J = 1DRK)
Suzie darksends 3.5 coins from K to Q, gets 6.5 back as change on address F, G, H  (F = 5DRK, G = 1DRK, H = 0.5DRK)

Change is denominated into units of 5, 1, 0.5, 0.25, 0.1, 0.05, and 0.01 DRK. I'll introduce the precision limitation back again of 0.01DRK. So if you get 7.5 DRK of change back, you'll end up with 5DRK+1DRK+1DRK+0.5DRK.

You could still possible do taint analysis on denominations only used once, but this would be solved with multiple rounds in DarkSend.

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 Cheesy

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

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


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  Grin  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.
legendary
Activity: 2674
Merit: 3000
Terminated.
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.
No. This is wrong and people shouldn't practice it. Bitcoin is fine with 10 minute block as well.
full member
Activity: 280
Merit: 100
The Future Of Work

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?

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.

Huh  I'll post another flow chart in a moment which might be how Evan is doing this or going to do this??
full member
Activity: 280
Merit: 100
The Future Of Work
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.
+1000.

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!
legendary
Activity: 2674
Merit: 3000
Terminated.
this could be good por DRK publicity but not so good if the govt try and make a point to shut DRK down.

I really liked the idea posted a few pages back about using crypto/DRK to move money within and in and out of 3rd world countries.  Getting a piece of the Western Union market would be phenomenal.  They charge a ridiculous fee to send money back and forth and to be able to offer people a simple app that works on (almost) any phone to send funds to family members etc could be huge.

I get so excited by this thread, i truly think Evan is a genius and that DRK will be a revolutionary coin.   Nice work people.
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.
sr. member
Activity: 339
Merit: 251
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.
legendary
Activity: 1105
Merit: 1000
I came up with a way better solution to this issue than my previous idea. Plus it's already supported by DarkSend, I'll just enforce it in RC3

John darksends 2.5 coins from A to C, gets 7.5 back as change on address X, Y, V, Z  (X = 5DRK, Y = 1DRK, V = 1DRK, Z=0.5DRK )
Joe darksends 3 coins from E to G, gets 7 back as change on address W, K, J  (W = 5DRK, K = 1DRK, J = 1DRK)
Suzie darksends 3.5 coins from K to Q, gets 6.5 back as change on address F, G, H  (F = 5DRK, G = 1DRK, H = 0.5DRK)

Change is denominated into units of 5, 1, 0.5, 0.25, 0.1, 0.05, and 0.01 DRK. I'll introduce the precision limitation back again of 0.01DRK. So if you get 7.5 DRK of change back, you'll end up with 5DRK+1DRK+1DRK+0.5DRK.

You could still possible do taint analysis on denominations only used once, but this would be solved with multiple rounds in DarkSend.

I'm taking partial credit for it!  Grin Cheesy

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.



This really is brilliant and completely removes the problems we've been brainstorming about (or I'm just tired again (always have an excuse Wink)). Too bad there's not a practical way of implementing it, right? Right?  Huh
legendary
Activity: 1105
Merit: 1000
I spent a fair amount of time thinking about the discussion with dime, humanitee, luigi1111, camosoul and others yesterday about the anonymity of Darksend.  I suspected that the logic behind darksend as currently implemented was not sound, and I thought it would be best to determine how exactly darksend was working, and do an in-depth analysis of a mixing cycle and the transactions that follow mixing.

...

Best,
Sim

Wow! This is great. About 400+ pages ago I talked about having a different kind of pool for change outputs only. Put in all of your change outputs and you'll get new fresh clean inputs of 10DRK. The client could automatically do this after each darksend, which would also get you new inputs for the next round.

I'm currently embedded in patching stratum and p2pool to support the masternode payments, which is why I haven't been around. It takes a lot of work to make something so different from anything else out there, dare I say, revolutionary?


On second thought, I'm not sure this solves the problem.  My understanding is that you want to accumulate the dirty change in the wallet until it breaches a certain amount (say 10 for example), then it is washed in a "change only" wash with a bunch of "10" transactions.  The problem I see is that even the clean coins could be linked to the original transaction.  Just to explain:

John darksends 2 coins from A to C, gets 8 back as change on address X
a few days later..
John darksends 8 coins from B to D, gets 2 back as change on address Y

Y+X are submitted to the change mixing pool (10 coins), and come out "clean" at address Z.

The problem is that the coins at address Z are not clean really, they are "suspect", they could have possibly participated in any darksends that generated the dirty coins that composed the "change washing" pool.

Now when Johns wants to spend coins from A, B, and Z in the same transaction.

So if John wants to send coins from A+B+Z in one transaction, the fact that Z participated in a pool that contained X and Y is enough to expose A and B as the original participants in the darksend transaction.

Really it leaves us at the same position that we were at previously after the original darksends.

I hope that made sense.

I came up with a way better solution to this issue than my previous idea. Plus it's already supported by DarkSend, I'll just enforce it in RC3

John darksends 2.5 coins from A to C, gets 7.5 back as change on address X, Y, V, Z  (X = 5DRK, Y = 1DRK, V = 1DRK, Z=0.5DRK )
Joe darksends 3 coins from E to G, gets 7 back as change on address W, K, J  (W = 5DRK, K = 1DRK, J = 1DRK)
Suzie darksends 3.5 coins from K to Q, gets 6.5 back as change on address F, G, H  (F = 5DRK, G = 1DRK, H = 0.5DRK)

Change is denominated into units of 5, 1, 0.5, 0.25, 0.1, 0.05, and 0.01 DRK. I'll introduce the precision limitation back again of 0.01DRK. So if you get 7.5 DRK of change back, you'll end up with 5DRK+1DRK+1DRK+0.5DRK.

You could still possible do taint analysis on denominations only used once, but this would be solved with multiple rounds in DarkSend.

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 Cheesy

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

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. Smiley
sr. member
Activity: 336
Merit: 250
I came up with a way better solution to this issue than my previous idea. Plus it's already supported by DarkSend, I'll just enforce it in RC3

John darksends 2.5 coins from A to C, gets 7.5 back as change on address X, Y, V, Z  (X = 5DRK, Y = 1DRK, V = 1DRK, Z=0.5DRK )
Joe darksends 3 coins from E to G, gets 7 back as change on address W, K, J  (W = 5DRK, K = 1DRK, J = 1DRK)
Suzie darksends 3.5 coins from K to Q, gets 6.5 back as change on address F, G, H  (F = 5DRK, G = 1DRK, H = 0.5DRK)

Change is denominated into units of 5, 1, 0.5, 0.25, 0.1, 0.05, and 0.01 DRK. I'll introduce the precision limitation back again of 0.01DRK. So if you get 7.5 DRK of change back, you'll end up with 5DRK+1DRK+1DRK+0.5DRK.

You could still possible do taint analysis on denominations only used once, but this would be solved with multiple rounds in DarkSend.

I'm taking partial credit for it!  Grin Cheesy

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.

...

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  Grin. 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.
sr. member
Activity: 336
Merit: 250
I spent a fair amount of time thinking about the discussion with dime, humanitee, luigi1111, camosoul and others yesterday about the anonymity of Darksend.  I suspected that the logic behind darksend as currently implemented was not sound, and I thought it would be best to determine how exactly darksend was working, and do an in-depth analysis of a mixing cycle and the transactions that follow mixing.

...

Best,
Sim

Wow! This is great. About 400+ pages ago I talked about having a different kind of pool for change outputs only. Put in all of your change outputs and you'll get new fresh clean inputs of 10DRK. The client could automatically do this after each darksend, which would also get you new inputs for the next round.

I'm currently embedded in patching stratum and p2pool to support the masternode payments, which is why I haven't been around. It takes a lot of work to make something so different from anything else out there, dare I say, revolutionary?


On second thought, I'm not sure this solves the problem.  My understanding is that you want to accumulate the dirty change in the wallet until it breaches a certain amount (say 10 for example), then it is washed in a "change only" wash with a bunch of "10" transactions.  The problem I see is that even the clean coins could be linked to the original transaction.  Just to explain:

John darksends 2 coins from A to C, gets 8 back as change on address X
a few days later..
John darksends 8 coins from B to D, gets 2 back as change on address Y

Y+X are submitted to the change mixing pool (10 coins), and come out "clean" at address Z.

The problem is that the coins at address Z are not clean really, they are "suspect", they could have possibly participated in any darksends that generated the dirty coins that composed the "change washing" pool.

Now when Johns wants to spend coins from A, B, and Z in the same transaction.

So if John wants to send coins from A+B+Z in one transaction, the fact that Z participated in a pool that contained X and Y is enough to expose A and B as the original participants in the darksend transaction.

Really it leaves us at the same position that we were at previously after the original darksends.

I hope that made sense.

I came up with a way better solution to this issue than my previous idea. Plus it's already supported by DarkSend, I'll just enforce it in RC3

John darksends 2.5 coins from A to C, gets 7.5 back as change on address X, Y, V, Z  (X = 5DRK, Y = 1DRK, V = 1DRK, Z=0.5DRK )
Joe darksends 3 coins from E to G, gets 7 back as change on address W, K, J  (W = 5DRK, K = 1DRK, J = 1DRK)
Suzie darksends 3.5 coins from K to Q, gets 6.5 back as change on address F, G, H  (F = 5DRK, G = 1DRK, H = 0.5DRK)

Change is denominated into units of 5, 1, 0.5, 0.25, 0.1, 0.05, and 0.01 DRK. I'll introduce the precision limitation back again of 0.01DRK. So if you get 7.5 DRK of change back, you'll end up with 5DRK+1DRK+1DRK+0.5DRK.

You could still possible do taint analysis on denominations only used once, but this would be solved with multiple rounds in DarkSend.

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 Cheesy
Jump to: