Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: How Bitshares paid delegates help prevent Sybil attacks  (Read 429 times)

0 Members and 1 Guest are viewing this topic.

Offline Ander

  • Hero Member
  • *****
  • Posts: 3499
    • View Profile
  • BTS: Ander
How Bitshares paid delegates help prevent Sybil attacks
« on: January 30, 2015, 09:32:21 PM »

I have realized something huge.  Paid delegates is probably the most important and most beneficial feature of Bitshares.  More important even than Bitassets! 
I’m pretty sure that Rune realized this several months ago, and I thought I understood why they were a big deal when he explained it, but actually I was still missing some of the pieces.  And now that I’ve put it all together I just had a mindgasm. :)

You see, paid delegates do more than just support the development and promotion of Bitshares. They do that too, which is super important, but they ALSO make Bitshares with DPoS paid delegates the most secure crypto coin that has ever been devised: *the most expensive crypto to attack*.  More expensive than Bitcoin even, once at the same scale.

First let’s imagine that you want to attack Bitcoin, what do you need to do?   You need to acquire 51% of hashing power.  So you go out and spend a ton of money on miners, then you make your attack.  You spend a ton of money and you hurt bitcoin.  (Maybe you are a hostile government with a ton to gain if you can keep bitcoin down for a long time and continue to print your own currency).

After the attack other people manage to get some more hashing power, and they get you back under 51% again, and bitcoin rebounds.  But guess what, you still have all of your hardware that you used to launch your first attack!  You buy some more, get 51%, and attack again. 

Once you are so heavily invested into crushing Bitcoin, you can keep on hitting it and you just pay electricity costs.


Now imagine you want to attack Bitshares instead.  Ultimately, what you need to do is similar, you need to gain control of X% of all delegates (this may not still be 51%, but there is some number that you will need). 

There are several possible avenues open to you.  First, you can acquire enough stake in BTS to vote in all your own delegates, and then attack.  This is by far the most expensive kind of attack, and it would give all the money you spend to BTS holders.   As Bytemaster says, if you do this, the community can recover by forking the code, cutting out the hostile stake, and continuing on as before, while also accepting your generous donation.

The second avenue is to do the above, but try to sell your BTS after electing delegates but before attacking, the so called Nothing at Stake attack.   Bytemaster addressed this here:
http://bytemaster.bitshares.org/article/2015/01/08/Nothing-at-Stake-Nothing-to-Fear/

Every set of 101 blocks (or roughly 17 minutes of time) is considered a snapshot, and after that these blocks cannot be changed.  Someone attempting to create a false chain deeper than that would have their block rejected automatically for not matching the snapshot.  Thus, one would have 17 minutes to sell their stake and launch the attack.

In 17 minutes you could dump a ton of BTS, but you would only get a fraction of your value back.  First you would empty out all the orderbooks.  In general there are about 25 million or less BTS on the ask on btc38 and bter, and a lot of that isn’t anywhere near the current price.  So that’s about 1% of the total supply of BTS, and then you are selling for essentially zero.  Then the traders who are actively online at the time will put in orders at cheap prices, trying to take advantage of the crash, and you’ll be able to sell into those as well.  You’ll get some more out of this, but given that you have less than 17 minutes, not very much. 
If you needed 10% of the total BTS stake to elect all your delegates, you’ll probably lose 80-90% of the money you put in in this dump.  If you need more stake than that, you would lose even more.


Finally, the most realistic and least expensive avenue of attack is the Sybil attack.  You would perform some combination of buying stake/electing your delegates, or fooling BTS holders into electing your delegates, not knowing that they are all controlled by you and ready to collude to attack Bitshares.   Then you would sell any stake you acquired over a period of weeks in order to not lose value, and then final launch your attack.

It is in this form of attack that paid delegates rises to our defense.    Prior to paid delegates, we have had at least one (minor) instance of a Sybil attack:  User ‘sfinder’ managed to get 5 delegates elected, and he became hostile to Bitshares.   Fortunately he couldnt really do much with only 5 delegates.

