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

What if DarkSend has a de minimis payment requirement. Participation is costly for everyone apart from those that want the service?

As a programmer I can reduce that to its essential logic. You still have to associate the payment with the inputs else the input collection stage can be forced to repeat over and over again at no penality.

There is no way around the issue. It is fundamental.

As far as i remember, the collateral is not send per see. But the node give the info to the network, and the network is then able to cash it IF you refuse at some point. Thereby not doing the payment unless dosing the system that way all the partitipants are still protected, and only the dosing party revealed

Let me try to explain it one more time.

CoinJoin has the following steps:

1. Participants provide their inputs key addresses (that they will use to sign in step 3).
2. Participants blind sign output addresses (and the list from step 1) so it is not possible to see who signed which output address.
3. Participants sign their inputs to the transaction that includes all the inputs and outputs.

If we assign a penalty payment transaction to the Participant before step 1, then the blind signing in step 2 is useless, because we can associate the input addresses to the output addresses.

If we assign a penalty payment transaction to the Participant before step 2, then the adversary can refuse to provide the penalty payment transaction and we must go back to repeat step 1 without being able to penalize the adversary.

There is no solution. CoinJoin is a broken idea.

The only pseudo-"solution" I ever thought of was to use divide-and-conquer to find the adversary, i.e. split the list of participants in two when try again. But the problem is the adversary can just proceed before you isolate him. So he still DOS a percentage of the DarkSends.

The smaller the Participants set, the less of DOS problem you have if you use the divide-and-conquer. So you could just do very small mixes. And then users need to mix numerous times to get a larger Participants set. Your anonymity depends on a large Participants set. But then the problem is the DOS percentage will increase by the number of times you need to pass through the mixer, e.g. if 1 time through mixer has 5% DOS rate, then 5 times through it has a 25% DOS rate.

None of the pseudo-"solution"s are really good.

I don't understand it well enough to give you an answer. *Paging Evan*

I do appreciate that you put time into thinking this through. I might have a read through the debate you linked to when I have some time.

If all the participants to a mix "collect their inputs", then they provide their penalty payment. Then the DOS attack comes in that second step where not all provide their penalty payment. Thus restart and "collect inputs" again. And again, and again and again. Forever.

If the penalty payment is provided before "collect their inputs", then the system knows who is the owner of the input and the output, and thus anonymity is broken.

Doesn't the refusal to sign only have to be correlated with the 0.1 DRK collateral for this to work?

By definition if anyone can correlate who didn't sign an output to the one who provided an input, then the anonymity is broken.

So the only way the penalty fee payment could be uncorrelated from the inputs to the transaction, is to create the penalty payment after providing the inputs. Thus one could DOS at that point and refuse to provide the penalty payment.

Indeed they can prevent DOS if they break the anonymity by correlating your penalty payment to both your input and output.

I don't claim to understand this perfectly -- but does this part of the whitepaper contradict you here?

[snip]
To defend against various attacks, DarkSend implements  a collateral system.  A transaction for
0.1DRK  is  made  out  to  the payment  node  to  ensure  proper  usage  of  the  system.  This
transaction  is  separate from the  funds added to the DarkSend pool.  If a user submits an input
but  refuses  to  sign  or  leaves  at  any  stage,  the  payment  node  will  “cash” the  transaction
by signing  and  broadcasting  it.  Collateral  transactions require multiple signatures to complete
from more than one payment node.
[/snip]

You can still DOS free-of-charge in the stage of providing the outputs. You can't identify the signers of the inputs to know who to charge a fee until the last stage where all inputs need to be signed to the transaction.

By definition the blind signing of the outputs has to be uncorrelated with the inputs.

http://www.darkcoin.io/downloads/DarkSendDocumentation.pdf#page=2

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

already answerd
https://bitcointalksearch.org/topic/m.5643365

CoinJoin can't work. Period. I had another debate in the CoinJoin thread a few weeks ago with gmaxwell and I won. Go read it for yourself.

The problem is you can't prevent someone from denial-of-service attacking by refusing to sign the second stage of the operation. They can block all DarkSends this way.

There is not any anonymity offered by DarkSend, because the shorts will simply attack it once the coin becomes valuable and DarkSends won't get processed. The system will jam. And the price will plummet.

I am not talking about DOS protection against sending transactions. Your developer misunderstood me before. I am talking about denial by refusing to sign the second stage of the DarkSend. Then the DarkSend has to reset and start over again. The attacker can do this over and over, and blacklisting can't work. If you blacklist the IP address, he can just get a botnet. If you blacklist the block chain address, he will just go through another instance of the DarkSend that uses a different blacklist. If you use one blacklist system wide, then you can have cheating miners or pools who cause legitimate users to become blacklisted.

http://www.cryptocoinsnews.com/2014/02/24/interview-anoncoin-developer-speaks-zerocoin-implementation/


They never PM'ed me as I requested. I don't spend my time monitoring that DK thread that has several pages per day of new posts.

Did they attempt to do anything to deal with DOS-attacks? The problem is that if you blacklist the input address, someone can just go create another input address (even passing through another instance of the mixer). If they are sharing a single blacklist coin-wide, then it is not a decentralized coin (i.e. some pools could lie and cause addresses to become unspendable). Etc, etc, etc.

Nothing in their whitepaper about DOS protection:

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

85 designs submitted on the designcrowd site! Should be a lot of great options, can't wait to see them in ~2 days.

A c h m a c h i n g !

It's code... code can break if it's not clean, extremely well thought out, trial-tested, reviewed, etc etc. It needs time to be patched to better levels of reliable functionality and prove itself, just like BTC code is taking years and still has questionmarks if something can break it and render it useless. Even things like stratum, kgw, dgw, need fixing. You can't have complicated code working flawlessly from day 1, no matter the assurances. That's just how it is.

It's always better to have realistic expectations rather than unrealistic ones because that way no disillusionment can occur later on and comments like "ohhhhhh disaster, darksend is a flop" start to spring up after some bug or something.

They are wonderful man, congrats!

I agree, I'm pleased with this currency..

Alter Schwede! I absolutely love this design. Very clean and professional, also looks good as small icon and incorporates the way DarkSend works!
When will be able to vote for the final design?

Hehe fun thing.

We all believe in Eduffield but we are a bit skeptical towards Darksend.

So.. Eduffield if you just say it will work for sure, we all can start buying more DRK!

If the gamble is hedged by integrating further layers of user anonymity beyond DarkSend, any potential risk is reduced significantly. If DarkSend is the only layer, and under certain circumstances the identity is uncovered, it's a single point of failure situation: You need something extra, whether it is IP obfuscation, or something else (preferably as many layers as you can get).