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

@Simcom Every time you believe that you may have find a flaw with DarkSend but yet you don't seem to totally understand or know about the way it works. Take your time to read the thread, some of your questions and concerns have already been answered long ago.

Oh that was not my idea.
It's written on White paper.

http://www.darkcoin.io/downloads/DarkcoinWhitepaper.pdf

Yea, I guess that is true - there is still some uncertainty provided by the pool, especially if transactions go through multiple darksend "washes" before they arrive at their final destination.  We might be able to infer who sent who what, but  it would be impossible to prove with mathematical certainty that it was true.

What is the plan with transaction (perhaps blockchain?) encryption? I seem to recall something like that being mentioned.

Well, I agree with your analysis. These are problems that Evan can and will solve it will just take time. I just need to relax and have faith that in the end we will think of all of the possible issues and that all will have viable solutions. Sometimes when I discover an issue with the logic and I can't immediately think of a solution I assume there is no solution - but after some time someone thinks of a solution.  This happened in an earlier post, Evan thought of an ingenious solution (denominating change, sending to multiple addresses), which solved the problem that I presented.    Requiring 1000 coins for a darksend of 101 had me in a similar panic.  I actually think this issue will be easier to solve than the last issue, but it will require quite a lot of coding on evan's part (ie the masternodes will need to determine when the amount of complexity in the pool is sufficient to ensure anonymity is maintained, just starting the mixing after a certain # of inputs will not be sufficient).  Combined with chaeplins idea I think we have something viable, still not perfect but viable.

The best solution I can think of...
If you want to send 221 from address A to address B:

if Total_Coins >= 1000 then
{
  1 entries into the 1000 coin pool
}

if Total_Coins >= 300 then
{
  3 entries into the 100 coin pool
}

if Total_Coins >= 230 then
{
   2 entries into the 100 coin pool
   3 entries into the 10 coin pool
}

if Total_Coins >= 221 then
{
   2 entries into the 100 coin pool
   2 entries into the 10 coin pool
   1 entries into the 1 coin pool
}

if Total_Coins < 221 then
{
   error
}

Assumption, can't be a legal proof.
Each Darksend need at least 3 input from others.

Because if you send all 101 coins to the same address it will be obvious that 101 coins left your address and 101 coins appeared at another address some time later - regardless of how much mixing occurs in between.

Yea I thought of this solution too but you still run into the same problem

Address A (slowly loses) -221 coins
Address B (slowly gains) +221 coins

The only difference is that this would occur over a couple of hours instead of a couple of minutes. :/

I think the only real solution is to send denominated amounts to multiple receiving addresses instead of a single receiving address.

Why is it that when you want to Darksend 101 coins, Darksend uses the 1000 pool, rather than breaking the transaction and using the smaller pools?

If someone need Darksend 221, wallet could do(automatically)
1) Darksend largest(or second or ..) pool size coin first --> 100 + 100
2) after random number of confirmation( 1 ~ 6), Darksend second largest or smallest
3) after random number of confirmation( 1 ~ 6), Darksend remains.


But I will prefer exact pool size Darksend.

As far as I know, the plan has been to populate the denomination pools with various sizes. It wasn't about just one pool - that's now, not the final. In any case, even if there is a practical limitation at some size, it could be solved with two deposits, no?