Now, in the era of paid delegates, we have a lot of delegates which are being *heavily scrutinized*.  Every paid delegate is under the watchful eye of shareholders, demanding that the see evidence that the delegate has the best interests of Bitshares at heart.
We have already voted out one paid delegate, blackwavelabs, who the community noticed was not providing updates, and we were not sure if he was creating any value.

Anyone wishing to launch a Sybil attack by getting many delegates elected in the current environment faces a very, very hard task.  Paid delegates create a significant amount of competition for delegate slots that was not present before, and as Bitshares scales, this demand scales with it.  A Bitshares which increases to an order of magnitude greater price will have many more than 101 individuals and organizations trying to become delegates.  It will be very hard for a malicious entity to execute a Sybil attack and get even a few paid delegates into office, much less 51 of them!

And once they get some delegates in office, it is hard for them to KEEP them in office, if they are a malicious entity.  Because BTS holders demand REAL Proof of Work!  We demand that our miners demonstrate that they are doing Work on behalf of Bitshares.  Not just cryptographic mathematical calculations like in Bitcoin’s Proof of Work, but actual HUMAN level work, that we can see.  Nonperforming delegates will be voted out fairly quickly in a competition intensive environment!

As a result, performing a Sybil attack would be immensely hard.  Anyone wishing to get 51 delegates elected would need to be doing 51 delegates worth of Proof of Work in promoting and building Bitshares, to remain in office until they can execute their plan. 

Finally, obtaining these delegate slots requires a good reputation.  In a future environment where 101 other organizations have good reputations and are working to build Bitshares, if you want to get your 51 delegates elected you will need to develop 51 delegates with even BETTER reputations than some of them, or manage to fool us all 51 times in a short period of time.  Fool me once, shame on you, fool me 51 times and we deserve to have Bitshares be attacked.

With Bitcoin, you executed your attack, and then you still have your hardware to provide hashing power to help you do it again, you only lose electricity costs.  But with Bitshares paid delegates, after you issue your attack, you destroy the reputation of every single delegate you use in your attack, that you worked so hard to build up.  Bitshares recovers after a time and then you are back where you began, voted out of all your positions, all your identities and reputations tarnished.   To attack again you would need to start over.  Bitshares is resilient.  It survives.


To remain a paid delegate, the individual or organization running the delegate must show TRUE Proof of Work.  Proof at a human level.  Proof that they are working for the benefit of Bitshares, as validated by human shareholders.


Bitcoin’s Proof of Work does provide security, but it is expensive.
Bitshares’ original DPoS with delegates that were hardly paid anything at all and not well scrutinized was cheap, but had vulnerabilities to Sybil attacks, if one entity could gain control of enough delegates while we weren’t paying attention.

Bitshares new DPoS with paid delegates adds resilience to Sybil attacks by giving shareholders a very strong incentive to thoroughly and continually investigate all delegates, and rally together to cut out any perceived malicious or parasitical agent.  While it is once again expensive like Proof of Work, the money contributes directly to paying for the development and promotion of the Bitshares ecosystem, such that it becomes a viral entity with the 101 most qualified business partners invested in its success! 

Paid delegates is the true Proof of Work.  Prove to us constantly that you are providing Work for Bitshares or be replaced in a highly competitive, reputation based environment.  Maintaining a good reputation is hard and requires effort.  Performing a Sybil attack and maintaining the reputation of enough fake identities to attack Bitshares is much, much harder!


When we look at Bitshares this way, it fulfills the ultimate promise of crypto: an ultra secure store of value.  While this requires a cost, just like in Proof of Work, our security algorithm provides a massive advantage: 101 entities and business partners devotes to the viral promotion of Bitshares.  These entities constantly compete with each other and others hoping to get into the club to provide the most value in a darwinian process where those who fail to be efficient enough in creating value are replaced.

The fact that Bitshares also has and will tons of other amazing features like Exchange, Vote, and DNS, and will make money through these uses, is icing on the cake.

