An attack on DevShares

[sumantso]

We need to have DevShares listed somewhere to give it some value. Maybe Bter or Yunbi will be willing to do so.

[cube]

Right, there only needs to be a surprise if there is actual malicious intent. If there exists a known vulnerability that only works when it is unanticipated, then either a) it needs to be always anticipated or b) something needs to be fixed to no longer need to constantly anticipate. In either case, in terms of strengthening the network, nothing is gained by exploiting this kind of vulnerability if it is known.

If the exact details of an attack is known, wouldn't the voters and community members be actively monitor and defend against it?  The apathy voters would suddenly spring into life and monitor the forum thread frequently.  These are the things that they do not do in any usual day.  And if the attack can fail so easily due a pre-warn, what kind of credibility (or rather 'discredibility') would Come-from-Beyond get out of it?  Would he spend the time, effort and monies to get this result?

[fluxer555]

Right, there only needs to be a surprise if there is actual malicious intent. If there exists a known vulnerability that only works when it is unanticipated, then either a) it needs to be always anticipated or b) something needs to be fixed to no longer need to constantly anticipate. In either case, in terms of strengthening the network, nothing is gained by exploiting this kind of vulnerability if it is known.

[Troglodactyl]

Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work.

Good idea, will do it this way.

0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?

Is it not easier to defend from an attack when it is known how and when it will be executed?
I would say the first step is to attack DevShares without informing the community when and how it will happen...

One of the elements for a successful attack is 'surprise'.  If we take this element out, I doubt it can have a successful outcome.

If the goal is to damage the network, this is true.  If the goal is to strengthen the network by discovering any vulnerabilities, then it depends on the nature of the vulnerability.

If the weakness is clearly apparent once attention is brought to it, there's no need to actually exploit it to demonstrate that it exists.  If a more subtle and controversial weakness exists, a demonstration on either DevShares or the main network might be required.

I appreciate Come-from-Beyond's efforts on this, and am also curious about his hardware angle.

[cube]

Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work.

Good idea, will do it this way.

0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?

Is it not easier to defend from an attack when it is known how and when it will be executed?
I would say the first step is to attack DevShares without informing the community when and how it will happen...

One of the elements for a successful attack is 'surprise'.  If we take this element out, I doubt it can have a successful outcome.

[bubble789]

My agenda is slightly different than you may guess. I'm going to probe BitShares a little to figure out what elements of the whole BitShares mechanism could be implemented in hardware. Nxt and Ethereum are in the list too.

you made me curious. care to explain more? please

[fluxer555]

Is it not easier to defend from an attack when it is known how and when it will be executed?
I would say the first step is to attack DevShares without informing the community when and how it will happen...

It is easier to defend because we can strengthen that weakness before the attack takes place. This is a desirable outcome.

[liondani]

Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work.

Good idea, will do it this way.

0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?

Is it not easier to defend from an attack when it is known how and when it will be executed?
I would say the first step is to attack DevShares without informing the community when and how it will happen...

[Ander]

Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work.

Good idea, will do it this way.

0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?

[Ander]

If you prove to be a valuable asset for our security, you may be a viable candidate for becoming a delegate and receiving pay.

I would definitely vote for Come_from_beyond as a delegate.  I wouldn't vote for him to have 10 delegates so he could attack us though, hehe.    (I don't think I could support more than 2 delegates for any individual, and wold allow 2 only as a temporary measure until such time as our share price returns to the 3 cent range).  We need to remain decentralized. 

Of course, if he was elected I would expect something to be produced, such as academic research/whitepapers on whether Bitshares was vulnerable to certain types of attacks, with empirical testing.  That would be quite valuable, imo!

[Ander]

as "Is BitShares vulnerable to attack in situations where BitShares holders will lose money", then having them place bets results in a more similar scenario, and more similar game-theory / socioeconomic climates.

The way I see it, Bitshares holders are in a constant state of betting that Bitshares will not suffer from attacks (as an attack would decrease the value of their holdings).

But if they also make an extra 'bet', they are in essence subsidizing any possible attack.

For example, if I can attack Bitshares for a cost of $X, and you offer my a bet of more than $X if I successfully attack, then you have simply opened yourself up to a vulnerability.  I take your bet, spend $X attacking, then collect and make a profit.


Bitshares best defense against attacks, imo, is that they not only cost money, but the money ends up in the hands of BTS holders and/or traders in the end.  Either through a failed nothing at stake attack, where the attacker loses money due to slippage when buying and selling BTS.  Or due to the scenario in case of a severe attack which Bytemaster has described, in which the community responds by hard forking Bitshares, cutting out the malicious stake, and proceeding on as before, but with a lower effective BTS supply.  In the end, humans play a role in the Bitshares consensus algorithm. 


I would not want BTS holders to make a bet that Bitshares can be attacked, because this might subsidize the attack.

I would like for the attacker to lose money on the attack (whether successful or a failure), and that money go to BTS holders in some way.   

I believe that Come_from_beyond could disrupt Bitshares, given a willingness to lose enough money.  I just don't think he can do it for cheap.

[Come-from-Beyond]

Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work.

Good idea, will do it this way.

0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?

[fluxer555]

Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work. If you go about it this way, then attacking BitShares directly may be a viable option. If you bring up a vulnerability that the community/devs declare is real, then we will fix it.

If you prove to be a valuable asset for our security, you may be a viable candidate for becoming a delegate and receiving pay.

[fluxer555]

I think this should be a competition, with defined rules, and money put up by both sides. The pot is split up proportionately to the donations of the side that wins. This will double as a prediction market indicator of the success of the attack.

But in normal conditions, there is not an extra bet riding on the outcome of whether the attack is successful.  I think this would modify the incentives of the situation and thus possibly change the results.

I think that we should investigate "Is Bitshares vulnerable to attack in normal situaitons" not "Is Bitshares vulnerable to attack in situations where Bitshares holders have agreed to a bet where they will pay money to the attacker if he wins". 

I agree. This would change the results, allowing to closer represent a realistic scenario. By holding BTS, you are implicitly betting on its security model. The security of a token gives its value proposition breadth. As confidence in security drops, a token's value trends toward zero very quickly, disproportionately. Since DevShares are explicitly 'hold at your own risk, hackers encouraged', this has a big effect on its token value. If people hold them knowing they could lose them at any time, they must be okay with this fact. If you are ok with losing something at any time, there is no resistance against hackers. If there is no resistance against hackers, then testing for vulnerabilities could lead to uselss results.

Your qualification of

"Is Bitshares vulnerable to attack in normal situations"

does in fact not fit with DevShares, as DevShares does not harbor a 'normal situation'. By putting money on the table, you're making the situation much closer to that of BitShares. If you interpret your negative qualification

"Is Bitshares vulnerable to attack in situations where Bitshares holders have agreed to a bet where they will pay money to the attacker if he wins"

as "Is BitShares vulnerable to attack in situations where BitShares holders will lose money", then having them place bets results in a more similar scenario, and more similar game-theory / socioeconomic climates.

[Ander]

I doubt that the attack plan is simply to loudly proclaim "I will attack Bitshares" and then hope you can make people panic and sell.  That isn't a real attack, its merely an attempt at market manipulation, and I'm pretty sure that Come_from_beyond is much better than that. 

Even if that was the case, you would simply divide people into NXT supporters cheering for Come_from_beyond's attack, versus Bitshares supporters thinking it wont work, and everyone will just defend their tribe's position. 

Every coin is vulnerable to market manipulation anyway, so such an attack would show nothing.