Author Topic: Delegated Proof of Stake (DPOS) White Paper  (Read 76252 times)

0 Members and 1 Guest are viewing this topic.

Offline bytemaster

let's assume, when bitshares release, Chinese network cut off from American,
2 seperate bts chain is running well in each network.
one day, the network is connect again.
which chain will win?

For btc, it's simple, the longer chian win.
From test these days, many chains run seperate without merge.

The same rule applies here as well (longest chain wins).  The trouble we have with many forks running in parallel is at the network layer.  We have code that hasn't been merged in that should keep them all in sync.   I was hoping that network forks would be rare and that the test would be functional without any forks. 

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 alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
let's assume, when bitshares release, Chinese network cut off from American,
2 seperate bts chain is running well in each network.
one day, the network is connect again.
which chain will win?

For btc, it's simple, the longer chian win.
From test these days, many chains run seperate without merge.

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
Also all nodes and all traffic is encrypted so you would have to be directly connected to a node to find out if they are the one to produce the block and they might not even be the one that produced it they could just be the first one to have received it.


Sent from my iPhone using Tapatalk
Hi BM
thank your reply , you konw i am a newbi
i just want konw if 51 delegates is out of network ,can chain runing well?
BR
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline bytemaster

Also all nodes and all traffic is encrypted so you would have to be directly connected to a node to find out if they are the one to produce the block and they might not even be the one that produced it they could just be the first one to have received it.


Sent from my iPhone using Tapatalk
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 xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Your attack requires cooperation of shareholders to give up their original keys....  it is not worth considering if there is a large number of initial shareholders.
HI BM
I saw many discuss about the 51% attack, these attacks are done by stakeshould,  what if  many delegates are attacked by DDOS?
BR
Delegates just sign blocks .. they do not need to reveal their IP address ..
Also one can set up backup-delegate machines to take over. I dont see any problems here.

BTW. you can even run a delegate through the onion network tor
there are many methods  and not diffclut to find the IP of delegate
yes, there are backup-delegates , and how many delegates can been replaced one round?
No need for replacing .. just unlocking the wallet and let the other machine start signing the blocks .. easy handover

finding an IP address is quit difficult if you are in a P2P address and not directly connected to the delegate. The delegate might be hidden behind a usual (relay-)node which can be DDOS, but not the delegate then.

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
Your attack requires cooperation of shareholders to give up their original keys....  it is not worth considering if there is a large number of initial shareholders.
HI BM
I saw many discuss about the 51% attack, these attacks are done by stakeshould,  what if  many delegates are attacked by DDOS?
BR
Delegates just sign blocks .. they do not need to reveal their IP address ..
Also one can set up backup-delegate machines to take over. I dont see any problems here.

BTW. you can even run a delegate through the onion network tor
there are many methods  and not diffclut to find the IP of delegate
yes, there are backup-delegates , and how many delegates can been replaced one round?
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Your attack requires cooperation of shareholders to give up their original keys....  it is not worth considering if there is a large number of initial shareholders.
HI BM
I saw many discuss about the 51% attack, these attacks are done by stakeshould,  what if  many delegates are attacked by DDOS?
BR
Delegates just sign blocks .. they do not need to reveal their IP address ..
Also one can set up backup-delegate machines to take over. I dont see any problems here.

BTW. you can even run a delegate through the onion network tor

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
Your attack requires cooperation of shareholders to give up their original keys....  it is not worth considering if there is a large number of initial shareholders.
HI BM
I saw many discuss about the 51% attack, these attacks are done by stakeshould,  what if  many delegates are attacked by DDOS?
BR
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline bytemaster

Your attack requires cooperation of shareholders to give up their original keys....  it is not worth considering if there is a large number of initial shareholders.
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 toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
I collect old accounts totaling >50%

You are right, I assumed this wasn't possible.

Two points:
* Remember it has to be >50% stake within a particular 1 hour window. I think it'd be *more* difficult to do this than getting 50% of the current stake. "Buying all old keys with nonzero balance between 12 and 1am on DD-MM-YYYY. Don't tell any delegates or else they'll add a checkpoint!"

* Even so, this would only affect nodes that have never been online and are trying to sync for the first time, since we do not look back farther than a few rounds of full participation when considering forks.

How does a checkpointing change anything?

In this scheme, "a checkpoint" seems to be exactly the same as "a new block was discovered/signed", which would make it irrelevant...the attack nodes can have their own 'checkpoints'.

Checkpoint built into the client, like BTC or PPC. Delegates issue an alert to update to preempt any serious attack.
Don't want to go down that path too far because it's essentially the same as "what happens if BTC gets 51% attacked", it's not part of the security model which I think is sound on its own.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline MolonLabe

  • Full Member
  • ***
  • Posts: 58
    • View Profile
I collect old accounts totaling >50%

You are right, I assumed this wasn't possible.

Two points:
* Remember it has to be >50% stake within a particular 1 hour window. I think it'd be *more* difficult to do this than getting 50% of the current stake. "Buying all old keys with nonzero balance between 12 and 1am on DD-MM-YYYY. Don't tell any delegates or else they'll add a checkpoint!"

* Even so, this would only affect nodes that have never been online and are trying to sync for the first time, since we do not look back farther than a few rounds of full participation when considering forks.

How does a checkpointing change anything?

In this scheme, "a checkpoint" seems to be exactly the same as "a new block was discovered/signed", which would make it irrelevant...the attack nodes can have their own 'checkpoints'.

Offline bytemaster

Could it be dynamic? or have shareholders also vote for the total number of delegates?

+5% for dynamic number of delegates

Sent from my ALCATEL ONE TOUCH 997D using Tapatalk

I think we can make it dynamic with a 'minimum number of delegates'...

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
Could it be dynamic? or have shareholders also vote for the total number of delegates?

+5% for dynamic number of delegates

Sent from my ALCATEL ONE TOUCH 997D using Tapatalk


Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Another thing to consider is that if an attacker acquires a big stake and starts repeatedly voting in bad delegates, you can hard-fork and exclude their stake from the new network. Unlike other POS systems it is very easy to identify which stake belongs to the bad actor.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Our protection against this is that the registration fee is equal to about two weeks' worth of block production, so this attack will drain their stake. Each delegate's stats are visible in the client and eventually you will have the option to let your client auto-downvote misbehaving delegates.

Ok, maybe this is enough but it seems that people could still cycle through their old delegates that got voted down without paying new registration fees right?  People can't waste their down votes on old stale delegates that got voted out a long time ago.

This particular attack would only matter if the attacker had 51% of the delegates.   They get in power and the only thing they can do is 'not produce a block' or 'not include a transaction' and thus I do not see what they could gain.

I guess I'm thinking of it as much in political terms as in compromising the network.  There are other reasons to want to be a delegate other than to attack the network (profit) and other reasons to down-vote delegates (such as delegates that are returning fees only to people voting for them).