Some more final notes:
•   At various points I suggest that you could attack Bitshares with 51 delegates.  I don’t actually know if this number is the right number, I have seen estimates both higher and lower.  Replace 51 with X delegates instead.
•   It is important that we are vigilant in inspecting standby delegates as well.  If a malicious entity got its delegates #102-152 ready in line, it could wait until some event got shareholders angry at current delegates and then get elected when we removed approval from them, then execute the attack.  Standby delegates matter as well and must be investigated.
•   Any time in which we see large and rapid delegate turnover we should be worried and extra vigilant!  It is possible at such times that all the new delegates are being voted in by a malicious entity who is going to dump their shares and then attack.  Be extra vigilant in times of high delegate turnover!


This post demonstrates why it is critical that we do NOT separate workers and block producer delegates!!  A low pay block producer delegate is a delegate that goes unscrutinized!  A high pay delegate is one that must always demonstrate proof of work.  It is precisely because we are paying so much attention to paiddelegates and their reputations, that Bitshares becomes secure against Sybil attacks.
« Last Edit: January 30, 2015, 09:39:21 PM by Ander »
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Ander

  • Hero Member
  • *****
  • Posts: 3499
    • View Profile
  • BTS: Ander
Re: How Bitshares paid delegates help prevent Sybil attacks
« Reply #1 on: January 30, 2015, 10:50:02 PM »
(Added some more paragraphs and notes)
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: How Bitshares paid delegates help prevent Sybil attacks
« Reply #2 on: January 30, 2015, 11:38:45 PM »
The second avenue is to do the above, but try to sell your BTS after electing delegates but before attacking, the so called Nothing at Stake attack.   

That isn't really the Nothing-at-Stake attack that I think most people understand. You don't need to buy BTS when it has value. You buy old private keys for very cheap that controlled BTS stake at some point in the blockchain history but no longer do. Then you can create a fork from that point where you vote in your own delegates and simulate the real blockchain but on the fake copy. If you can get someone on the fake chain you can then pull of a double-spend. But doing it the way you said is workable too, however, you have no requirement to sell in 17 minutes, as I will explain shortly.

What you did get correct is that timing is important here and the fake blocks should ideally be rejected by syncing clients. But let me clarify on what you claim later...

Every set of 101 blocks (or roughly 17 minutes of time) is considered a snapshot, and after that these blocks cannot be changed.  Someone attempting to create a false chain deeper than that would have their block rejected automatically for not matching the snapshot.  Thus, one would have 17 minutes to sell their stake and launch the attack.

From a NaS perspective the checkpoints every round are irrelevant. What matters is how old compared to the present the fork point needs to be before the client refuses to automatically accept a chain reorganization. I believe (devs please correct me if I am wrong) that it is 16 rounds (so a little over 4 hours).

I don't fully understand the fork resolution and consensus mechanics of DPOS, so what I say may very likely be inaccurate. I appreciate any corrections. But from what I understand, it means that any client that has been offline for more than 4 hours could get stuck at a fork if it receives two or more competing blockchains that have fork points more than 4 hours older than the present. In such a scenario manual intervention is required to resolve the fork (basically a trusted checkpoint is needed to choose the "correct" chain).

Obviously if anyone could create a fork at minimal cost (say the cost of producing a single Bitcoin block) this consensus technology would be unsuitable. People could do DOS attacks forcing everyone to resort to manual social consensus all the time. DPOS solves this by restricting block producers to the elected 101 active delegates and providing an economic incentive for them to not double sign (or else they will get fired). As long as those incentives remain in place, we can be confident that there will be a low probability of a set of delegates that simultaneously existed in some point in the blockchain history deciding to produce a competing forked chain that would cause a client syncing the blockchain (after being offline for more than 4 hours) to get stuck and require manual intervention.

