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

[CHAOSiTEC]

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.

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

[AnonyMint]

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

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.

[coins101]

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

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.

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

[IloveAnonCoin]

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

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.

It is flaws in design, not bugs in implement, Period.

[AnonyMint]

It is flaws in design, not bugs in implement, Period.

Agreed.

But let's wait to hear developers response. Maybe somehow he is more clever than me. I don't see how to make CoinJoin work well. Maybe somehow he did, but I very strongly doubt it.

[AnonyMint]

He can implement my divide-and-conquer idea. Then at least you get some anonymity guaranteed. It is impossible to completely DOS attack that.

I don't really like it as a great solution, but it will work to provide limited mixing.

[Kai Proctor]

Next step : he will ask for the source  

1...2...3...

[LimLims]

If we assign a penalty payment transaction to the Participant before step 2, then the adversary can refuse to provide the penalty payment transaction

Why not have the master node simply wait until the required number of participants have actually provided the collateral payment transaction? This should take the same amount of time whether or not a DOS is occurring, because that depends on the rate of legit participants trying to enter the pool, which is unaffected by the illegitimate participants.

Or in other words: I don't see why a refusal to provide collateral by one participant has to kill the pooling process. They could simply be ignored beyond that point (and perhaps eventually banned), and the pooling continue.

[ErrorId]

That's what is hard for me, being totally new. This is the first major dip I've seen/been a part of, whereas people who've been around for a while may feel more comfortable that it'll probably go back up. My first instinct is to cash out (I don't have a lot invested so it's not money, just get the maybe irrational panicky feeling of seeing the red) but I'm hanging on. 

Fear and greed. That's the two basic emotions it comes down to when you see stuff like this happening. If you can control those emotions you can make a lot of money.

[Kai Proctor]

At one point I'm sure one of them will say : "Hmmm I'm not convinced, show me the source code I'm sure I will detect some flaws".

[LimLims]

At one point I'm sure one of them will say : "Hmmm I'm not convinced, show me the source code I'm sure I will detect some flaws".

That's the plan, down the track. Before open sourcing Evan wants more beta testing & a vetting of the code by a 3rd party. But eventually it will be thoroughly picked apart by the community.

[AnonyMint]

If we assign a penalty payment transaction to the Participant before step 2, then the adversary can refuse to provide the penalty payment transaction

Why not have the master node simply wait until the required number of participants have actually provided the collateral payment transaction? This should take the same amount of time whether or not a DOS is occurring, because that depends on the rate of legit participants trying to enter the pool, which is unaffected by the illegitimate participants.

You are very confused. The point is the inputs have already been provided. Providing the inputs didn't take 0 time. Thus refusing to provide the collateral payment forces us back to step 1 again and repeat the collection of the inputs.

How do you ban the participant who refused to provide the collateral payment? By IP address? So he uses a botnet.

Or in other words: I don't see why a refusal to provide collateral by one participant has to kill the pooling process. They could simply be ignored beyond that point (and perhaps eventually banned), and the pooling continue.

Ignored how? You collect the inputs you don't know who the bad guy is yet. Then you find out who he is, so you must repeat the collection of the inputs (to get rid of his input because you don't know which one it is). How do you ban him from the repeat? By IP? He will use a botnet have zillions of IP addresses. Botnets cost $100.

[IloveAnonCoin]

At one point I'm sure one of them will say : "Hmmm I'm not convinced, show me the source code I'm sure I will detect some flaws".

Dude, sometime people share their though, you should listening. if you have better method, please provide. if not, please read carefully what they said, don't ack like you know it all.

[coins101]

If we assign a penalty payment transaction to the Participant before step 2, then the adversary can refuse to provide the penalty payment transaction

Why not have the master node simply wait until the required number of participants have actually provided the collateral payment transaction? This should take the same amount of time whether or not a DOS is occurring, because that depends on the rate of legit participants trying to enter the pool, which is unaffected by the illegitimate participants.

You are very confused. The point is the inputs have already been provided. Providing the inputs didn't take 0 time. Thus refusing to provide the collateral payment forces us back to step 1 again and repeat the collection of the inputs.

How do you ban the participant who refused to provide the collateral payment? By IP address? So he uses a botnet.

Or in other words: I don't see why a refusal to provide collateral by one participant has to kill the pooling process. They could simply be ignored beyond that point (and perhaps eventually banned), and the pooling continue.

