[ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency

[eizh]

https://bitcointalk.org/index.php?topic=579976.msg6335710#msg6335710

7k DRK will be worth around $60k  

If the market expectations were actually that one-sided, it would be built into the price already. There's no free lunch to be had here and no way to escape the risk-reward tradeoff. Enough people disagree that there's insufficient demand at a higher price. The fact that they didn't bother to vote merely shows that polls don't work.

[Simcom]

pool : 10, 100, 1000
darkssend 10.1 coins --> 10 + 0.1   --> need 10 + 10 coins, not 100
darkssend 101 coins --> 100 + 1  ---> need 100 + 10 coins , not 1000

Need more smallest pool's size.

Isn't it ?

If there is 1 coin pool, just need 1 coin more.

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

[Simcom]

Wow you sold 7k DRK for that   lol !! That's some panic  

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.

[solo20]

great cheap coins keep going time to buy

[fearcoka]

Zerocoin wont even touch us. Dark is the future brahs

[Minotaur26]

Wow you sold 7k DRK for that   lol !! That's some panic  

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.

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.

[chaeplin]

pool : 10, 100, 1000
darkssend 10.1 coins --> 10 + 0.1   --> need 10 + 10 coins, not 100
darkssend 101 coins --> 100 + 1  ---> need 100 + 10 coins , not 1000

Need more smallest pool's size.

Isn't it ?

If there is 1 coin pool, just need 1 coin more.

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

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

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 infer that A is the sender to B - depending on the other entries into the 100 coin pool.


It's going to suck 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).

[Simcom]

pool : 10, 100, 1000
darkssend 10.1 coins --> 10 + 0.1   --> need 10 + 10 coins, not 100
darkssend 101 coins --> 100 + 1  ---> need 100 + 10 coins , not 1000

Need more smallest pool's size.

Isn't it ?

If there is 1 coin pool, just need 1 coin more.

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

Yes total is -221.
But transaction would be -100 + -100 + -1

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.

[coins101]

https://bitcointalk.org/index.php?topic=579976.msg6335710#msg6335710

7k DRK will be worth around $60k  

If the market expectations were actually that one-sided, it would be built into the price already. There's no free lunch to be had here and no way to escape the risk-reward tradeoff. Enough people disagree that there's insufficient demand at a higher price. The fact that they didn't bother to vote merely shows that polls don't work.

The only factor that may counter your spot on analysis:

[AlexGR]

If you want to darksend 1.1 coins you need to have 10 coins in your wallet.

So back to my confession - when I discovered this issue I panicked a bit and sold 7,000 coins and tanked the market  Sad.  

Now for the good news, if anyone can come up with an ingenious solution to this problem I'll buy back all of these coins in an instant. Put your thinking caps on

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.

[chaeplin]

pool : 10, 100, 1000
darkssend 10.1 coins --> 10 + 0.1   --> need 10 + 10 coins, not 100
darkssend 101 coins --> 100 + 1  ---> need 100 + 10 coins , not 1000

Need more smallest pool's size.

Isn't it ?

If there is 1 coin pool, just need 1 coin more.

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

Yes total is -221.
But transaction would be -100 + -100 + -1

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.

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.

[Brilliantrocket]

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?

[Simcom]

pool : 10, 100, 1000
darkssend 10.1 coins --> 10 + 0.1   --> need 10 + 10 coins, not 100
darkssend 101 coins --> 100 + 1  ---> need 100 + 10 coins , not 1000

Need more smallest pool's size.

Isn't it ?

If there is 1 coin pool, just need 1 coin more.

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

Yes total is -221.
But transaction would be -100 + -100 + -1

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.

If someone need Darksend 221, wallet could do
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.

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.

[Simcom]

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.

[chaeplin]

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.

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

[AD_Infinitum]

pool : 10, 100, 1000
darkssend 10.1 coins --> 10 + 0.1   --> need 10 + 10 coins, not 100
darkssend 101 coins --> 100 + 1  ---> need 100 + 10 coins , not 1000

Need more smallest pool's size.

Isn't it ?

If there is 1 coin pool, just need 1 coin more.

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

Yes total is -221.
But transaction would be -100 + -100 + -1

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.

If someone need Darksend 221, wallet could do
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.

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.

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
}

[Simcom]

...

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.

....

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.

[Brilliantrocket]

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

[Simcom]

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.

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

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.

[chaeplin]

...

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.

....

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.

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

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

Improved Anonymity
An  anonymity enhancement to the generic CoinJoin implementation  is added by only allowing
inputs of the same size into the DarkSend pools. These sizes are referred to as “denominations”
and are in  powers of  ten  (for example,  1DRK, 10DRK, 100DRK, 1000DRK). This allows the
inputs from all users to be virtually the same. Outputs per user must add up to the denomination
size.

Users  that send less money than the denomination size will use a second “change” output.
These outputs are new addresses not connected to their identity. This implementation allows for
amounts of any precision to be sent without a negative impact in the quality of anonymity. 
All users  entering a DarkSend transaction pool have an equal chance of becoming the master 
node.  All  participant  nodes  know  which  node  is  the  current  master  by  way  of  an  election 
algorithm. Master nodes also have a collateral transaction that is made out to the payment node, 
which can be cashed if they misbehave in any way.

In  the  case  where  a  master  node  loses  internet  connection  or  is  a  bad  actor, the collateral 
transaction of that node will be cashed and a slave node will be elected in it’s place. Due to the 
trustless nature  of DarkSend, there is no risk of lost money from the master node being a bad 
actor  as a slave node would be elected to replace the master node and the collateral would be 
forfeited to the network.