Author Topic: An attack on DevShares  (Read 22496 times)

0 Members and 1 Guest are viewing this topic.

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
Is there anyone here who can edit the wiki and change that page?

I dont like that it gives an outdated explanation of the peg which we all discussed and showed to be flawed.  People could read that, realize that it doesnt work, and avoid bitshares as a result, even though we have already implemented a much better system months ago.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
I do not believe that is still accurate.  A lot of the wiki is very outdated.

Specifically, I think this part is wrong:
" This happens by behavioural confirmation - all traders in the blockchain expect BitUSD to peg to the dollar, which leads them to trade in ways that reaffirm that expectation. If traders start to see Bitshares rising in value relative to dollars, this will result in lower bids being put in for BitUSD because of the expectation of seeing lower asks from the shorts. "


Back in august/september time frame, this was discussed a lot and it was pretty clear to many that this plan would not work.  Specifically, there was no reason for the peg to hold, the price could simply go to 0.


The solution to this was to implement:

* Feeds.  Delegates provide feeds to the system, telling the blockchain how much BTS each asset is worth.
* Forced covering after 30 days.  In order to prevent the asset price from going to 0, shorts (who created the asset), are forced to cover after 30 days, at the feed price.  This assures that a bitasset holder will get fair value for their bitasset with a 30 day or less wait. 
* Margin calls enforced by the blockchain.  In order to ensure that sufficient collateral always exists in order to pay asset holders, any time a short has insufficient collateral to cover 200% of the value of the assets, they are issued an automatic margin call.  This liquidates the asset and gives the fair value of the asset to the holder (in BTS).


This ensures that bitAsset holders can always receive fair value of the asset if they are willing to wait up to 1 month. 

The only way this fails is an extreme black swan event which causes the price of BTS to fall 66% in hours, and doesnt recover.  (A flash crash with no bounce back). 


In the case where demand for a bitAsset dries up and no one wants it at all anymore, all of the asset will end up being liquidated within 30 days, and the holders will have been given fair value worth of BTS in exchange.  The market cap of the asset (bitUSD or whatever) will then be 0, with 0 of the asset existing, but holders of the asset will not have lost their money, they will have sold them for equivalent value in BTS.

Thank you. Looks like this can't be attacked at the technical level (assuming that channels the delegates get info about USD price from do not belong to BitShares protocol).

The delegates all set up their own price feeds and are supposed to use lots of different sources.  They get their info elsewhere and then broadcast the informaiton to the Bitshares network when they create blocks.  (They don't do it every block, just sometimes.  For many they do it once a day or once an hour.  Some delegates dont provide feeds, but this is a problem that should be worked on.  As Bitshares grows, delegates would be pressured more to provide feeds.  Currently most of them do.



The Median price feed is used.  (It doesnt average, so corrupting 1 delegate and posting a bogus price wont do anything).

I think that if you corrupted 51 delegates that you could launch some sort of attack on this system, but I dont think thats surprising.  51% lets you attack every coin.  And it would be really obvious to everyone what was happening.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Come-from-Beyond

  • Full Member
  • ***
  • Posts: 113
    • View Profile
I do not believe that is still accurate.  A lot of the wiki is very outdated.

Specifically, I think this part is wrong:
" This happens by behavioural confirmation - all traders in the blockchain expect BitUSD to peg to the dollar, which leads them to trade in ways that reaffirm that expectation. If traders start to see Bitshares rising in value relative to dollars, this will result in lower bids being put in for BitUSD because of the expectation of seeing lower asks from the shorts. "


Back in august/september time frame, this was discussed a lot and it was pretty clear to many that this plan would not work.  Specifically, there was no reason for the peg to hold, the price could simply go to 0.


The solution to this was to implement:

* Feeds.  Delegates provide feeds to the system, telling the blockchain how much BTS each asset is worth.
* Forced covering after 30 days.  In order to prevent the asset price from going to 0, shorts (who created the asset), are forced to cover after 30 days, at the feed price.  This assures that a bitasset holder will get fair value for their bitasset with a 30 day or less wait. 
* Margin calls enforced by the blockchain.  In order to ensure that sufficient collateral always exists in order to pay asset holders, any time a short has insufficient collateral to cover 200% of the value of the assets, they are issued an automatic margin call.  This liquidates the asset and gives the fair value of the asset to the holder (in BTS).


This ensures that bitAsset holders can always receive fair value of the asset if they are willing to wait up to 1 month. 

The only way this fails is an extreme black swan event which causes the price of BTS to fall 66% in hours, and doesnt recover.  (A flash crash with no bounce back). 


In the case where demand for a bitAsset dries up and no one wants it at all anymore, all of the asset will end up being liquidated within 30 days, and the holders will have been given fair value worth of BTS in exchange.  The market cap of the aset (bitUSD or whatever) will then be 0, with 0 of the asset existing, but holders of the asset will nto have lost their money, they will have sold them for equivalent value in BTS.

Thank you. Looks like this can't be attacked at the technical level (assuming that channels the delegates get info about USD price from do not belong to BitShares protocol).

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
I think the sybil attacks are actually the most promising and we should focus on that.
Solutions do exist as Bytemaster posted but I worry that too few delegates are using them.  If we hit the delegates in this way, the ones that are lax will need to step it up!


New idea: Sybil attack all the paid delegates in particular.  The ones that have lax security will miss blocks and not get paid.  Serves them right! :)