Ignored how? You collect the inputs you don't know who the bad guy is yet. Then you find out who he is, so you must repeat the collection of the inputs (to get rid of his input because you don't know which one it is). How do you ban him from the repeat? By IP? He will use a botnet have zillions of IP addresses. Botnets cost $100.

I'm not technical....but (I asked before)

What if DarkSend has a de minimis payment requirement. Participation is costly for everyone apart from those that want the service, when the cost is considered in the context of obtaining value.

Entering the network requires fees to be paid, so why not say darksend minimum of $x transaction value, with x% fee.  Using darkcoin is relatively cheap. Using DarkSend is an extra feature with added cost. Then you have multiple cost barriers within the system making attacks pointless to those who attack for trivial reasons, I would have thought. The same way PoW for email was considered to avoid spam.

The transactions are being handled by the wallet. Isn't there a way to make anyone that develops a wallet the equivalent of having to go through https?

[Kai Proctor]

At one point I'm sure one of them will say : "Hmmm I'm not convinced, show me the source code I'm sure I will detect some flaws".

Dude, sometime people share their though, you should listening. if you have better method, please provide. if not, please read carefully what they said, don't ack like you know it all.

Yeah right the pot, the kettle ... You don't share you troll (e.g. your posts in the last 24h)

At one point I'm sure one of them will say : "Hmmm I'm not convinced, show me the source code I'm sure I will detect some flaws".

That's the plan, down the track. Before open sourcing Evan wants more beta testing & a vetting of the code by a 3rd party. But eventually it will be thoroughly picked apart by the community.

Yeah I know, but somebody renowned in the field not some "Anon<Insert Coin Name>" guys who might have an agenda.

[AnonyMint]

If we assign a penalty payment transaction to the Participant before step 2, then the adversary can refuse to provide the penalty payment transaction

Why not have the master node simply wait until the required number of participants have actually provided the collateral payment transaction? This should take the same amount of time whether or not a DOS is occurring, because that depends on the rate of legit participants trying to enter the pool, which is unaffected by the illegitimate participants.

You are very confused. The point is the inputs have already been provided. Providing the inputs didn't take 0 time. Thus refusing to provide the collateral payment forces us back to step 1 again and repeat the collection of the inputs.

How do you ban the participant who refused to provide the collateral payment? By IP address? So he uses a botnet.

Or in other words: I don't see why a refusal to provide collateral by one participant has to kill the pooling process. They could simply be ignored beyond that point (and perhaps eventually banned), and the pooling continue.

Ignored how? You collect the inputs you don't know who the bad guy is yet. Then you find out who he is, so you must repeat the collection of the inputs (to get rid of his input because you don't know which one it is). How do you ban him from the repeat? By IP? He will use a botnet have zillions of IP addresses. Botnets cost $100.

I'm not technical....but (I asked before)

What if DarkSend has a de minimis payment requirement. Participation is costly for everyone apart from those that want the service, when the cost is considered in the context of obtaining value.

Entering the network requires fees to be paid, so why not say darksend minimum of $x transaction value, with x% fee.  Using darkcoin is relatively cheap. Using DarkSend is an extra feature with added cost. Then you have multiple cost barriers within the system making attacks pointless to those who attack for trivial reasons, I would have thought. The same way PoW for email was considered to avoid spam.

The transactions are being handled by the wallet. Isn't there a way to make anyone that develops a wallet the equivalent of having to go through https?

Do you mean everyone pays a fee to enter a CoinJoin? Even when it fails due to DOS? 

[ErrorId]

If we assign a penalty payment transaction to the Participant before step 2, then the adversary can refuse to provide the penalty payment transaction

Why not have the master node simply wait until the required number of participants have actually provided the collateral payment transaction? This should take the same amount of time whether or not a DOS is occurring, because that depends on the rate of legit participants trying to enter the pool, which is unaffected by the illegitimate participants.

You are very confused. The point is the inputs have already been provided. Providing the inputs didn't take 0 time. Thus refusing to provide the collateral payment forces us back to step 1 again and repeat the collection of the inputs.

How do you ban the participant who refused to provide the collateral payment? By IP address? So he uses a botnet.

Or in other words: I don't see why a refusal to provide collateral by one participant has to kill the pooling process. They could simply be ignored beyond that point (and perhaps eventually banned), and the pooling continue.

