Author Topic: On 51% Attacks  (Read 9832 times)

0 Members and 1 Guest are viewing this topic.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
PS + variable number of delegates depending on transactions volume...?

Variable number would at least remove the magic number of 100 delegates. Magic numbers is the 1st thing that attracts attention of opponents.



You missed some insight's... 99 or 101 delegates! Like the dalmatians dogs (that's a marketing idea Brian)
Notice the detail... that it is optimal to use odd* number for delegates...








*   
Recent update... the number of delegates must be a ODD number to prevent the potential of a chain split of equal length.     We had discussed making the number of delegates PRIME, but this seems to be an unnecessary considering a it does not prevent a 3-way split from potentially forming two equal length chains. 

At every time interval (30 sec) exactly one block can be produced (or not produced).   If the network splits this means that two chains with opposite holes will be produced until the missing delegates are fired.   Assuming both sides of the fork replace their delegates at an equal rate then the chain that started out with the most delegates will always have the most blocks and thus be the best.   

If you get a chain fork that lasts for a prolonged period of time then which ever chain is most effective at keeping delegates online will ultimately win.   To be effective at this will require that the delegates that were disconnected be replaced rapidly; however, to replace them requires shareholders to switch votes or to vote against them.   This means that the fork is ultimately resolved by how the shareholders are divided by the network split rather than just how the delegates are divided.   

What will likely happen in the event of such a split is that all shareholders will become aware of the split immediately and also know which side of the split they are on.  Many delegates can immediately detect that they are on a minority fork and could choose to let the minority fork die by voluntarily not producing blocks for it.   Only in the event of hostile delegates would the minority delegates & shareholders attempt to 'make a run for it'... 

Conclusion: having an ODD number of delegates makes it easy to identify a minority fork and the shareholders and delegates will act accordingly. 

There is one last 'far-out-there' attack where the network is divided into 3 or more pieces less than 50%... in this case the delegates would have to stay online producing blocks until they could confirm that their 3rd is the largest 3rd.  If they are in the smallest 3rd then they should stop producing blocks to let that third die.

These corner cases are all ultimately resolved by the longest-chain standard and it is inconceivable to think that a consensus would not force once fork or another to win out.

source: https://bitsharestalk.org/index.php?topic=4009.45
« Last Edit: May 25, 2014, 12:53:05 pm by liondani »

Come-from-Beyond

  • Guest
PS + variable number of delegates depending on transactions volume...?

Variable number would at least remove the magic number of 100 delegates. Magic numbers is the 1st thing that attracts attention of opponents.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
Bytemaster what about:

"The truth is NOT to be found  ONLY by VOTING..."

What about a hybrid solution ...like 50% of the delegates to be elected like the original plan propose, and the other 50% to be "elected" depended of their % of stake on bitshares or "whatever" mix brings optimal results... ?


PS + variable number of delegates depending on transactions volume...?
« Last Edit: May 25, 2014, 11:37:16 am by liondani »

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
the possibility both to be wrong is small I guess...

(Devil's advocate mode on)

The truth is not to be found by voting...

(Devil's advocate mode off)

(Angel's advocate mode on)

Devil is lying because they don't want us to find the truth...  :)

(Angel's advocate mode off)
« Last Edit: May 25, 2014, 12:54:36 pm by liondani »

Come-from-Beyond

  • Guest
the possibility both to be wrong is small I guess...

(Devil's advocate mode on)

The truth is not to be found by voting...

(Devil's advocate mode off)

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
the possibility both to be wrong is small I guess...

Sent from my ALCATEL ONE TOUCH 997D using Tapatalk


Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
I think that at the end of the day the primary difference between transparent forging and DPOS is only how the block producers are selected.   In one case you do it based upon balance, we do it by vote.

Aye, I thought so too.

This is a good sign for both of our communities.

+5%
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline bytemaster

I think that at the end of the day the primary difference between transparent forging and DPOS is only how the block producers are selected.   In one case you do it based upon balance, we do it by vote.

Aye, I thought so too.

This is a good sign for both of our communities.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Come-from-Beyond

  • Guest
I think that at the end of the day the primary difference between transparent forging and DPOS is only how the block producers are selected.   In one case you do it based upon balance, we do it by vote.

Aye, I thought so too.

Offline bytemaster

If the attacker has 51% then their hidden chain will be longer than the public chain.

The attacker have to reveal this hidden chain before the legit chain goes 10* blocks ahead of the fork. Otherwise online nodes won't accept his chain. So after 10 confirmations transactions will be set in stone.

---
* - actual number depends on statistics, it's set to 720 now.

So right now it takes 720 confirmations to be 'set in stone'.   It sounds to me like we are both using the same model here. 

I think I can sum up  DPOS as automated POS mining pools with an eye toward rapid confirmation and filtering of good/bad pool operators.

I would love to know which ideas you have found worth borrowing. 

I think that at the end of the day the primary difference between transparent forging and DPOS is only how the block producers are selected.   In one case you do it based upon balance, we do it by vote.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
Thank u. Bitshares looks similar to Nxt, I hope u don't mind if I borrow good ideas. :)

I borrow Stans quote :  ;)
"You and Dan will drive more awareness to each other than you will take away from each other.  It's the same reason competing car dealers and hardware stores tend to cluster on the same street.  Get the traffic to come to your neighborhood and then compete!"

Come-from-Beyond

  • Guest
Thank u. Bitshares looks similar to Nxt, I hope u don't mind if I borrow good ideas. :)

Offline Empirical1

  • Hero Member
  • *****
  • Posts: 884
    • View Profile
Welcome to the forum CfB! Thanks for posting!  I love to see tech discussion with NXT devs

 +5%

welcome!

 +5%

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Welcome to the forum CfB! Thanks for posting!  I love to see tech discussion with NXT devs
+5%
welcome .. its a pleasure

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
Welcome to the forum CfB! Thanks for posting!  I love to see tech discussion with NXT devs

 +5%

welcome!