However, since delegates will get replaced/fired, eventually you will get a set of delegates that simultaneously existed at some point in the blockchain history that are no longer active delegates in the present. Assuming they don't care about their reputation going forward or just generally being good moral human beings, they would no longer have a disincentive from colluding to create a fake blockchain history reaching the present that can compete with the real blockchain. I think that if the fork point is more than 16*101 blocks older than the head block of a client that is trying to sync, the client can ignore the fake chain and continue syncing with the real chain. However if the fork point is newer than that threshold point, the client will ideally see both the fake chain and the real chain (assuming a non-compromised internet connection) and get stuck. The good news is that since delegate turn over is slow (and attempting to buy old private keys is even slower), the fork point that those evil colluding former delegates can branch off from has to be fairly old and so the only people vulnerable to this are clients syncing after being offline for a long time (or syncing from genesis). If the fork point is really old, the client will likely have a trusted checkpoint built in to protect the user. If the fork point is only moderately old (say a few months old), then the user will need to manually provide the checkpoint to the client which they need to obtain from the social network of trust. In that scenario, typical users can likely rely on the checkpoint provided by the devs and other major institutions in this space assuming each of them are all in agreement on the checkpoint provided (in other words, the likelihood of them colluding to attack the user is low especially when their reputation is on the line).

And again, I am not very sure about the mechanics actually implemented in the BitShares code, so I would appreciate if the devs could confirm if my understanding is correct or educate me if it is not.


This post demonstrates why it is critical that we do NOT separate workers and block producer delegates!!  A low pay block producer delegate is a delegate that goes unscrutinized!  A high pay delegate is one that must always demonstrate proof of work.  It is precisely because we are paying so much attention to paiddelegates and their reputations, that Bitshares becomes secure against Sybil attacks.

I think the stakeholders should carefully scrutinize the delegates regardless of their payment. This is not a good argument in my opinion why workers shouldn't be separated from block producers.
« Last Edit: January 30, 2015, 11:41:12 PM by arhag »

Offline Ander

  • Hero Member
  • *****
  • Posts: 3499
    • View Profile
  • BTS: Ander
Re: How Bitshares paid delegates help prevent Sybil attacks
« Reply #3 on: January 31, 2015, 12:12:49 AM »
Thanks for the clarifications.

I didnt want to go into huge detail about Nothing at Stake because Bytemaster blogged about it, and also the main point was about why delegates being paid helps prevent Sybil attacks.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline fuzzy

Re: How Bitshares paid delegates help prevent Sybil attacks
« Reply #4 on: January 31, 2015, 02:03:02 AM »
Now imagine you want to attack Bitshares instead.  Ultimately, what you need to do is similar, you need to gain control of X% of all delegates (this may not still be 51%, but there is some number that you will need). 

There are several possible avenues open to you.  First, you can acquire enough stake in BTS to vote in all your own delegates, and then attack.  This is by far the most expensive kind of attack, and it would give all the money you spend to BTS holders.   As Bytemaster says, if you do this, the community can recover by forking the code, cutting out the hostile stake, and continuing on as before, while also accepting your generous donation.


Not only that but with delegate hangouts the community will have a very close relationship with the delegates they know actually care about the network.  Even if those people do not get voted in initially, they will be able to continue "campaigning" and we will have people ready to take up the reigns as soon as any significant portion of the delegates are removed due to a hard fork.  The power of DPoS is not only in its tech, but in the community that backs it...in essence all of you. :)
BROWNIE==DKP; BitShares is our Community! 
ShareBits Welcome to  the Sharing Economy w/ BeyondBitcoin.org Partners--ShareBits.io & OpenLedger.info
TIP FORMAT: #sharebits "ForumHandleInQuotes" Quanity Token_Name

Offline theoretical

Re: How Bitshares paid delegates help prevent Sybil attacks
« Reply #5 on: January 31, 2015, 06:18:15 AM »
Now, in the era of paid delegates, we have a lot of delegates which are being *heavily scrutinized*.  Every paid delegate is under the watchful eye of shareholders, demanding that the see evidence that the delegate has the best interests of Bitshares at heart.
We have already voted out one paid delegate, blackwavelabs, who the community noticed was not providing updates, and we were not sure if he was creating any value.

Interesting point.  If a delegate is merely a block signing provider, their service is an interchangeable commodity which doesn't individualize them very much.  If each delegate is providing unique business services, their service is no longer a commodity for which equivalent services are readily obtainable.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

 

Google+