Ignored how? You collect the inputs you don't know who the bad guy is yet. Then you find out who he is, so you must repeat the collection of the inputs (to get rid of his input because you don't know which one it is). How do you ban him from the repeat? By IP? He will use a botnet have zillions of IP addresses. Botnets cost $100.

I'm not technical....but (I asked before)

What if DarkSend has a de minimis payment requirement. Participation is costly for everyone apart from those that want the service, when the cost is considered in the context of obtaining value.

Entering the network requires fees to be paid, so why not say darksend minimum of $x transaction value, with x% fee.  Using darkcoin is relatively cheap. Using DarkSend is an extra feature with added cost. Then you have multiple cost barriers within the system making attacks pointless to those who attack for trivial reasons, I would have thought. The same way PoW for email was considered to avoid spam.

The transactions are being handled by the wallet. Isn't there a way to make anyone that develops a wallet the equivalent of having to go through https?

Do you mean everyone pays a fee to enter a CoinJoin? Even when it fails due to DOS?  

Thanks for looking at this, the more eyes and people trying to break it the stronger the system can become. Have you seen the below? What's your take on it.

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.
Payment nodes are simply the last node to create a block specifically,
the last block solver and
the one before that. These nodes will monitor DarkSend for misbehavior. Should any be
discovered, the payment nodes will “cash” the transaction by signing and broadcasting it. This
has the added benefit of creating a sustainable income stream in
addition to mining for
miners, while simultaneously protecting the network from attackers.
The collateral transaction is made to multiple payment nodes. Cashing collateral transactions
require multiple signatures from the user, payment node 1 and payment node 2.
Collateral forfeited to the network will be paid to the payment nodes, which are the last two nodes
to solve a block. These nodes will commonly be the pools. To cash the collateral transactions
and take all of the money, multiple pool operators would

[LimLims]

If we assign a penalty payment transaction to the Participant before step 2, then the adversary can refuse to provide the penalty payment transaction

Why not have the master node simply wait until the required number of participants have actually provided the collateral payment transaction? This should take the same amount of time whether or not a DOS is occurring, because that depends on the rate of legit participants trying to enter the pool, which is unaffected by the illegitimate participants.

You are very confused. The point is the inputs have already been provided. Providing the inputs didn't take 0 time. Thus refusing to provide the collateral payment forces us back to step 1 again and repeat the collection of the inputs.

Sorry, I should have been more clear. I meant, if collateral is provided as the very first step (before the inputs). But I see the point that you'd then not know who to penalise beyond the blind signing stage.

How do you ban the participant who refused to provide the collateral payment? By IP address? So he uses a botnet.

If IP bans are employed, a botnet running a DOS would be quickly mitigated. Although I'm not sure how one would implement IP banning in a decentralised manner. But then, I'm a bit clueless, so maybe that part is easy.

[n00bnoxious]

If we assign a penalty payment transaction to the Participant before step 2, then the adversary can refuse to provide the penalty payment transaction

Why not have the master node simply wait until the required number of participants have actually provided the collateral payment transaction? This should take the same amount of time whether or not a DOS is occurring, because that depends on the rate of legit participants trying to enter the pool, which is unaffected by the illegitimate participants.

You are very confused. The point is the inputs have already been provided. Providing the inputs didn't take 0 time. Thus refusing to provide the collateral payment forces us back to step 1 again and repeat the collection of the inputs.

Sorry, I should have been more clear. I meant, if collateral is provided as the very first step (before the inputs). But I see the point that you'd then not know who to penalise beyond the blind signing stage.

How do you ban the participant who refused to provide the collateral payment? By IP address? So he uses a botnet.

If IP bans are employed, a botnet running a DOS would be quickly mitigated. Although I'm not sure how one would implement IP banning in a decentralised manner. But then, I'm a bit clueless, so maybe that part is easy.

IP bans wouldn't do much - the majority of home broadband users are on dynamic IPs, so you'd end up with thousands or millions of perfectly ok IPs being blacklisted, after that user's routing equipment had already gone and fetched a new IP via DHCP, and detecting when an infected user's IP has changed is trivial for the botnet owner.

[AnonyMint]

Remember you have my divide-and-conquer idea to fall back on as last resort, so everything isn't lost no matter what. It is not very ideal solution though.

ErrorId, I already addressed that in my posts today. What you quoted doesn't change my point.