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

great cheap coins keep going time to buy

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.

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.

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.

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?

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.

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
}

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

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

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