I suspect you have deeper concerns for DarkSend than that and it's good you keep poking the thread so that we can get the best product available. Technological criticism is good. We've had discussions in the past where someone could say "oh DarkSend is broken" (that's when it had quite different specs) and the price would tank (ok it would drop, not tank), but we are somewhat past that point now due to more people understanding that something in development can actually "shapeshift" into new forms that deal with prior problems, before it solidifies as a final product. And even then it can (and will) be improved.

I know you lack intelligent counter-arguments for some of the issues presented but this is not a cryptographic mailing list and the level of discussion is consequently not up to standard. The people that can intelligently and factually discuss these issues, in this thread, are perhaps numbered in the fingers of one hand.

If there is one weakness I can say that it can present problems is that Evan is just one man. Given that the day has only 24 hours and he must do all the work alone, plus run a pool, answer pms, follow discussions or chats, or I don't know what else his tasklist entails, it will be that either the work will be delayed, or the work will go on schedule but not be top-notch in terms of quality refinement (=appearing "sloppy"), or a mix of these two depending the situation.

I've heard/read some criticism (perceived as sloppiness or "not being a serious" coin), like the broken libs in the wallets, the versioning numbers on the beta/rc clients, the dgw requiring multiple versions to be ok, the tray icon of the xcoin, a complain about something that was unchanged from litecoin and worldcoin and that does some network fuckup between lite/world and dark networks and which needs a hard fork to fix, the issue of the problematic network sync for some wallets, the diff issue when the coin started etc etc. DarkSend operation has also been criticized until proposed solutions were discussed.

One can stretch this line of reasoning and say "if there are so many problems with simple stuff, what guarantees that DarkSend will work 100% from the start?" and the answer will most probably be something like "it won't - it'll have to be patched/hardened/have some elements rewritten as it goes along".

For a programmer the "ok this broke, we'll fix it with a patch" may be the most natural response, but when millions of USD are engaged then things start to get "bumpy" in the charts. Satoshi and others had the relative comfort of time to develop stuff because there was not so much economic pressure: The market wasn't mature and nobody cared. Here people have already put money and thus can panic or lose confidence or not engage due to some things appearing sketchy / problematic / sloppy, etc. Of course the speculative nature of the investment also determines the (low) price, for if we had an ironed out and 100% working / hardened tech, right now, the price wouldn't be low - so, in a sense, it balances out because it's already factored into the price.

My personal stance on the issue is that I understand the limitations of having just one man to do the job but backing the coin is a given because it offers something significant in terms of technology which aims at an even more significant market segment that can be in the billions. I am a computer guy so I can understand the issues of coding but I can also understand the end-user or investor perspective of those who are less tolerant when a string of perceived glitches / failures can seem sketchy for the overall project, or when some questions or info presented cast shadows over the project. I am prepared for bumps (ups and downs) that may come up as a result of the situation but I am in for the long term, so these won't really affect me. For the shorter term, the bumps of ups and downs can be desirable because the volatility can present great trading opportunities but in the mid-term they must be reduced significantly so as to have a stable currency. In any case, it's always better to be actually backing something up that has some technology in it, rather than backing a shitcoin that offers nothing.

The only factor that may counter your spot on analysis:

It doesn't matter how the transactions are broken up, it will be obvious looking at the blockchain that Address A drops exactly 221 coins and a few minutes later Address B increases exactly 221 coins.

EDIT:
Yes total is -221.
But transaction would be -100 + -100 + -10 + -10 + -1
And each Darksend need 3 inputs.

Dude you seem obviously technically very bright I think you are so bright you are blinded by it. Thank you. I bought 5BTC more today and didn't know who to thank.

Zerocoin wont even touch us. Dark is the future brahs

great cheap coins keep going time to buy

I still have a lot left, but I do think my concerns are warranted.  I asked the same question earlier today and got no good solution from anyone, chaeplin's solution is good but not perfect (as far as I can tell). This will be a big drawback if Zerocoin is launched with no such limitation.

Evan claimed that the 1000 coin pool would be used for any amount between 101-1000

Your solution is pretty good IMO.

But there are problems..

If you want to send 221 from address A to address B:

2 entries into the 100 coin pool
2 entries the 10 coin pool
1 entry into the 1 coin pool

So on the blockchain it would show

Address A -221 coins ... some time later
Address B +221 coins - so it would be easy to determine that A sent coins to B

I like your idea of using the 10 coin pool to handle the extra 1 coin, so only 230 coins are needed.

If you want to send 221 from address A to address B (assuming the wallet with Address A has 230 coins):

2 entries into the 100 coin pool
3 entries into the 10 coin pool

Address A -230 coins ... some time later
Address B +221 coins

This still might be enough to prove that A is the sender to B - depending on how many other entries are entered into the 100 coin pool.


It's going to be a big issue in practice because when someone has exactly 221 coins, and they want to darksend 221 coins, they are going to get an error message that they need 230 coins to send 221, so instead they will submit a 220+1 to the same address, which will out them (see example above).