Forced compliance...
A little extreme isn't it?

More like Forced "do not be vulnerable to attacks that could disrupt the blockchain".  It is critical that our delegates are secure.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
Does http://wiki.bitshares.org/index.php/BitShares/Market_Peg contain actual info?

I do not believe that is still accurate.  A lot of the wiki is very outdated.

Specifically, I think this part is wrong:
" This happens by behavioural confirmation - all traders in the blockchain expect BitUSD to peg to the dollar, which leads them to trade in ways that reaffirm that expectation. If traders start to see Bitshares rising in value relative to dollars, this will result in lower bids being put in for BitUSD because of the expectation of seeing lower asks from the shorts. "


Back in august/september time frame, this was discussed a lot and it was pretty clear to many that this plan would not work.  Specifically, there was no reason for the peg to hold, the price could simply go to 0.


The solution to this was to implement:

* Feeds.  Delegates provide feeds to the system, telling the blockchain how much BTS each asset is worth.
* Forced covering after 30 days.  In order to prevent the asset price from going to 0, shorts (who created the asset), are forced to cover after 30 days, at the feed price.  This assures that a bitasset holder will get fair value for their bitasset with a 30 day or less wait. 
* Margin calls enforced by the blockchain.  In order to ensure that sufficient collateral always exists in order to pay asset holders, any time a short has insufficient collateral to cover 200% of the value of the assets, they are issued an automatic margin call.  This liquidates the asset and gives the fair value of the asset to the holder (in BTS).


This ensures that bitAsset holders can always receive fair value of the asset if they are willing to wait up to 1 month. 

The only way this fails is an extreme black swan event which causes the price of BTS to fall 66% in hours, and doesnt recover.  (A flash crash with no bounce back). 


In the case where demand for a bitAsset dries up and no one wants it at all anymore, all of the asset will end up being liquidated within 30 days, and the holders will have been given fair value worth of BTS in exchange.  The market cap of the aset (bitUSD or whatever) will then be 0, with 0 of the asset existing, but holders of the asset will nto have lost their money, they will have sold them for equivalent value in BTS.

https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads


Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
I think the sybil attacks are actually the most promising and we should focus on that.
Solutions do exist as Bytemaster posted but I worry that too few delegates are using them.  If we hit the delegates in this way, the ones that are lax will need to step it up!


New idea: Sybil attack all the paid delegates in particular.  The ones that have lax security will miss blocks and not get paid.  Serves them right! :)

Forced compliance...
A little extreme isn't it?

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
I think the sybil attacks are actually the most promising and we should focus on that.
Solutions do exist as Bytemaster posted but I worry that too few delegates are using them.  If we hit the delegates in this way, the ones that are lax will need to step it up!


New idea: Sybil attack all the paid delegates in particular.  The ones that have lax security will miss blocks and not get paid.  Serves them right! :)
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline blahblah7up

  • Full Member
  • ***
  • Posts: 192
    • View Profile
Hopefully the fact that our competitors are still pursuing POW (and proprietary, at that) gives us time to clean up our ui and get marketing caught up.

We only have one competitor, ethereum.

And they're not dicking around.

This is most certainly an ethereum thing.  They've long had plans to start out with a proprietary hardware POW solution, then possibly shift into POS later.

Offline Come-from-Beyond

  • Full Member
  • ***
  • Posts: 113
    • View Profile
Isn't that the whole point of consensus mechanics to solve the Two-Generals problem?

Two Generals problem is unsolvable IIRC.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
A double-spending attack has come to my mind but it requires a sybil attack to conduct an eclipse attack... Heh, without ability to control the communications it's quite hard to do something hostile.
Isn't that the whole point of consensus mechanics to solve the Two-Generals problem?

Offline Come-from-Beyond

  • Full Member
  • ***
  • Posts: 113
    • View Profile
A double-spending attack has come to my mind but it requires a sybil attack to conduct an eclipse attack... Heh, without ability to control the communications it's quite hard to do something hostile.

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
They are not interesting anyway...
Anyone could create such hardware and require users to purchase it in order to use the system.
It is useless for bitshares as its goals are WIDE adoption and custom hardware prevents that.

Right. Let's assume that Sybil attack is mitigated and look for other weak spots.

Hold on. Can that be mitigated by making changes to the software codes?  I think something like DNS with reverse lookup and certificates can help.

Hold on! Where is the privacy ? Dont touch that.

That is something we need to work out as part of the solution.
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline Come-from-Beyond

  • Full Member
  • ***
  • Posts: 113
    • View Profile
Hold on. Can that be mitigated by making changes to the software codes?

Yes.

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
They are not interesting anyway...
Anyone could create such hardware and require users to purchase it in order to use the system.
It is useless for bitshares as its goals are WIDE adoption and custom hardware prevents that.

Right. Let's assume that Sybil attack is mitigated and look for other weak spots.

Hold on. Can that be mitigated by making changes to the software codes?  I think something like DNS with reverse lookup and certificates can help.

Hold on! Where is the privacy ? Dont touch that.