BitShares Forum

Main => General Discussion => Topic started by: Come-from-Beyond on February 01, 2015, 03:50:28 pm

Title: Consensus on the list of delegates
Post by: Come-from-Beyond on February 01, 2015, 03:50:28 pm
I'm trying to find out how BitShares work but some things are not clear to me. Unfortunatelly, these things are fundamental and I can't move ahead without understanding them. Could anyone answer two simple questions, please?

Do the shareholders have the same list of the delegates? If they do then how the consensus is achieved?
Title: Re: Consensus on the list of delegates
Post by: sumantso on February 01, 2015, 04:05:14 pm
I will let the smarter guys give you a proper answer rather than confuse you more with my attempts.

I wanted to know, what did you mean by 'move ahead'?
Title: Re: Consensus on the list of delegates
Post by: cass on February 01, 2015, 04:07:46 pm
Welcome Come-from-Beyond!

Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 01, 2015, 04:18:36 pm
I wanted to know, what did you mean by 'move ahead'?

To dig deeper into BitShares internals.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 01, 2015, 04:19:08 pm
Welcome Come-from-Beyond!

Thank you.
Title: Re: Consensus on the list of delegates
Post by: speedy on February 01, 2015, 04:20:46 pm
Do the shareholders have the same list of the delegates? If they do then how the consensus is achieved?

Yes all shareholders see the same list directly from the blockchain, which you can also see here: http://bitsharesblocks.com/delegates

Votes are added up and the top 101 get in. For example from the client I can see that the top delegate is yunbi with 18.64% of all BTS voting to approve them, i.e. 465,995,430 BTS.
Title: Re: Consensus on the list of delegates
Post by: edilliam on February 01, 2015, 04:21:29 pm
I'm trying to find out how BitShares work but some things are not clear to me. Unfortunatelly, these things are fundamental and I can't move ahead without understanding them. Could anyone answer two simple questions, please?

Do the shareholders have the same list of the delegates? If they do then how the consensus is achieved?

There are both unelected and elected delegates. BTS represents stake ("shares") in the BitShares DAC. Anybody that owns BTS can vote for their choice of delegates with their BTS. The more BTS a user has, the more votes they effectively have too. The 101 delegates that receive the most votes from this process become the elected delegates for the BitShares DAC. Users have to pay a fee to become a delegate, so not all users are necessarily delegates. Does this make sense?
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 01, 2015, 06:59:02 pm
What ensures that the shareholders agree on the list of delegates? If a delegate can be kicked off for misbehavior then the list can change instantly which is hard to achieve in a distributed system.
Title: Re: Consensus on the list of delegates
Post by: btswildpig on February 01, 2015, 07:05:39 pm
What ensures that the shareholders agree on the list of delegates? If a delegate can be kicked off for misbehavior then the list can change instantly which is hard to achieve in a distributed system.

active delegates are those who have the most approval votes before the 101 ranking .
For instance , if a guy at 101 misbehaved , some shareholders withdraw some vote , then he falls to 102 , and the one on 102 become 101 .

It's an approval voting system . So you don't need all the shareholders to kick someone out , just withdraw enough vote to let him fall out of 101 . Or add enough vote on 102 , then it can push the one on 101 out either .
Title: Re: Consensus on the list of delegates
Post by: robrigo on February 01, 2015, 07:15:25 pm
When an account name is registered on the blockchain, if a pay rate between 0-100 is specified then that account becomes registered as a delegate. Each delegate has a variable amount of stake voting for them. If a delegate has enough votes where the total stake voting for them is in the top 101 vote balances out of the set of registered delegates, then that delegate node will be included in each round as an active block signer. When these vote balances change, i.e. a delegate has votes revoked and are  "fired" from the top 101, each client will sync that information and reflect the new set of active 101 delegates accordingly.

So the list of delegates is a list that doesn't get any smaller, only larger, as new delegate accounts are registered. The set of active delegates is dynamic based on the amount of stake each delegate has voting for them. Anyone can change their vote and their changes will be reflected when that trx is included in the next block. To change your vote, send a transfer (to yourself for example).  There are multiple voting schemes you can specify when you transfer your stake: vote_none, vote_all, vote_random, and vote_recommended. The GUI client has a vote button to make this process simpler.

The default is "vote_recommended", which I believe means that your votes are cast based on the voting slates published by the delegates that you approve of.
Title: Re: Consensus on the list of delegates
Post by: jshow5555 on February 01, 2015, 07:36:06 pm
He is asking something different...

The answer is:
-The 101 deletes with the most votes @ block n, are  put in randomly order to produce - blocks from n+a to n+a+100;

As for the value of 'a' and questions regarding the consensus who has the most votes in block 'n', you should wait for some dev to answer that, or alternatively check the code yourself.
Title: Re: Consensus on the list of delegates
Post by: sschechter on February 01, 2015, 07:46:06 pm
Delegates sign blocks, just like bitcoin miners.  However, the majority of bitcoin miners don't actually sign blocks, their pool operators do.   To fully grasp the reasons why DPOS and the delegate system were designed the way it was, the best way to understand is to hear about it from the man who designed it (hint: you can't hide from economics) :

http://bytemaster.bitshares.org/article/2015/01/12/Decentralization-Scalability-and-Fault-Tolerance-of-Bitcoin/
http://bytemaster.bitshares.org/bitshares/2015/01/04/Delegated-Proof-of-Stake-vs-Proof-of-Work/
Title: Re: Consensus on the list of delegates
Post by: testz on February 01, 2015, 07:57:07 pm
Welcome Come-from-Beyond!
Nice to see you here  :)
Title: Re: Consensus on the list of delegates
Post by: Empirical1.2 on February 01, 2015, 08:01:01 pm
Welcome Come-from-Beyond!
Nice to see you here  :)

 +5%
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 01, 2015, 08:06:39 pm
I'm trying to find out how BitShares work but some things are not clear to me. Unfortunatelly, these things are fundamental and I can't move ahead without understanding them. Could anyone answer two simple questions, please?

Do the shareholders have the same list of the delegates? If they do then how the consensus is achieved?

Welcome Come-from-Beyond.

A 'delegate' is just a username registered on the blockchain with a public flag set announcing that it's a delegate and a requested pay percentage.  Everyone who has the blockchain has the same list of registered accounts, including the delegates, but they don't all vote to approve the same subset of those delegates.  Each stakeholder votes with his/her stake to approve certain delegates, and the active delegates are the 101 with the most stake approving them.  Only the active delegates produce blocks, but which delegates are active can change as rapidly as people can change their votes.  The votes are on the blockchain, so everyone knows the consensus of which delegates are active, even if they aren't voting for those delegates.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 01, 2015, 08:09:24 pm
Votes are included into the blockchain by delegates. I'm curious what may happen if votes are about to fire 51 delegates...
Title: Re: Consensus on the list of delegates
Post by: BunkerChainLabs-DataSecurityNode on February 01, 2015, 08:42:46 pm
Votes are included into the blockchain by delegates. I'm curious what may happen if votes are about to fire 51 delegates...

Then then ones directly below them would move up. There is always 101, they would just change who are in that space.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 01, 2015, 08:54:58 pm
Votes are included into the blockchain by delegates. I'm curious what may happen if votes are about to fire 51 delegates...

If 51 delegates colluded to block any vote transactions that would take away any of their positions, and ignored the blocks created by the minority honest delegates, it would be completely apparent what they were doing.  They could fork the network, but they would have no special ability to gain more than 51 positions in their branch, so its speed and delegate participation rate would be cut in half.  In the honest branch the colluding delegates would be quickly replaced and normal operation would continue.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 01, 2015, 10:15:15 pm
it would be completely apparent what they were doing.

This what I'm asking - how is it possible? It may be apparent for 100 shareholders who saw their votes not included into the blockchain but not for the other 900.
Title: Re: Consensus on the list of delegates
Post by: fuzzy on February 01, 2015, 10:40:05 pm
Welcome Come-from-Beyond!

Thank you.

You see guys...this is what is awesome about the BitShares community.  Look how many of you are helping him understand our voting system so he can help develop a similar one for a competing platform. 

I am proud to be a part of this community.
Title: Re: Consensus on the list of delegates
Post by: vikram on February 01, 2015, 10:46:06 pm
What ensures that the shareholders agree on the list of delegates? If a delegate can be kicked off for misbehavior then the list can change instantly which is hard to achieve in a distributed system.

It's a blockchain--state transitions happen at most once every block interval (10 seconds in this case).
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 01, 2015, 11:15:20 pm
it would be completely apparent what they were doing.

This what I'm asking - how is it possible? It may be apparent for 100 shareholders who saw their votes not included into the blockchain but not for the other 900.

The non-colluding delegates would include the vote transactions in blocks, and the colluding delegates would then have to ignore those blocks and create their own fork of the chain, same as a mining pool could fork the bitcoin chain by ignoring everyone else's blocks.

Anyone who initially ended up on the hostile fork would see delegate participation drop because none of the honest blocks were being included and would thus know something was wrong, and further investigation would reveal that the other fork had the hostile delegates voted out.  If the user doesn't investigate and just waits, the fork should resolve because the honest fork will be able to replace the non-participating delegates, while the hostile fork has no such ability.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 01, 2015, 11:40:01 pm
The non-colluding delegates would include the vote transactions in blocks...

Would they still include these transactions if the delegate who is being voted out promised to pay 1 milion dollars if they didn't?

I'm analyzing a situation when delegates bribe other delegates in exchange of keeping their position in top 101. Every rational delegate will accept the money. There can be some delegates who will reject the money but depending on the offered amount the number of such delegates can be less than 10-20-30. In this case the other (majority) will ignore their blocks if these blocks contain voting-out transactions.

What do we get here? We get that if mining is too profitable then delegates may get enough money to "buy" permanent position in top 101. Any expert in Game Theory here?
Title: Re: Consensus on the list of delegates
Post by: chryspano on February 02, 2015, 12:02:56 am
I might be wrong in this and my memory maybe fails me but I think that even if there is only one honest delegate the bad delegates are doomed, the only real side effect will be the slow transaction times(16,8 minutes)  because the honest delegate will have to wait for his turn every time until the situation is resolved.

Again I might be wrong in this and it would be better if someone can confirm or deny this.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 12:08:02 am
The non-colluding delegates would include the vote transactions in blocks...

Would they still include these transactions if the delegate who is being voted out promised to pay 1 milion dollars if they didn't?

I'm analyzing a situation when delegates bribe other delegates in exchange of keeping their position in top 101. Every rational delegate will accept the money. There can be some delegates who will reject the money but depending on the offered amount the number of such delegates can be less than 10-20-30. In this case the other (majority) will ignore their blocks if these blocks contain voting-out transactions.

What do we get here? We get that if mining is too profitable then delegates may get enough money to "buy" permanent position in top 101. Any expert in Game Theory here?

So you've gone from requiring 51 colluding delegates elected to 101 delegates who will eventually collude.  Assuming the 101 delegates all trust each other and don't betray one another after striking their agreement, they still aren't going to be able to keep their alliance a secret.  That fact that they're ignoring transactions to vote them out will be quickly observed and brought to public attention, which will destroy the value of their fork of the chain, and with it the value of the delegate positions for which they've worked so hard.  This is basically a worst case scenario, in which a single malicious group takes over all delegate positions, and I think it would likely require a hard fork maintaining current balances but resetting the elected delegates.

Since this sort of hostile takeover leaves the target chain basically worthless, I don't think it would be worth the cost and effort for anyone to seriously attempt, unless a competitor to BitShares was truly desperate.  Even for a competitor, the cost to recruit all 101 delegates would probably exceed the cost to the BitShares community of forking to resolve the issue.

The assertion that every rational delegate will accept the money also implies that every delegate values reputation very little, and short term monetary gain very highly, but which value systems are objectively the most rational is a discussion for another time.
Title: Re: Consensus on the list of delegates
Post by: sschechter on February 02, 2015, 01:16:06 am
All these attacks of course are entirely theoretical and extremely unlikely.  BitShares is a company like any other centralized company....  No delegate will offer 1 million dollars unless being in that spot can guarantee the money gets returned - a bet that is extraordinarily risky.  If a delegate gets voted out, they are better off spending the money to lobby voters to get voted back in.  There is no penalty to get voted out then voted back in, minus a temporary loss of income. If delegates are making a million dollars, then you're a goddamn idiot for not investing now when they are making $2000-3000 a month. Theoretically, every Google employee could shoot each other in the face, and its shareholders would get burned.  It doesn't stop people from taking that risk and investing in Google.  Your game theory scenario requires that the main participant makes bad choices that go against his own self interest.  There is no mechanism in place that prevents delegates from taking the money and not fulfilling their promise to the bad actor.

Its great that you are thinking these scenarios through and asking these questions, but the thing about BitShares is that its made up of entrepreneurs willing to go out and do, and to take risks that these extraordinary edge cases will exist and will never happen.  Its why we will make the money while those chasing perfection will end up teaching university courses. BitShares always has a back up plan in case of the unpredictable black swan, but it doesn't waste time squabbling about optimizing the effectiveness of plans that are unlikely to ever be needed.
Title: Re: Consensus on the list of delegates
Post by: theoretical on February 02, 2015, 01:29:31 am
What ensures that the shareholders agree on the list of delegates? If a delegate can be kicked off for misbehavior then the list can change instantly which is hard to achieve in a distributed system.

Every BTS balance keeps track of the slate [1] it's voting for.  Whenever BTS moves, vote totals are updated.

[1] A "slate" is a set of delegate accounts assigned a numeric ID.
Title: Re: Consensus on the list of delegates
Post by: cube on February 02, 2015, 05:05:44 am
Welcome Come-from-Beyond.  I am glad you join the bitshares community. 

The people who can really help you with the 'deep questions' you are seeking answers for are bytemaster and its developers. vikram and theoretical are two of the key developers on the bitshares blockchain. Another user, arhag may help you too.
Title: Re: Consensus on the list of delegates
Post by: xeroc on February 02, 2015, 08:33:38 am
Would they still include these transactions if the delegate who is being voted
out promised to pay 1 milion dollars if they didn't?

I'm analyzing a situation when delegates bribe other delegates in exchange of
keeping their position in top 101. Every rational delegate will accept the
money. There can be some delegates who will reject the money but depending on
the offered amount the number of such delegates can be less than 10-20-30. In
this case the other (majority) will ignore their blocks if these blocks contain
voting-out transactions.

You can always (not only try to) buy votes. Though you need to keep it a secret.
Also, you do not gain anything by having a single delegate active. You need
plenty to be able to fake price feeds in the market, which can be observed by
(other) people and make them downvote you. If you manage to buy 51% you can fuck
with the system, as you can with ANY consensus algorithm, because by definition
51% is majority and defined "consensus" :)

Through I don't believe you can "buy" 51 delegates. Once you just "ask" an
honest guys he will certainly ring bells and warn the community about what's
going on.

Further, if 51% is not achieved yet but an attack has been identified, the
stakeholders can still vote for a hard fork to "freeze" malicious signing keys.

What do we get here? We get that if mining is too profitable then
delegates may get enough money to "buy" permanent position in top 101. Any
expert in Game Theory here?
No game theory expert here, but I can tell you that delegates cannot get enough
delegate pay to pay for their positions 'on ther own'. There will always be a
need for more money to flow in if someone outside wants your delegate to be in
the top 101.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 08:43:43 am
Thank you for your replies guys. The problem is becoming more and more interesting.

Imagine that someone created a smart contract that pays money to every delegate as long as none of the delegates is voted out. In this case every delegate knows that he will get money with 100% probability. It's also impossible to know who is bribing, it can be any or even several delegates. The shareholders can't abandon this fork because even if all the delegates are replaced with new ones then the smart contract will keep paying money.

I showed how bribery can be reliable, unavoidable and briber undetectable and there is no even need to keep the fact of bribery in secret. Several honest delegates can be excluded by dishonest ones by pretending that their blocks don't reach the next in the queue. Or am I wrong and blocks can't be ignored?
Title: Re: Consensus on the list of delegates
Post by: xeroc on February 02, 2015, 08:48:43 am
Thank you for your replies guys. The problem is becoming more and more interesting.

Imagine that someone created a smart contract that pays money to every delegate as long as none of the delegates is voted out. In this case every delegate knows that he will get money with 100% probability. It's also impossible to know who is bribing, it can be any or even several delegates. The shareholders can't abandon this fork because even if all the delegates are replaced with new ones then the smart contract will keep paying money.
You don't need a smart contract. Delegates get all payed already. Depending on their payrate 0%-100%, they get x% of 50BTS per block that is signed.
That also leads to an incentive to stay honest.

I don't see how a smart-contract would change anything. BTW, who pays for the smart-contract?

Quote
I showed how bribery can be reliable, unavoidable and briber undetectable and there is no even need to keep the fact of bribery in secret. Several honest delegates can be excluded by dishonest ones by pretending that their blocks don't reach the next in the queue. Or am I wrong and blocks can't be ignored?
blocks can be ignored. and due to the 10secs block interval it happens from time to time that your next delegates just doesn't see your block in-time.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 09:05:21 am
You don't need a smart contract. Delegates get all payed already. Depending on their payrate 0%-100%, they get x% of 50BTS per block that is signed.
That also leads to an incentive to stay honest.

I don't see how a smart-contract would change anything. BTW, who pays for the smart-contract?

I used the smart contract to get a cryptographically reliable bribery. 0.4 BTS is a nice bonus to 50 BTS, isn't it? Any delegate can afford to pay this amount to others and still keep 50 - 0.4*100 = 10 BTS. Being a dishonest is still profitable if none of the delegates can be kicked off.

A delegate that wants to stay in top 101 forever pays for the smart contract. This can be done via a sockpuppet account.
Title: Re: Consensus on the list of delegates
Post by: xeroc on February 02, 2015, 09:43:23 am
So what happens if less than 101 people pay into the smart-contract? The smart contract still pays to all 101 delegates?
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 10:44:22 am
So what happens if less than 101 people pay into the smart-contract? The smart contract still pays to all 101 delegates?

Even 1 person is enough. The SC does pay to all 101 delegates. We can make it worse if some shareholders want to keep delegates the voted-for in top 101. These shareholders just need to send money to the balance of the SC.
Title: Re: Consensus on the list of delegates
Post by: xeroc on February 02, 2015, 11:55:29 am
So what happens if less than 101 people pay into the smart-contract? The smart contract still pays to all 101 delegates?

Even 1 person is enough. The SC does pay to all 101 delegates. We can make it worse if some shareholders want to keep delegates the voted-for in top 101. These shareholders just need to send money to the balance of the SC.
I don't get it ..
In order for that to work, those that want the current 101 delegates to stay where they are, they need 51% of the stake. Else the others (majority) can simply vote them down. The SC would than pay to new people being independent from the attacker, won't they?
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 01:43:53 pm
So what happens if less than 101 people pay into the smart-contract? The smart contract still pays to all 101 delegates?

Even 1 person is enough. The SC does pay to all 101 delegates. We can make it worse if some shareholders want to keep delegates the voted-for in top 101. These shareholders just need to send money to the balance of the SC.
I don't get it ..
In order for that to work, those that want the current 101 delegates to stay where they are, they need 51% of the stake. Else the others (majority) can simply vote them down. The SC would than pay to new people being independent from the attacker, won't they?

The point is that being "rational" he thinks that all 101 delegates would immediately accept payment from the smart contract, and reject any new voting transactions that would replace any delegate.  He's basically asserting that the BitShares network would be unable to find even 1 out of the 101 delegates who would refuse to sabotage the network if offered a 1% pay raise as a bribe to sabotage it:

You don't need a smart contract. Delegates get all payed already. Depending on their payrate 0%-100%, they get x% of 50BTS per block that is signed.
That also leads to an incentive to stay honest.

I don't see how a smart-contract would change anything. BTW, who pays for the smart-contract?

I used the smart contract to get a cryptographically reliable bribery. 0.4 BTS is a nice bonus to 50 BTS, isn't it? Any delegate can afford to pay this amount to others and still keep 50 - 0.4*100 = 10 BTS. Being a dishonest is still profitable if none of the delegates can be kicked off.

A delegate that wants to stay in top 101 forever pays for the smart contract. This can be done via a sockpuppet account.

If he actually believes this would work, he has my sympathy, and I hope he can spend more time around here in the future and get to know some of us and our delegates.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 01:52:56 pm
The point is that being "rational" he thinks that all 101 delegates would immediately accept payment from the smart contract, and reject any new voting transactions that would replace any delegate.  He's basically asserting that the BitShares network would be unable to find even 1 out of the 101 delegates who would refuse to sabotage the network if offered a 1% pay raise as a bribe to sabotage it:

Not all 101. 50 is enough, because with 1 briber this group gets majority and can ignore blocks of other 50 delegates.
Title: Re: Consensus on the list of delegates
Post by: xeroc on February 02, 2015, 02:02:21 pm
The point is that being "rational" he thinks that all 101 delegates would immediately accept payment from the smart contract, and reject any new voting transactions that would replace any delegate.  He's basically asserting that the BitShares network would be unable to find even 1 out of the 101 delegates who would refuse to sabotage the network if offered a 1% pay raise as a bribe to sabotage it:

Not all 101. 50 is enough, because with 1 briber this group gets majority and can ignore blocks of other 50 delegates.
I don't get why this is not a classical 51% attack?
Title: Re: Consensus on the list of delegates
Post by: sschechter on February 02, 2015, 02:24:45 pm
The point is that being "rational" he thinks that all 101 delegates would immediately accept payment from the smart contract, and reject any new voting transactions that would replace any delegate.  He's basically asserting that the BitShares network would be unable to find even 1 out of the 101 delegates who would refuse to sabotage the network if offered a 1% pay raise as a bribe to sabotage it:

This also assumes that our non anonymous delegates are willing to harm their own reputation and risk their own investments for peanuts.

 +5% +5%

Even in these EXTREME scenarios you present, whats the harm to the network? Why can't the network be forked?

Sony was hacked, Target was hacked....a PR blunder for sure but did that actually stop anyone from shopping at Sony or Target?
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 02:38:29 pm
The point is that being "rational" he thinks that all 101 delegates would immediately accept payment from the smart contract, and reject any new voting transactions that would replace any delegate.  He's basically asserting that the BitShares network would be unable to find even 1 out of the 101 delegates who would refuse to sabotage the network if offered a 1% pay raise as a bribe to sabotage it:

Not all 101. 50 is enough, because with 1 briber this group gets majority and can ignore blocks of other 50 delegates.
1 delegate can ignore blocks from the other 100 and thus fork the network without bribing anyone, but that doesn't gain him anything.

51 delegates all ignoring blocks from the other 50 doesn't gain them anything either. Their fork will have 51 delegates, but the honest fork will quickly replace them and have 101 delegates.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 03:14:03 pm
I don't get why this is not a classical 51% attack?

It's like 51% but without chain reorg.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 03:15:53 pm
This also assumes that our non anonymous delegates are willing to harm their own reputation and risk their own investments for peanuts.

They won't harm their reputation because you can't prove that they saw a transaction but decided to ignore it.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 03:18:35 pm
1 delegate can ignore blocks from the other 100 and thus fork the network without bribing anyone, but that doesn't gain him anything.

51 delegates all ignoring blocks from the other 50 doesn't gain them anything either. Their fork will have 51 delegates, but the honest fork will quickly replace them and have 101 delegates.

Chain of 1 delegate will be very short and ignored.

51 delegates ignoring blocks from other 50 get the bribery money. How the honest fork can win if its chain is shorter?
Title: Re: Consensus on the list of delegates
Post by: sschechter on February 02, 2015, 03:23:49 pm
This also assumes that our non anonymous delegates are willing to harm their own reputation and risk their own investments for peanuts.

They won't harm their reputation because you can't prove that they saw a transaction but decided to ignore it.

Then users will swarm the boards wondering why their transactions went through.  The community will discover they've been attacked, and will roll back / fork the network to vote in a new set of delegates.  The attackers attack will have been for naught.  Short term, this attack will give BitShares a minor black eye, but long term it will show how resilient the network is and there will be no more incentives to perform this attack again.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 03:34:41 pm
1 delegate can ignore blocks from the other 100 and thus fork the network without bribing anyone, but that doesn't gain him anything.

51 delegates all ignoring blocks from the other 50 doesn't gain them anything either. Their fork will have 51 delegates, but the honest fork will quickly replace them and have 101 delegates.

Chain of 1 delegate will be very short and ignored.

51 delegates ignoring blocks from other 50 get the bribery money. How the honest fork can win if its chain is shorter?
How will their chain be shorter, when they have 101 delegates and the attackers only have 51?  The attackers can't replace the honest delegates without shareholder support, so their branch will be crippled.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 03:39:56 pm
Then users will swarm the boards wondering why their transactions went through.  The community will discover they've been attacked, and will roll back / fork the network to vote in a new set of delegates.  The attackers attack will have been for naught.  Short term, this attack will give BitShares a minor black eye, but long term it will show how resilient the network is and there will be no more incentives to perform this attack again.

This won't work for DACs. They can't read forums. A good solution ought to be automatic.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 03:44:34 pm
How will their chain be shorter, when they have 101 delegates and the attackers only have 51?  The attackers can't replace the honest delegates without shareholder support, so their branch will be crippled.

This is why the title of this thread is "Consensus on the list of delegates". Consensus can be achieved only via blockchain. If 51 delegates control information that is stored on the blockchain then there is no a way to replace them with other delegates in a reliable manner. You inevitably come to necessity to make a centralized decision.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 03:51:54 pm
How will their chain be shorter, when they have 101 delegates and the attackers only have 51?  The attackers can't replace the honest delegates without shareholder support, so their branch will be crippled.

This is why the title of this thread is "Consensus on the list of delegates". Consensus can be achieved only via blockchain. If 51 delegates control information that is stored on the blockchain then there is no a way to replace them with other delegates in a reliable manner. You inevitably come to necessity to make a centralized decision.
You're missing the point here. The fork is created by some delegates ignoring transactions and blocks that include votes that take away their power.  The other fork therefore includes those votes. Therefore the honest fork automatically heals itself, and the dishonest fork cannot.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 04:03:48 pm
You're missing the point here. The fork is created by some delegates ignoring transactions and blocks that include votes that take away their power.  The other fork therefore includes those votes. Therefore the honest fork automatically heals itself, and the dishonest fork cannot.

The other fork is shorter, why is it accepted as legit?
Title: Re: Consensus on the list of delegates
Post by: svk on February 02, 2015, 04:06:40 pm
1 delegate can ignore blocks from the other 100 and thus fork the network without bribing anyone, but that doesn't gain him anything.

51 delegates all ignoring blocks from the other 50 doesn't gain them anything either. Their fork will have 51 delegates, but the honest fork will quickly replace them and have 101 delegates.

Chain of 1 delegate will be very short and ignored.

51 delegates ignoring blocks from other 50 get the bribery money. How the honest fork can win if its chain is shorter?

I still fail to see why on earth anyone would jeopardize their reputation and future pay for a laughable 1% bribe (spread out over time as well), and more importantly how you expect to be able to bribe >50 delegates without a single person refusing and blowing your scheme open.

To me this whole scenario is so far fetched I don't understand how it's gotten to 4 pages of discussion.. You're saying the delegate will use 80% of his pay in order to stay elected, but that's just not realistic so in reality you'd have someone paying more to stay in than what they're earning by staying in. So then what would be the point of doing all this?

Title: Re: Consensus on the list of delegates
Post by: xeroc on February 02, 2015, 04:07:55 pm
How about a penalty for delegates not including transactions that the network has seen for 30 secs and are valid? Penalty would be to deny 2-10 rounds of payment.
Would that help in this case?
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 04:14:16 pm
So then what would be the point of doing all this?

The point is just to show that power that controls election will stay on the top forever. This is what we observe in a lot of dictatorship countries where elections are faked.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 04:15:14 pm
How about a penalty for delegates not including transactions that the network has seen for 30 secs and are valid? Penalty would be to deny 2-10 rounds of payment.
Would that help in this case?

How could you know that the network "sees" a transaction?
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 04:17:47 pm
How about a penalty for delegates not including transactions that the network has seen for 30 secs and are valid? Penalty would be to deny 2-10 rounds of payment.
Would that help in this case?
This would be difficult to implement and is unnecessary. Ignoring legitimate blocks makes your chain shorter than including them does...
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 04:23:27 pm
Ignoring legitimate blocks makes your chain shorter than including them does...

It's fine as long as your chain is still the longest.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 04:31:24 pm
Ignoring legitimate blocks makes your chain shorter than including them does...

It's fine as long as your chain is still the longest.
But it won't be, because every time an honest delegate's turn comes around, the votes will be included and the longest chain will be an honest chain again.
Title: Re: Consensus on the list of delegates
Post by: cube on February 02, 2015, 04:34:16 pm
So then what would be the point of doing all this?

The point is just to show that power that controls election will stay on the top forever. This is what we observe in a lot of dictatorship countries where elections are faked.

Nicely derived argument. 
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 04:37:20 pm
So then what would be the point of doing all this?

The point is just to show that power that controls election will stay on the top forever. This is what we observe in a lot of dictatorship countries where elections are faked.

Nicely derived argument.
Except that the delegates can't falsify votes, and thus don't actually control the election. They can't even conceal the existence of the votes. They can only exclude them from their blocks.
Title: Re: Consensus on the list of delegates
Post by: xeroc on February 02, 2015, 05:05:42 pm
How about a penalty for delegates not including transactions that the network has seen for 30 secs and are valid? Penalty would be to deny 2-10 rounds of payment.
Would that help in this case?
This would be difficult to implement and is unnecessary. Ignoring legitimate blocks makes your chain shorter than including them does...
I am not talking about invalidating blocks .. but reducing the pay if a transaction was excluded by you.

Delegates can identify if you misses to include a tx ... if i reveice a tx and construct a block containg it although i received the tx 30secs ago already.. coulsn't i assume the previous 1 or 2 delegatea have received them to?

Sure, numbers have to be optimized..
Title: Re: Consensus on the list of delegates
Post by: sschechter on February 02, 2015, 05:15:31 pm
Then users will swarm the boards wondering why their transactions went through.  The community will discover they've been attacked, and will roll back / fork the network to vote in a new set of delegates.  The attackers attack will have been for naught.  Short term, this attack will give BitShares a minor black eye, but long term it will show how resilient the network is and there will be no more incentives to perform this attack again.

This won't work for DACs. They can't read forums. A good solution ought to be automatic.

Already addressed by a previous post:

"BitShares always has a back up plan in case of the unpredictable black swan, but it doesn't waste time squabbling about optimizing the effectiveness of plans that are unlikely to ever be needed."

"Its why we will make the money while those chasing perfection will end up teaching university courses. "

You opinion of what is a 'good' solution is just your opinion, based on a theoretical assumption that a DAC can't have human intervention.  As a practical solution, I think my solution is great, and it kills the incentive for such an EXTREMELY improbable attack.
Title: Re: Consensus on the list of delegates
Post by: sschechter on February 02, 2015, 05:22:04 pm
So then what would be the point of doing all this?

The point is just to show that power that controls election will stay on the top forever. This is what we observe in a lot of dictatorship countries where elections are faked.

BitShares is like a company, not a country. In you're hostile takeover scenario, the result would be that no new employees can be hired, unless they have the approval of the existing employers.  In your nightmare scenario, BitShares becomes like every other company on the planet. I think I'll manage to sleep ok.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 05:37:20 pm
But it won't be, because every time an honest delegate's turn comes around, the votes will be included and the longest chain will be an honest chain again.

Blocks of honest delegates will be excluded completely. Bitcoin Selfish Mining attack uses exactly the same trick.
Title: Re: Consensus on the list of delegates
Post by: jsidhu on February 02, 2015, 05:40:55 pm
Are you trying to figure out how to hack the network? Just read the source if so?
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 05:47:01 pm
If we come to the problem from another side...

Let's assume that 20 honest delegate is indeed enough to outweigh the other 81 ones. Then we should agree that in situation when 61 delegates vote for no change, 20 delegates vote for scenario A and 20 delegates vote for scenario B we will be completely confused what branch to follow - A or B. Hence this can be used to fragment the network. It's so obvious that I can't even provide a formal proof (trivial things are very hard to prove).
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 05:58:05 pm
Are you trying to figure out how to hack the network? Just read the source if so?

Reading the source won't help much because I can't get the idea. Common sense says that if a government controls election process then this government can't be voted-out if it doesn't want this. In the real world we have separation of powers. What do we have in BitShares to avoid abuse of power? I already knew that the shareholders can fire delegates, bad thing is that they have to do it only with help of these delegates and the delegates may refuse to do so by pretending that they don't see voting-out transactions.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 06:05:03 pm
But it won't be, because every time an honest delegate's turn comes around, the votes will be included and the longest chain will be an honest chain again.

Blocks of honest delegates will be excluded completely. Bitcoin Selfish Mining attack uses exactly the same trick.
Sure, they'll be excluded from confirmation in the hostile chain, but they'll still be the leaf blocks in that chain after every honest delegate turn.  Each such honest leaf block can include votes that replace the hostile delegates and heal the chain.
Title: Re: Consensus on the list of delegates
Post by: liondani on February 02, 2015, 06:05:53 pm
You can try out several attacks very cheaply on DevShares  ;)

Sent from my ALCATEL ONE TOUCH 997D

Title: Re: Consensus on the list of delegates
Post by: sschechter on February 02, 2015, 06:14:29 pm
Are you trying to figure out how to hack the network? Just read the source if so?

Reading the source won't help much because I can't get the idea. Common sense says that if a government controls election process then this government can't be voted-out if it doesn't want this. In the real world we have separation of powers. What do we have in BitShares to avoid abuse of power? I already knew that the shareholders can fire delegates, bad thing is that they have to do it only with help of these delegates and the delegates may refuse to do so by pretending that they don't see voting-out transactions.

In the BitShares world, delegates are not government representatives, they are employees of a company. If your scenario happens, what is the actual harm done?
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 06:15:57 pm
If we come to the problem from another side...

Let's assume that 20 honest delegate is indeed enough to outweigh the other 81 ones. Then we should agree that in situation when 61 delegates vote for no change, 20 delegates vote for scenario A and 20 delegates vote for scenario B we will be completely confused what branch to follow - A or B. Hence this can be used to fragment the network. It's so obvious that I can't even provide a formal proof (trivial things are very hard to prove).
The only flexibility the delegates have is to ignore valid transactions or to ignore valid blocks and make their own fork.

If all the block signers in any blockchain network decide to ignore all other signers' blocks, then sure, they'll create lots of equally illegitimate forks and make a mess of things.

In the BitShares network, as long as there are some delegates who continue building on the longest valid chain, and including valid transactions, that group will have an advantage over any group that ignores valid blocks. Even if they start out outnumbered, they can replace delegates by including votes, while hostile groups can only ignore honest delegates.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 06:16:17 pm
Sure, they'll be excluded from confirmation in the hostile chain, but they'll still be the leaf blocks in that chain after every honest delegate turn.  Each such honest leaf block can include votes that replace the hostile delegates and heal the chain.

...and heal a shorter chain. I don't get why someone would adopt a shorter chain. What lines of the code will make them do so?
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 06:18:27 pm
In the BitShares world, delegates are not government representatives, they are employees of a company. If your scenario happens, what is the actual harm done?

You call them employees but this doesn't change the fact that they can exclude those employees who try to publish orders leading to their firing.

The harm is this - the employees will be employed forever and here we come to a work-around - noone should be a delegate indefinitely. Isn't it why the USA president can't be elected more than twice?
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 06:21:13 pm
Sure, they'll be excluded from confirmation in the hostile chain, but they'll still be the leaf blocks in that chain after every honest delegate turn.  Each such honest leaf block can include votes that replace the hostile delegates and heal the chain.

...and heal a shorter chain. I don't get why someone would adopt a shorter chain. What lines of the code will make them do so?
If I'm an honest delegate, and I see that the longest chain is the hostile chain, I just have to sign my honest vote including block on the end of that formerly hostile chain, and at that point my honest chain is now the longest chain.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 06:23:23 pm
In the BitShares network, as long as there are some delegates who continue building on the longest valid chain, and including valid transactions, that group will have an advantage over any group that ignores valid blocks. Even if they start out outnumbered, they can replace delegates by including votes, while hostile groups can only ignore honest delegates.

We assume that majority is bribed. Hence even if honest delegates build one chain and dishonest ones build another, the latter will be longer.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 06:26:00 pm
If I'm an honest delegate, and I see that the longest chain is the hostile chain, I just have to sign my honest vote including block on the end of that formerly hostile chain, and at that point my honest chain is now the longest chain.

Then hostile delegates ignore your block and extend their chain with 2 blocks making shareholders to pick theirs.
Title: Re: Consensus on the list of delegates
Post by: sschechter on February 02, 2015, 06:34:38 pm
In the BitShares world, delegates are not government representatives, they are employees of a company. If your scenario happens, what is the actual harm done?

You call them employees but this doesn't change the fact that they can exclude those employees who try to publish orders leading to their firing.

The harm is this - the employees will be employed forever and here we come to a work-around - noone should be a delegate indefinitely. Isn't it why the USA president can't be elected more than twice?

No, this has nothing to do with term limits and presidents.  In your scenario, shareholders can no longer fire employees, only the other employees can.  This is the way Google or any other company works.  In order to get hired, you need approval from Google's employers - no outside opinions matter. No matter how much this forum may like me (if at all :)), they can't vote me into a paid position with Google. Delegates have simple job. The only power they have is to keep their own job if they collude, in your extraordinarily, unlikely, hypothetical scenario.

At the end of the day, when all else fails, human intervention will fix this problem. Whether or not you think this solution meets an arbitrary definition of what you think is 'good' is irrelevant.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 06:37:09 pm
In the BitShares network, as long as there are some delegates who continue building on the longest valid chain, and including valid transactions, that group will have an advantage over any group that ignores valid blocks. Even if they start out outnumbered, they can replace delegates by including votes, while hostile groups can only ignore honest delegates.

We assume that majority is bribed. Hence even if honest delegates build one chain and dishonest ones build another, the latter will be longer.
OK, what you're missing is that while the dishonest delegates are forced to ignore the honest ones, the honest delegates do not suffer the same disadvantage. The honest delegates can continue dropping honest leaf blocks on the hostile chain for as long as the hostile chain is longest. Eventually one of those leaves will give them the majority they need to permanently banish the hostiles.
Title: Re: Consensus on the list of delegates
Post by: Ander on February 02, 2015, 07:04:00 pm
Welcome ComeFromBeyond, and thanks for your ideas! 
I think it is important that we all analyze to try and find realistic attack scenarios.  If we know about them, then we could make any necessary changes to prevent or disincentivize them.


I would love to see DevShares used as a testing ground for this.  There should be people trying to attack DevShares, empirically testing these attack ideas so that we can analyze the results: how much did it cost, and what hard was done?



Title: Re: Consensus on the list of delegates
Post by: cube on February 02, 2015, 07:13:50 pm
Welcome ComeFromBeyond, and thanks for your ideas! 
I think it is important that we all analyze to try and find realistic attack scenarios.  If we know about them, then we could make any necessary changes to prevent or disincentivize them.


I would love to see DevShares used as a testing ground for this.  There should be people trying to attack DevShares, empirically testing these attack ideas so that we can analyze the results: how much did it cost, and what hard was done?

Yes, we should take in critical analyses that helps to harden bitshares defence.  Come_From_Beyond can only help as much as the information given to him.

Title: Re: Consensus on the list of delegates
Post by: Chronos on February 02, 2015, 07:38:49 pm
This looks like a viable attack to me. A disruptive hard fork might be needed to overcome it.

The post-attack scenario is more like a company unable to hire anyone new, with a group of employees that are impossible to fire. Worse, these employees do not have to act in the best interest of the company, but they still receive pay (BTS) no matter their behavior, which they can constantly dump on the market for "real money". Not good, and not anything like today's "centralized" companies.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 07:44:41 pm
This looks like a viable attack to me. A disruptive hard fork might be needed to overcome it.

The post-attack scenario is more like a company unable to hire anyone new, with a group of employees that are impossible to fire. Worse, these employees do not have to act in the best interest of the company, but they still receive pay (BTS) no matter their behavior, which they can constantly dump on the market for "real money". Not good, and not anything like today's "centralized" companies.
Can you explain how this is viable?
Title: Re: Consensus on the list of delegates
Post by: Chronos on February 02, 2015, 07:53:39 pm
Come-From-Beyond has been explaining for 6 pages, haha. I'll summarize:


Do I understand correctly?
Title: Re: Consensus on the list of delegates
Post by: Ander on February 02, 2015, 07:57:55 pm
I believe (with only moderate confidence, I could easily be convinced otherwise by good evidence) that the network if you get 51% of delegates into a hostile state, then this requires the userbase of Bitshares to hard fork to fix the situation.  A hostile delegate includes one that is accepting bribes in order to collaborate with the other hostile delegates.


Ultimately, a blockchain derives value from the size of its network.  Such an attack would split the network into the two forks, and users would be forced to choose between them.  It should be fairly clear what has occurred, and almost all of the users should choose the chain without the hostile delegates.  If people do not support one chain unanimously, then the value of the network will be split into the two forks depending on the number of users who support each one.



Obtaining a delegate spot is relatively difficult, and requires one to build a reputation.  Maintaining a delegate position is also difficult and requires creating value for bitshares, so if the attack is not executed very quickly, there are ongoing costs. 

https://bitsharestalk.org/index.php?topic=13864.msg180306#msg180306


If many delegates are replaced in a short period of time, this is a massive warning flag to everyone to be extra aware of the possibility of attack.

The cost to a delegate who engages in hostile activity (either directly or taking bribes to collaborate), is to potentially lose their delegate position.  Either the attack fails, and those who tried are voted out.  Or the attack succeeds, the userbase is upset at the results, and hardforks back to a good state and removes the offending delegates. 



From a game theory perspective, the major thing working in our favor is that bad actions result in loss of reputation, and it is difficult (expensive) to build reputation.
Title: Re: Consensus on the list of delegates
Post by: sschechter on February 02, 2015, 07:59:31 pm
This looks like a viable attack to me. A disruptive hard fork might be needed to overcome it.

The post-attack scenario is more like a company unable to hire anyone new, with a group of employees that are impossible to fire. Worse, these employees do not have to act in the best interest of the company, but they still receive pay (BTS) no matter their behavior, which they can constantly dump on the market for "real money". Not good, and not anything like today's "centralized" companies.

Not acting in the best interest of employees is one thing, it happens all the time in the real world.  But if it doesn't act in the best interest of its customers, its customers will no longer use its services and the shareholders will dump their shares.  The result is that the hostile employees will destroy their own source of food.  This is not any more likely to occur in BitShares than it would any other brick and mortar company.  At the end of the day, a hostile entity with enough resources can damage any company they feel like.  Should someone want to damage the airline industry, they can fly planes into buildings.  Extraordinary circumstances in which you cannot prepare for require resolution, not over engineered solutions to prevent it from ever happening.  Otherwise, you'd spend all your time coming up with solutions to edge cases without ever building any products.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 08:17:34 pm
Come-From-Beyond has been explaining for 6 pages, haha. I'll summarize:

  • 51 of 101 delegates decide they never want to be fired (via bribery, for example).
  • These delegates ignore all blocks from the other 50 delegates. Their chain is longest, so it is accepted. The 50 are powerless.
  • The 51 delegates ignore all transactions that vote them out, but they still produce blocks without these transactions.
  • In the end, the accepted longest chain never votes them out. They can sell all BTS and maintain control of the chain.

Do I understand correctly?

Yes.
Title: Re: Consensus on the list of delegates
Post by: jsidhu on February 02, 2015, 08:34:15 pm
Its a moot point to try to do this because:

1) The attack will render the value of the underlying asset useless, just like a bitcoin 51% attack. The top mining pools have financial incentive to keep going honestly, just as delegates do.
2) If it does happen we can hard fork and start again, ofcourse it would hurt value unless people believe its a bargain and we end up higher because we survived a hard fork attack
3) If they don't do it fast enough they will get fired as they try to collude, if people find out... all it takes is one leak. Its too hard to keep a secret like this when there are so many parties involved.

With points 1/2 and 3 it is less likely we see the scenario play out as CfB wants it to. Is the block signing system more robust than bitcoin's? I think so, does it improve upon the efficiency of consensus protocol? Yes for sure.

If the system withstands itself from this attack (which is probably the #1 on the list of types of attacks on bitshares) then we have a self re-enforcing system that will end up stronger than it was before.

In what case would the system not be able to withstand itself from this attack? The only case I would see is if people end up shying away from the project because it got hacked and wasnt' recovered in a timely manor. Even though their keys would still be intact they may lose confidence... however I find this very unlikely to be the case.
Title: Re: Consensus on the list of delegates
Post by: donkeypong on February 02, 2015, 08:43:55 pm
So then what would be the point of doing all this?

The point is just to show that power that controls election will stay on the top forever. This is what we observe in a lot of dictatorship countries where elections are faked.

Basically, it's possible for any election on the planet earth to be "bought" in one way or another. So you're saying that elections are always suspect? That BitShares delegates will care more about a potential small bribe than about their longer term financial interest and fiduciary duty to act in the best interests of BitShares? I certainly don't see this as a solid possibility.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 08:56:13 pm
Basically, it's possible for any election on the planet earth to be "bought" in one way or another. So you're saying that elections are always suspect? That BitShares delegates will care more about a potential small bribe than about their longer term financial interest and fiduciary duty to act in the best interests of BitShares? I certainly don't see this as a solid possibility.

Modern election systems are more secure because the branch of the state that supervises election process is not controlled by another branch which is being elected.
Title: Re: Consensus on the list of delegates
Post by: svk on February 02, 2015, 08:57:39 pm
Come-From-Beyond has been explaining for 6 pages, haha. I'll summarize:

  • 51 of 101 delegates decide they never want to be fired (via bribery, for example).
  • These delegates ignore all blocks from the other 50 delegates. Their chain is longest, so it is accepted. The 50 are powerless.
  • The 51 delegates ignore all transactions that vote them out, but they still produce blocks without these transactions.
  • In the end, the accepted longest chain never votes them out. They can sell all BTS and maintain control of the chain.

Do I understand correctly?

If all they wanted was to sell their BTS they'd be better off doing that before attempting an attack though, as the attack will be detected very quickly and promptly cause a big drop in the price of BTS. Being a delegate doesn't give you magical powers to spend BTS you don't have, so I still don't see the economic incentive for anyone to do such a thing, although of course a theoretical malicious entity (read government or bank) might be more plausible.

Even so, like BM has said many times: we'll take their money that they need to spend to gain control of the network, say thank you very much and then just start a new fork.

Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 09:04:41 pm
...and then just start a new fork.

What will happen to DACs in this case?
Title: Re: Consensus on the list of delegates
Post by: donkeypong on February 02, 2015, 09:06:12 pm
Basically, it's possible for any election on the planet earth to be "bought" in one way or another. So you're saying that elections are always suspect? That BitShares delegates will care more about a potential small bribe than about their longer term financial interest and fiduciary duty to act in the best interests of BitShares? I certainly don't see this as a solid possibility.

Modern election systems are more secure because the branch of the state that supervises election process is not controlled by another branch which is being elected.

Really? How is this true in the United States?
Title: Re: Consensus on the list of delegates
Post by: svk on February 02, 2015, 09:32:10 pm
...and then just start a new fork.

What will happen to DACs in this case?

It depends how the shareholders view it I guess, the idea would be to freeze "malicious" funds in the new fork but otherwise just pick up where the other left off. Depending on your interpretation it could be seen as a successful attack in which case you'll lose confidence in the DAC and move on, or you could see it as a failed attack that was successfully fended off. One of those glass half-full/half-empty kind of things..
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 09:32:24 pm
Come-From-Beyond has been explaining for 6 pages, haha. I'll summarize:

  • 51 of 101 delegates decide they never want to be fired (via bribery, for example).
  • These delegates ignore all blocks from the other 50 delegates. Their chain is longest, so it is accepted. The 50 are powerless.
  • The 51 delegates ignore all transactions that vote them out, but they still produce blocks without these transactions.
  • In the end, the accepted longest chain never votes them out. They can sell all BTS and maintain control of the chain.

Do I understand correctly?

Yes.
No.

The hostile delegates can't prevent the honest delegates from creating blocks. All they can do is ignore those honest blocks.  If an honest delegate signs a block that elects one or more new delegates, the newly elected delegates will clearly prefer that fork over the one in which the votes that elected them were ignored.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 09:39:59 pm
Really? How is this true in the United States?

The USA has weird laws, I'm talking about the rest of the world.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 09:42:52 pm
If an honest delegate signs a block that elects one or more new delegates, the newly elected delegates will clearly prefer that fork over the one in which the votes that elected them were ignored.

I suspect this will lead to fragmentation of the network which is very bad because it makes possible to do double-spending almost for free.
Title: Re: Consensus on the list of delegates
Post by: Chronos on February 02, 2015, 09:48:04 pm
If an honest delegate signs a block that elects one or more new delegates, the newly elected delegates will clearly prefer that fork over the one in which the votes that elected them were ignored.

I suspect this will lead to fragmentation of the network which is very bad because it makes possible to do double-spending almost for free.
Also, this is most possible in a 51 vs 50 scenario. If the attackers had a sizable majority, say 81 vs 20, then it would be very difficult for the 20 to add enough ignored votes to their blocks to elect 31 more delegates and remake a longest chain.

EDIT: It should come as no surprise that 81 delegates can control the chain. What is notable is that 81 delegates can (maybe) control the chain and never be voted out without a hard fork, and that bribery methods can (maybe) turn a delegate majority into a Nash equilibrium outcome.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 10:19:14 pm
If an honest delegate signs a block that elects one or more new delegates, the newly elected delegates will clearly prefer that fork over the one in which the votes that elected them were ignored.

I suspect this will lead to fragmentation of the network which is very bad because it makes possible to do double-spending almost for free.
Also, this is most possible in a 51 vs 50 scenario. If the attackers had a sizable majority, say 81 vs 20, then it would be very difficult for the 20 to add enough ignored votes to their blocks to elect 31 more delegates and remake a longest chain.
Clearly if you somehow managed to get a strong majority of delegates hostile to the network elected, they could seriously disrupt service until they were voted out.   I don't think anyone here is disputing that. What I am disputing is the idea that they couldn't be evicted without a hard fork.

The hostile delegates have no way to maintain their power as long as honest delegates are also active, and the hostile delegates can't get rid of the honest ones. The more they disrupt the network, the faster the voters would respond and vote new honest delegates in on an honest block.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 10:24:57 pm
Can't you guys just change the rules slightly and get rid of the issue?
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 10:33:09 pm
Can't you guys just change the rules slightly and get rid of the issue?
If there is an issue...

What exactly are you suggesting?  You're welcome to pull request a fix yourself, or even campaign for a delegate position and try to either work for our blockchain long term or try to sabotage it. :P
Title: Re: Consensus on the list of delegates
Post by: Ander on February 02, 2015, 10:34:49 pm
Can't you guys just change the rules slightly and get rid of the issue?
What is your idea for a rule change that would make things better?
Title: Re: Consensus on the list of delegates
Post by: sschechter on February 02, 2015, 10:52:34 pm
Can't you guys just change the rules slightly and get rid of the issue?
What is your idea for a rule change that would make things better?

After all this discussion, I'm curious to know your fix
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 10:59:53 pm
The easiest part is to increase interval between blocks 51-fold. Then to make majority of delegates to sign every single block together. => 1 confirmation is as reliable as 51 confirmations in old design, but as a free bonus you are now protected against network fragmentation because if you don't see the next superblock for a long time then you are eclipse-attacked or delegates can't find each other.

Next step is setting a requirement to "refresh" votes every week with the quorum set to 51% of the stake. If less than 51% of the stake takes part in the voting then network stalls automatically. => DACs should be happy + employees can't abuse their power.

PS: This is just suggestions, without modelling I can't say if this will work as intended.
Title: Re: Consensus on the list of delegates
Post by: Chronos on February 02, 2015, 11:03:32 pm
The easiest part is to increase interval between blocks 51-fold.
I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 11:11:12 pm
I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

If you include 51x more transactions then tx/sec ratio will be the same.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 11:12:06 pm
The easiest part is to increase interval between blocks 51-fold.
I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.
Yes. This would mess up the markets badly, as well as requiring voters to revote just to keep the network from freezing even when delegates were doing a fine job.  Remember the uproar when having an inactivity fee was proposed? Same thing, plus tragedy of the commons, since the whole network freezes if enough individual voters don't actively keep it alive.

I still don't see any issues this is intended to correct as very serious.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 02, 2015, 11:13:48 pm
I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

If you include 51x more transactions then tx/sec ratio will be the same.
Also that would make our network almost as painfully slow as Bitcoin.
Title: Re: Consensus on the list of delegates
Post by: Chronos on February 02, 2015, 11:15:02 pm
I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

If you include 51x more transactions then tx/sec ratio will be the same.
This would still worsen the exchange, because the blockchain frontruns you. See http://bytemaster.bitshares.org/article/2015/01/29/How-BitShares-Prevents-Front-Running/.
Title: Re: Consensus on the list of delegates
Post by: Ander on February 02, 2015, 11:20:20 pm
Hmm,

I feel that BTS with a 10 second block time and the possibility of an avenue of attack that requires users to agree to hard fork to recover is probably better than BTS with an almost 10 minute transaction time but safer from attack.


Part of the idea behind all Proof of Stake variations is that it might be worth trading off some security in order to greatly improve other aspects of the blockchain such as speed and reduced cost of network security, provided that you can make it still "expensive enough" to execute an attack that no one will want to do it. 


I think it would be quite hard to get 51 delegates elected who all are agreeing to collude in a way detrimental to bitshares.  If the plan involves bribing other delegates, I think at least one of the delegates you approach will believe that a reputation gain they can get from exposing the scheme to everyone and helping defeat it will outweigh any possible payment. 


I think that all of this is worth empirically testing by trying to attack DevShares.   We might learn interesting things.  If one could successfully attack DevShares and show that it wasnt expensive enough to do, then changing Bitshares in whatever way is needed to avoid the attack is probably worth it.
Title: Re: Consensus on the list of delegates
Post by: Ander on February 02, 2015, 11:21:47 pm
The easiest part is to increase interval between blocks 51-fold.
I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

Yes this, 10 second transactions are important for running an Exchange. 
Its not worth it to kill the functionality of the DAC in order to secure it more.



Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 02, 2015, 11:22:39 pm
Well, with 200 ms latency you still get 10 sec blocks.

No idea how to fix 51% stake requirement though.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 03, 2015, 12:05:59 am
Hmm,

I feel that BTS with a 10 second block time and the possibility of an avenue of attack that requires users to agree to hard fork to recover is probably better than BTS with an almost 10 minute transaction time but safer from attack.
...

...but recovery wouldn't require a hard fork in the current system, and in a system where the majority of delegates had to sign each block, as CfB is proposing, recovering would require a hard fork if the majority of delegates were hostile.
Title: Re: Consensus on the list of delegates
Post by: gamey on February 03, 2015, 01:06:05 am
So then what would be the point of doing all this?

The point is just to show that power that controls election will stay on the top forever. This is what we observe in a lot of dictatorship countries where elections are faked.

Basically, it's possible for any election on the planet earth to be "bought" in one way or another. So you're saying that elections are always suspect? That BitShares delegates will care more about a potential small bribe than about their longer term financial interest and fiduciary duty to act in the best interests of BitShares? I certainly don't see this as a solid possibility.

This is an interesting thread but it can be summed up with a few points

51%" attacks at various levels/layers.  In Bitcoin, 51% of the pools could attack or 51% of the hashing power.  51% of the pools could immediately start doing this attack in BTC.  That is nothing new.

All elections/consensus can be 51% attacked.

The reality is that there is a human component so if this happened it could be forked around. It would be very pricey for the attackers. It would be an interesting thing to observe if it were to actually happen.  (Whose disruptive/attacking stake is removed?)

I'm not sure how NXT works, but it seems likely we could concoct very similar attacks to NXT.  Once 51% of those mining/forging pools fall under the control of the same entity, they could ignore the blocks of the minority and thus reap all the transaction fees themselves. Is this not correct?  The only difference is the magnitude at which people are being paid.  How does NXT fix this 51% problem ?

Title: Re: Consensus on the list of delegates
Post by: Ander on February 03, 2015, 01:38:10 am
Democracy can be 51% attacked. :)
Title: Re: Consensus on the list of delegates
Post by: arhag on February 03, 2015, 02:36:16 am
The easiest part is to increase interval between blocks 51-fold. Then to make majority of delegates to sign every single block together. => 1 confirmation is as reliable as 51 confirmations in old design, but as a free bonus you are now protected against network fragmentation because if you don't see the next superblock for a long time then you are eclipse-attacked or delegates can't find each other.

While I don't think the attack you are suggesting is a serious issue and I don't really see how your suggestion prevents the 51+ delegate collusion attack, I have proposed (https://bitsharestalk.org/index.php?topic=13872.0) something similar to what you suggested but without changing block interval requirements. The idea is that in typical scenarios, we should have greater than 80% delegate confirmation of the state of the blockchain within 20 seconds.

Next step is setting a requirement to "refresh" votes every week with the quorum set to 51% of the stake. If less than 51% of the stake takes part in the voting then network stalls automatically. => DACs should be happy + employees can't abuse their power.

It is already possible in theory to measure how much of the stake has participated in voting where the votes are not older than a given time. I don't think there is any reason to make this a hard requirement in the blockchain. If a user feels uncomfortable with the percentage of the stake that has updated their votes in the last month, for example, or especially if their vote update transactions are being ignored by the delegates, then they could perhaps start communicating their suspicions with others and start organizing a potential hard fork. In the forked chain (I will call BTS'), which snapshots off a recent block in the main chain, they can all vote on whether their vote update transactions have been filtered by the delegates in the main chain and that they wish to start with a new clean slate of delegates. If you reach some quorum on this fact (+ the new set of 101 delegates to take over the new chain) on that new chain (say >50%), then the stakeholders will initiate yet another hard fork of the original BTS chain.

The second hard fork is to incorporate in the snapshot all the updates to stake and BitAsset ownership during the time between the first snapshot and the second snapshot, which should be very soon after the point at which 50% consensus is reached on the first fork. Then on this second forked chain (BTS''), a quorum of 75%, for example, would be necessary for the chain to begin as the new BTS and for the original chain (BTS) to be considered an invalid fork (and hopefully merchants and exchanges will also agree to this new consensus) . People will dump the stake of the old chain (killing the old chain's market cap) and start using BTS'', now rebranded BTS, of the new chain like the real BTS. Any transfer on the original chain after the point of the second snapshot might be void (double spend), but the users should have likely stopped transferring stake on the original chain, just to be safe, when they realized that 50% consensus was reached on a fork.
Title: Re: Consensus on the list of delegates
Post by: arhag on February 03, 2015, 03:34:55 am
By the way, I haven't had time to carefully read the entire 8 pages, but I think it is worth commenting on the exchange between Troglodactyl and Come-from-Beyond. This is how I understand the consensus mechanism of DPOS to work (I would appreciate any corrections in my understanding by the devs).

Let's say 100 delegates are colluding to ignore any transactions that update the votes against their favor. They are also ignoring all blocks by the remaining honest delegate. They have 100/101 = 99% delegate participation. People are creating, signing, and broadcasting transactions that changes the vote for their balance away from the evil delegates and to other honest delegates. There exists enough transactions that if included in the blockchain would cause the delegates of the next round to be 101 honest delegates. However, anytime the single honest active delegates includes these transactions, the other delegates ignore his block.

The single honest delegate can wait until a round in which he is one of the last 4 block producers (this happens approximately 4% of the time every 17 minutes, which means it would take 1.5 days (https://www.google.com/?gws_rd=ssl#q=log(0.01)%2Flog(1+-+4%2F101)+*+(101+*+10+seconds)) for there to be a greater than 99% probability of this opportunity opening up). If the single honest active delegate builds off the longest current chain created by the other colluding 100 evil delegates and includes as many transactions as possible in his block to get as many honest new delegates to replace the other 100 evil delegates, then this honest delegate could create a fork that reaches the next round with (ideally) a set of 101 honest delegates and with anywhere from 0 to 4 blocks less than the original chain created by the 100 evil delegates (which is why clients will ignore this fork for now). In this next round, all of the (ideally) 101 honest delegates in the competing fork each create a valid block (and include other remaining vote update transactions to get the number of honest delegates in the following rounds to 101 if it isn't already). If there were in fact 101 honest delegates in this round, that means they gain a one block advantage compared to the competing fork created by the colluding 100 evil delegates. After four more rounds like this, they will have a longer chain than the chain created by the 100 evil delegates. Even if the first round of the fork does not have 101 honest delegates (because it was impossible to stuff enough transactions in a single block to replace all 100 evil delegates), realistically, it just means that a few more rounds are needed before they have the longest chain. If they can get this longest chain within 16 rounds (before the chain reorganization limit), all live clients will switch over to that new chain run by the honest set of delegates. Clients that were offline during this transition and trying to resync some time later will then (I think?) choose the longest chain which would at that point be the one run by the 101 new honest delegates and not the one by the 100 old evil delegates whose chain would keep falling further behind.

So, if my assumptions about the details of how DPOS works is true, it means that even if one honest delegate remains, it is possible for the network to recover without hard forks in a reasonable amount of time. Now if all 101 delegates are evil and colluding together, then stakeholders have to resort to the hard fork method which I discussed in my previous post.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 03, 2015, 04:15:36 am
By the way, I haven't had time to carefully read the entire 8 pages, but I think it is worth commenting on the exchange between Troglodactyl and Come-from-Beyond. This is how I understand the consensus mechanism of DPOS to work (I would appreciate any corrections in my understanding by the devs).

Let's say 100 delegates are colluding to ignore any transactions that update the votes against their favor. They are also ignoring all blocks by the remaining honest delegate. They have 100/101 = 99% delegate participation. People are creating, signing, and broadcasting transactions that changes the vote for their balance away from the evil delegates and to other honest delegates. There exists enough transactions that if included in the blockchain would cause the delegates of the next round to be 101 honest delegates. However, anytime the single honest active delegates includes these transactions, the other delegates ignore his block.

The single honest delegate can wait until a round in which he is one of the last 4 block producers (this happens approximately 4% of the time every 17 minutes, which means it would take 1.5 days (https://www.google.com/?gws_rd=ssl#q=log(0.01)%2Flog(1+-+4%2F101)+*+(101+*+10+seconds)) for there to be a greater than 99% probability of this opportunity opening up). If the single honest active delegate builds off the longest current chain created by the other colluding 100 evil delegates and includes as many transactions as possible in his block to get as many honest new delegates to replace the other 100 evil delegates, then this honest delegate could create a fork that reaches the next round with (ideally) a set of 101 honest delegates and with anywhere from 0 to 4 blocks less than the original chain created by the 100 evil delegates (which is why clients will ignore this fork for now). In this next round, all of the (ideally) 101 honest delegates in the competing fork each create a valid block (and include other remaining vote update transactions to get the number of honest delegates in the following rounds to 101 if it isn't already). If there were in fact 101 honest delegates in this round, that means they gain a one block advantage compared to the competing fork created by the colluding 100 evil delegates. After four more rounds like this, they will have a longer chain than the chain created by the 100 evil delegates. Even if the first round of the fork does not have 101 honest delegates (because it was impossible to stuff enough transactions in a single block to replace all 100 evil delegates), realistically, it just means that a few more rounds are needed before they have the longest chain. If they can get this longest chain within 16 rounds (before the chain reorganization limit), all live clients will switch over to that new chain run by the honest set of delegates. Clients that were offline during this transition and trying to resync some time later will then (I think?) choose the longest chain which would at that point be the one run by the 101 new honest delegates and not the one by the 100 old evil delegates whose chain would keep falling further behind.

So, if my assumptions about the details of how DPOS works is true, it means that even if one honest delegate remains, it is possible for the network to recover without hard forks in a reasonable amount of time. Now if all 101 delegates are evil and colluding together, then stakeholders have to resort to the hard fork method which I discussed in my previous post.

This is my understanding also, except that I don't know why offline clients would require manual intervention on resyncing.  They should sync to the active network, and may not even be aware that a fork existed unless they are isolation attacked.

I did think delegates could be voted out mid-round, but it looks like you're right on that unless I'm missing something.  I think this is a bug that should be corrected, and that a delegate should not be expected to confirm a block that revokes his active delegate status by voting him out of the top 101.

Issue created: https://github.com/BitShares/bitshares/issues/1344

EDIT: Strikethrough response to ninja edited comments.  :P
Title: Re: Consensus on the list of delegates
Post by: arhag on February 03, 2015, 04:31:07 am
This is my understanding also, except that I don't know why offline clients would require manual intervention on resyncing.

I think you were referring to the previous version of my post which I edited to correct that mistake prior to you pressing the quote button :).

I originally was worried about whether the offline clients would automatically be able to resolve the fork or not because (I think) I remember one of the devs saying there are situations where the client will just stop at a fork and need a trusted checkpoint. I don't think this situation is one of those cases though. I think that would happen only when the client cannot trust the longest chain metric to resolve a fork between two chains because the fork occurs due to the a majority of the same set of delegates double signing blocks. Some clarification from the devs would be appreciated here. Basically, because of Nothing-at-Stake, when the client is syncing after being offline for some time (past chain reorganization limits) it cannot always rely on longest chain since they can be tricked onto a fake chain forked off by 101 delegates that simultaneously existed at some point in the blockchain history (but are now presumably fired/retired).

I did think delegates could be voted out mid-round, but it looks like you're right on that unless I'm missing something.  I think this is a bug that should be corrected, and that a delegate should not be expected to confirm a block that revokes his active delegate status by voting him out of the top 101.

I would like clarification from the devs on what happens when a delegate, who has yet to produce their block for the round, is replaced due to the transactions included in a block within that round that comes before their block. Does the old delegate still produce the block in that round and then get fired in the next round? Does the delegate that replaced him take over? How do we even determine which delegate replaced the old delegate? Or do we just consider that block to be one that will be missed?
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 03, 2015, 04:40:00 am
See here: https://github.com/BitShares/bitshares/blob/master/libraries/blockchain/chain_database.cpp#L900
Title: Re: Consensus on the list of delegates
Post by: arhag on February 03, 2015, 04:55:36 am
See here: https://github.com/BitShares/bitshares/blob/master/libraries/blockchain/chain_database.cpp#L900

Yup, it appears to be like I originally assumed. Which means that when it is time for the fired delegate to sign the block, they have the option of doing so. Not sure whether the default client is set up to do it or not (probably does), but it is not like we can rely on that anyway since the delegate can just turn block production off as soon as they are fired. So the assumption should be that if in the very first block of a round all other 100 delegates lose rank in the top 101, then worst case there will be 100 missing blocks until the next round.

Of course my assumption was that the 1 honest delegate waits until they can produce a block in the last four blocks of a round so that they can avoid that 100 block starting disadvantage. The recovering mechanism I discussed in this post (https://bitsharestalk.org/index.php?topic=13921.msg181604#msg181604) should work fine with the way the delegate updating is done in the current code. I don't really think the code needs to be changed.

What is far more important is that blocks not have hard size limitations that make them invalid blocks if they exceed that size. That way all of the vote update transactions could be stuffed in the single honest delegate's block. Each transaction can still have a max size to prevent abuse.

Edit:
But if we do want to change the code to allow active delegates to be replaced mid-round (to make recovering from the attacks discussed in this thread more convenient for example), then I have a suggestion on how it could be done. So let's say the round begins with block N (where N % 101 == 1). Let's say the order of the delegates producing blocks in this round is (D1, D2, ..., D100, D101). After the first 4 blocks have been produced we are at block N+4 to be produced by delegate D5 and the remaining blocks in the round are to be produced by o=(D6, D7, ..., D100, D101) in that order as of now. Transactions included in block N+4 cause some of the delegates in the set of top 101 delegates to be replaced by another set of delegates of the same size. So let's pretend R={D2, D3, D6, D80, D101} are replaced by A={D102, D103, D104, D105, D106}. Also define a new set of safe delegates, S, which includes all of the delegates who have already produced blocks in this round as well as the delegate producing the current block and the next block (as determined by the current order). So in this case S={D1, D2, D3, D4, D5, D6}. The clients split the remaining delegate order sequence for the round into a head (h=D6) and the tail (tail = (D7, ..., D100, D101)). Take the set consisting of the delegates in tail as T. Define R' = R \ S, which in this example would be R'={D80, D101}. The cardinality of R' is the number of delegates that we can choose from A to create the set A', which is the set of delegate that need to replace the delegates in R' from the tail. Order the delegates in set A according to their approval (and in the case of ties, lexicographical ordering according to their account address), and pick the |R'| delegates with the highest approval from that list to form the set A'. In this example if we assume D102 and D104 have the highest approval rating compared to the rest in A, then A'={D102, D104}. Define T' = (T \ R') ∪ A', in this example T'={D7, D8, ..., D78, D79, D81, D82, ..., D99, D100, D102, D104}. Then create a new tail, tail', which is a sequence consisting of the elements in T' in some random order (use the current random seed as of block N+4 as the random value). I will mathematically represent this as tail' = permutation(T', get_current_random_seed()). Then prepend h to this new tail to get the sequence o' = h || tail' that defines the order of the delegates to produce the remaining blocks N+5 to N+100 (assuming no further changes to the set of active delegate). At the end of the round, the regular method for determining the new active delegates and their order is used (this way D103, D105, and D106 in this example get to be included in the following round). This procedure ensures that the next block producer remains the same even if the current block causes him to no longer be in the top 101 ranks (I think this is important for predictability and performance).

So with the above in place, the single honest delegate is in a better position for recovering from the attack from the other 100 evil delegates. No matter which block he starts the fork off from, the block disadvantage is going to be zero compared to the other evil chain. That means after the next round is complete (assuming they elect 101 new good delegates who don't miss their blocks), the good chain will become the longest chain (by just 1 block but then it will just grow from there). This means that the good chain can recover in at most 51 minutes after collecting all the valid (non-expired) transactions that vote out the 100 bad delegates and replace them with 100 good ones.
Title: Re: Consensus on the list of delegates
Post by: Ander on February 03, 2015, 07:18:48 am
Thanks arhag!


So, if a single good delegate can create his own chain and eventually cause it to be the longest chain and repair the network, what prevents a single attacker delegate from taking over?  Could the attacker delegate create extra false transactions which vote it additional attacker delegates, and take over that way?
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 08:01:20 am
How does NXT fix this 51% problem ?

Nxt doesn't have delegates. A briber have to pay to almost everyone.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 08:11:14 am
This means that the good chain can recover in at most 51 minutes after collecting all the valid (non-expired) transactions that vote out the 100 bad delegates and replace them with 100 good ones.

What if only 99 delegates will be voted-out on the honest chain? Or someone votes-out the honest delegate on the hostile chain? We'll get two chains of the same power => double-spending made for free.

Any game that allows a minority to win can be used for malicious things...
Title: Re: Consensus on the list of delegates
Post by: arhag on February 03, 2015, 10:00:39 am
So, if a single good delegate can create his own chain and eventually cause it to be the longest chain and repair the network, what prevents a single attacker delegate from taking over?  Could the attacker delegate create extra false transactions which vote it additional attacker delegates, and take over that way?

The single attacker delegate can only potentially make his fork the longest chain if he actually has enough stake in his control to vote in 101 new delegates. Without that his chain will be disregarded by everyone. So let's say the single attacker delegate was voted into rank 101 (currently require 8.23% approval). In order to replace delegates ranked 1 to 100 with his sockpuppet delegates he would need a higher percentage of stake than the approval of the delegate at rank 1 (currently 18.59%). But if the attacker already had 18.6% stake, he wouldn't need to trick people to vote for him into rank 101. He could have just voted in all 101 of his attack delegates at once. This is a traditional stake attack, not a delegate attack.

This means that the good chain can recover in at most 51 minutes after collecting all the valid (non-expired) transactions that vote out the 100 bad delegates and replace them with 100 good ones.

What if only 99 delegates will be voted-out on the honest chain? Or someone votes-out the honest delegate on the hostile chain?

I assumed that people will update their votes to make sure they can get all 100 evil delegates replaced by good ones so that the honest chain can take over. If they were only able to get 99 delegates replaced then the honest chain isn't able to win. Which means the voting stakeholders are stuck on the corrupted chain until enough stakeholders join them to push all 100 evil delegates out. Considering that the evil delegates are censoring transactions, eventually enough stakeholders should be motivated to take away any votes they have for the evil delegates and vote for good delegates for the purpose of returning chain operation back to normal.

I also assumed that the 100 delegate attackers do not control enough stake to replace the last remaining honest delegate (since that would be a stake attack and not an attack where they trick stakeholders into voting for the evil delegates or an attack where 100 delegates for some reason decide to collude to be evil). If they do not control enough stake they cannot vote the remaining honest delegate out of their chain (which gives them their 1 block per round disadvantage). If they do control enough stake to replace the last remaining delegate, then I view that as no different than the attack I described above when responding to Ander. Even if the last remaining honest delegate is at rank 101, they would still need to control 8.24% of all the BTS stake (currently) to fully take over the network (at least until stakeholders hard fork). It is difficult to obtain that much stake, especially when you realize that the stakeholders are likely to destroy, within the hard fork chain, any stake voting for the 101 evil delegates in the main chain. In that case, you can think of the attackers buying up 8.24% of BTS as giving a donation to the remaining 91.76% of stakeholders to compensate them for the burden of having to do a hard fork.

Finally, there is a chance that all 101 stakeholder-voted delegates spontaneously decide to collude together and become evil (or an attacker is able to convince stakeholders to vote all 101 of their sockpuppets into the top 101 ranks). In that case, they can take control of the network (at least until stakeholders hard fork) even without having any BTS stake. But the probability of this happening is incredibly low. And again, the way that the stakeholders recover is through the hard fork procedure (which I described here (https://bitsharestalk.org/index.php?topic=13921.msg181590#msg181590)).

We'll get two chains of the same power => double-spending made for free.

As I explained before, I believe (I appreciate if devs will confirm this) that the longest chain metric is only valid if the fork point is less than 16*101 blocks (roughly 4 hours) from the head block. I explained how even if there is one honest delegate it is possible for the good chain to become the longest chain (thus resolving the attack) before this reorganization limit is reached. What this means is that in these very rare scenarios of hostile delegate attacks in which the good chain is able to fight back against the attack after a few rounds, the transactions included as old as 4 hours ago will need to be moved over to the new (good) chain. So there is a potential for double spend to occur for those transactions specifically.

In these incredibly rare situations, someone who gave away goods/services less than 4 hours after confirming the transaction that paid them in the blockchain could be at risk of a double spend. Big deal. The risk is so incredibly low, plus you likely have other means (legal) of deterring an attacker from attempting this. If it is a really big transaction with no other deterrence available to protect from double spends (say a crypto/crypto exchange with an anonymous counterparty for a very large sum of money) it is probably best to design the transactions (escrow, atomic cross chain trades) so that either party can back out after 1 day, and to actually wait at least half a day before actually finalizing the transaction. But for regular transactions with merchants, it is a non-issue.

Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 01:10:17 pm
I assumed that people will update their votes to make sure they can get all 100 evil delegates replaced by good ones so that the honest chain can take over.

Now we need something to distinguish bad and good delegates.
Title: Re: Consensus on the list of delegates
Post by: arhag on February 03, 2015, 01:35:50 pm
I assumed that people will update their votes to make sure they can get all 100 evil delegates replaced by good ones so that the honest chain can take over.

Now we need something to distinguish bad and good delegates.

In the scenarios discussed in this thread, I define an "evil delegate" from the perspective of a stakeholder as a delegate who the stakeholder has noticed is not including valid transactions into the blockchain in a reasonable amount of time. Then, "good delegate" from the perspective of a stakeholder is a delegate that this stakeholder suspects will not be an "evil delegate".

If 100 of the current top 101 delegates are colluding to not include any transactions that take votes away from them and/or vote for delegates other than them, then eventually consensus will be reached by some collection of BTS stakeholders (the "Participating Stakeholders") that this set of delegates (the "Bad Delegates") include members that are each considered to be an "evil delegate". Once the collective BTS stake held by the "Participating Stakeholders" has reached a percentage of BTS greater than the approval rating of the delegate in the "Bad Delegates" with the highest approval rating, it becomes possible (assuming the stakeholders in the "Participating Stakeholders" group collectively can come to an agreement on the 100 "good delegates" that they vote on to replace the 100 "evil delegates")  for the last remaining delegate in the top 101 ranks that is not in the "Bad Delegates" (the "Single Honest Delegate") to initiate the process I described here (https://bitsharestalk.org/index.php?topic=13921.msg181604#msg181604) to recover from the attack. Even if the replacement process that "Participating Stakeholders" choose is as simple as to not vote for the "Bad Delegates" and vote for the next 100 delegates in the ranks that are known to have not been "evil delegates" in the past, then eventually (even if it takes a few iterations) all the delegates who will choose to become "evil delegates" will be exhausted leaving only delegates that do not choose to become "evil delegates", at the very least for a long period of time starting from when they get elected.
Title: Re: Consensus on the list of delegates
Post by: Gentso1 on February 03, 2015, 01:38:34 pm
I assumed that people will update their votes to make sure they can get all 100 evil delegates replaced by good ones so that the honest chain can take over.

Now we need something to distinguish bad and good delegates.
http://bitsharesblocks.com/delegates (http://bitsharesblocks.com/delegates)

This will at give you some basic information on the delegate.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 03, 2015, 01:38:53 pm
I assumed that people will update their votes to make sure they can get all 100 evil delegates replaced by good ones so that the honest chain can take over.

Now we need something to distinguish bad and good delegates.

The voters always have to distinguish between delegates who serve their interests and delegates who do not.  That's the whole point of voting.  This sort of scenario makes it pretty clear, as delegates excluding valid votes clearly do not serve the interests of the shareholders.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 01:44:52 pm
In the scenarios discussed in this thread, I define an "evil delegate" from the perspective of a stakeholder as a delegate who the stakeholder has noticed is not including valid transactions into the blockchain in a reasonable amount of time.

Other transactions may be prioritized and occupy all available space in blocks. Unconfirmed transactions can be lost in void. An eclipse attack may be conducted against one of the delegates... Rating grinding attack becomes much easier if you decide to distinguish delegates.
Title: Re: Consensus on the list of delegates
Post by: bytemaster on February 03, 2015, 03:23:05 pm
If the attacker cannot get 101 delegates in then his network will only be "half power" at 51% and will never be able to get to 100% power without buying the stake.
The honest minority will be able to include votes that can get honest delegates elected in.. if they can only get 10 more honest delegates in then it will be a 51% chain vs a 59% chain.
Lastly if it is clear there is an attack, and it would be, then it would be TRIVIAL to release a universally accepted hard fork that simply reset the vote on the offending delegates to 0.

Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 03:24:22 pm
People who accept bribes think there's a high likelihood they won't get caught.

The delegates don't know who they're screwing over in an attack but the shareholders would  know who the majority of them are.

Finding a large group of people willing to take this risk is almost completely implausible especially high trust individuals who are elected based on established reputations.

If majority accepted the bribe then you will earn nothing because your blocks will be ignored. Game theory tells that you will follow the majority as long as risk of being caught and voted-out is below some threshold. You don't know what threshold the others chose so you start observing if Bob included voting-out transactions. With non-zero probability Bob can be a honest delegate but he picks all non-voting-out transactions (pure random). What will you do? More likely you will think that Bob is rogue. There is a bias towards scenario when delegates decide to abuse the power. Sybil attack makes it less risky to go the bad route.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 03:27:39 pm
Lastly if it is clear there is an attack, and it would be, then it would be TRIVIAL to release a universally accepted hard fork that simply reset the vote on the offending delegates to 0.

How is it trivial?
Title: Re: Consensus on the list of delegates
Post by: Empirical1.2 on February 03, 2015, 03:54:39 pm
People who accept bribes think there's a high likelihood they won't get caught.

The delegates don't know who they're screwing over in an attack but the shareholders would  know who the majority of them are.

Finding a large group of people willing to take this risk is almost completely implausible especially high trust individuals who are elected based on established reputations.

If majority accepted the bribe then you will earn nothing because your blocks will be ignored. Game theory tells that you will follow the majority as long as risk of being caught and voted-out is below some threshold. You don't know what threshold the others chose so you start observing if Bob included voting-out transactions. With non-zero probability Bob can be a honest delegate but he picks all non-voting-out transactions (pure random). What will you do? More likely you will think that Bob is rogue. There is a bias towards scenario when delegates decide to abuse the power. Sybil attack makes it less risky to go the bad route.

I deleted the post as I don't actually know how it works in practice in terms of detection but if it is possible to discern who was involved in the attack, my point was not only do they risk being voted out but there's an additional personal safety/health risk associated with deliberately messing with other people's money if you are publicly known.

High trust, high reputation individuals are unlikely to be bribeable en masse. It would have to be massive to offset loss of future earnings potential and destruction of personal reputation + you have the additional risk of retribution if you can be detected.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 03, 2015, 03:55:56 pm
Lastly if it is clear there is an attack, and it would be, then it would be TRIVIAL to release a universally accepted hard fork that simply reset the vote on the offending delegates to 0.

How is it trivial?
In context of such an incredibly unlikely situation in which all of the delegates have been hijacked and are persistently rejecting being voted out, such a fork would be an easy and verifiable code change.  In such a situation, I doubt the users would resist accepting the fork as an easy way to end the network disruption.

This whole thread has been focused on the implausible scenario in which most delegates are compromised. Exploring handling for such extreme cases is healthy, but it's important to keep the probability context in mind.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 04:14:28 pm
This whole thread has been focused on the implausible scenario in which most delegates are compromised. Exploring handling for such extreme cases is healthy, but it's important to keep the probability context in mind.

Actually the thread was derailed with bribery example. The point was supposed to be - if delegates control the only medium of exchange then this channel cannot be used for sending information that affect the delegates.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 03, 2015, 04:15:56 pm
This whole thread has been focused on the implausible scenario in which most delegates are compromised. Exploring handling for such extreme cases is healthy, but it's important to keep the probability context in mind.

Actually the thread was derailed with bribery example. The point was supposed to be - if delegates control the only medium of exchange then this channel cannot be used for sending information that affect the delegates.
That would be true if there was only one delegate.

EDIT: Also nice to confirm that your original purpose here was to attack the system, not to understand it as you said in your OP. :-P
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 04:21:58 pm
That would be true if there was only one delegate.

The proof of this statement is not presented in DPoS whitepaper, hence it's better (for security) to assume the opposite.
Title: Re: Consensus on the list of delegates
Post by: fluxer555 on February 03, 2015, 04:24:18 pm
Thank you Come-from-Beyond, for helping us harden our security model, and harden our theories backing up our current system.
Title: Re: Consensus on the list of delegates
Post by: Troglodactyl on February 03, 2015, 04:29:11 pm
Thank you Come-from-Beyond, for helping us harden our security model, and harden our theories backing up our current system.
+1
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 04:30:45 pm
Thank you Come-from-Beyond, for helping us harden our security model, and harden our theories backing up our current system.

It's more about whitepaper now. :)

I see that the whitepaper lacks the following:
1. Protocol that allows to detect hostile delegates (with some quantitative analysis on probabilities of detection).
2. Protocol how hard-fork is handled.

This is a serious obstacle to world domination because the outer world doesn't know what to do in extraordinary cases. It will not figure out the details by itself and will simply pick another cryptocurrency.
Title: Re: Consensus on the list of delegates
Post by: Empirical1.2 on February 03, 2015, 05:04:58 pm
If Bitcoin had a 101 delegate system how much would you have to bribe an Andreas Antonopolous or an Amir Taaki delegate to sabotage Bitcoin?

What about someone like Max Keiser who might choose to be a delegate for personal reasons despite having a net worth of $X million +?

If you were elected a delegate in NXT, would it be easy to bribe you?

Does game theory account for people that can't be bought?
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 05:25:41 pm
Does game theory account for people that can't be bought?

Dunno, I'm not an expert. But a cryptocurrency can't rely on trust.
Title: Re: Consensus on the list of delegates
Post by: donkeypong on February 03, 2015, 05:49:12 pm
Basically, it's possible for any election on the planet earth to be "bought" in one way or another. So you're saying that elections are always suspect? That BitShares delegates will care more about a potential small bribe than about their longer term financial interest and fiduciary duty to act in the best interests of BitShares? I certainly don't see this as a solid possibility.

Modern election systems are more secure because the branch of the state that supervises election process is not controlled by another branch which is being elected.

With DPoS, I think that we are beyond this.

The Separation of Powers into multiple branches has served an important function, basically to ensure that no one person or group has total control. There is a functional aspect to this also, because each branch is handling different work (e.g. legislative branch as lawmaker, executive as day-to-day operator and enforcer, and judiciary as arbiter of disputes). And in a modern parliamentary system, many of these functions are fused together anyway. But in a trustless DAC community, a lot of these typical functions are moot.

BitShares delegates are elected independently. There is no traditional election cycle, so they can be voted out at any point if they abuse the community's trust. Each of them handles differing functions, depending on their utility, in addition to their core function of verifying blocks. So one could say that it's a single-branched system, but really it is a decentralized (101-branched) structure where no one delegate must answer to any other. The notion of a conspiracy of bribery between a majority of delegates is as far-fetched as a conspiracy between multiple branches of a traditional government. One could just as easily buy of a majority of a nation's legislature and of its highest court in order for them to agree with the executive 100% of the time.
Title: Re: Consensus on the list of delegates
Post by: gamey on February 03, 2015, 06:30:20 pm
How does NXT fix this 51% problem ?

Nxt doesn't have delegates. A briber have to pay to almost everyone.

There are those forging pools or whatever NXT calls them.  So we  realize you don't call them Delegates, but what happens if 51%+ of them are malicious and ignore the blocks of the minority?  Can the rest of the network recover?
Title: Re: Consensus on the list of delegates
Post by: gamey on February 03, 2015, 06:37:16 pm
Does game theory account for people that can't be bought?

No, but game theory is constantly misapplied now that the concept has become mainstream and perhaps taught to some degree in numerous undergrad classes.
Title: Re: Consensus on the list of delegates
Post by: Stan on February 03, 2015, 06:39:04 pm
Basically, it's possible for any election on the planet earth to be "bought" in one way or another. So you're saying that elections are always suspect? That BitShares delegates will care more about a potential small bribe than about their longer term financial interest and fiduciary duty to act in the best interests of BitShares? I certainly don't see this as a solid possibility.

Modern election systems are more secure because the branch of the state that supervises election process is not controlled by another branch which is being elected.

With DPoS, I think that we are beyond this.

The Separation of Powers into multiple branches has served an important function, basically to ensure that no one person or group has total control. There is a functional aspect to this also, because each branch is handling different work (e.g. legislative branch as lawmaker, executive as day-to-day operator and enforcer, and judiciary as arbiter of disputes). And in a modern parliamentary system, many of these functions are fused together anyway. But in a trustless DAC community, a lot of these typical functions are moot.

BitShares delegates are elected independently. There is no traditional election cycle, so they can be voted out at any point if they abuse the community's trust. Each of them handles differing functions, depending on their utility, in addition to their core function of verifying blocks. So one could say that it's a single-branched system, but really it is a decentralized (101-branched) structure where no one delegate must answer to any other. The notion of a conspiracy of bribery between a majority of delegates is as far-fetched as a conspiracy between multiple branches of a traditional government. One could just as easily buy of a majority of a nation's legislature and of its highest court in order for them to agree with the executive 100% of the time.

And, unlike those branches of human government, delegates have limited power and misbehavior can be detected.  Further, if a corrupt government somehow emerged, it would immediately be competing against an honest fork of itself. 

(This is where the expression "go fork yourself" comes from.)

Then market forces would drive the dishonest branch out of business. 
If not, then the market approves of the new branch and gets what it demands.
Title: Re: Consensus on the list of delegates
Post by: Ander on February 03, 2015, 07:05:37 pm
Does game theory account for people that can't be bought?

No, but game theory is constantly misapplied now that the concept has become mainstream and perhaps taught to some degree in numerous undergrad classes.

Game theory can account for this, it just has to place a large amount of utility for those people on not defecting, due to their desire for reputation or ideals.   You need to build an accurate payoff matrix in order for game theory to tell you the correct outcome, and for most Bitshares delegates they probably place a lot more utility on their reputation and future potential gain from being a delegate than they do for the bribe money. 
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 07:09:05 pm
There are those forging pools or whatever NXT calls them.  So we  realize you don't call them Delegates, but what happens if 51%+ of them are malicious and ignore the blocks of the minority?  Can the rest of the network recover?

Max period for delegation of power is 32767 blocks.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 07:10:39 pm
...misbehavior can be detected.

How?
Title: Re: Consensus on the list of delegates
Post by: clout on February 03, 2015, 07:14:23 pm
...misbehavior can be detected.

How?

Its a block chain. Everything is public
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 07:20:41 pm
Its a block chain. Everything is public

I mean what protocol should I follow to detect misbehavior.
Title: Re: Consensus on the list of delegates
Post by: bytemaster on February 03, 2015, 07:40:45 pm
Its a block chain. Everything is public

I mean what protocol should I follow to detect misbehavior.

You would run a node that gathered statistics about transactions that are delayed in their inclusion from the time they were received.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 07:50:37 pm
You would run a node that gathered statistics about transactions that are delayed in their inclusion from the time they were received.

So 1000 people with 25% total stake notice that their transactions are not confirmed for a long time. Votes of these people are enough to replace 51 delegates. How will they notify the others that something went wrong?
Title: Re: Consensus on the list of delegates
Post by: xeroc on February 03, 2015, 08:08:34 pm
You would run a node that gathered statistics about transactions that are delayed in their inclusion from the time they were received.

So 1000 people with 25% total stake notice that their transactions are not confirmed for a long time. Votes of these people are enough to replace 51 delegates. How will they notify the others that something went wrong?
The same way you inform others that GHash is doublespending on a gambling site ... you make a post in the community, news, forums ....
Title: Re: Consensus on the list of delegates
Post by: gamey on February 03, 2015, 08:34:05 pm
Does game theory account for people that can't be bought?

No, but game theory is constantly misapplied now that the concept has become mainstream and perhaps taught to some degree in numerous undergrad classes.

Game theory can account for this, it just has to place a large amount of utility for those people on not defecting, due to their desire for reputation or ideals.   You need to build an accurate payoff matrix in order for game theory to tell you the correct outcome, and for most Bitshares delegates they probably place a lot more utility on their reputation and future potential gain from being a delegate than they do for the bribe money.

Sure, but when you say 'game-theory dictates ' to come to a conclusion which largely ignores very difficult to measure values which have just as much importance, then 'game-theory dictates' is being misapplied or simply incorrect. It often becomes an argument from authority which people use to support their view.
Title: Re: Consensus on the list of delegates
Post by: Come-from-Beyond on February 03, 2015, 09:23:35 pm
The same way you inform others that GHash is doublespending on a gambling site ... you make a post in the community, news, forums ....

We can't make shareholders re-vote, why can we make them read the forum? Also, what should be used as a proof of the words?
Title: Re: Consensus on the list of delegates
Post by: donkeypong on February 04, 2015, 12:13:55 am
The same way you inform others that GHash is doublespending on a gambling site ... you make a post in the community, news, forums ....

We can't make shareholders re-vote, why can we make them read the forum? Also, what should be used as a proof of the words?

As we grow, we'll have more ways to 'get the word out' and collect information on delegates for use by the commuity. So far, the forum and Mumble sessions have been enough.
Title: Re: Consensus on the list of delegates
Post by: jsidhu on February 04, 2015, 04:46:13 am
Maybe the email system can come to use here
Title: Re: Consensus on the list of delegates
Post by: Tobo on April 09, 2015, 06:58:25 pm
So 1000 people with 25% total stake notice that their transactions are not confirmed for a long time. Votes of these people are enough to replace 51 delegates. How will they notify the others that something went wrong?

The same concern has been shared by Vitalik - https://www.zapchain.com/a/FRsI5InA2e
Quote
DPOS: not too comfortable with people voting honestly as a security assumption (as I recall, there was an empirical result that showed that due to the mass of people non-voting you only need ~8% of stake to perform a "51% attack"), would prefer it used a more standard BFT algo between the delegates, but otherwise makes sense.
Title: Re: Consensus on the list of delegates
Post by: fuzzy on April 09, 2015, 08:03:35 pm
So 1000 people with 25% total stake notice that their transactions are not confirmed for a long time. Votes of these people are enough to replace 51 delegates. How will they notify the others that something went wrong?

The same concern has been shared by Vitalik - https://www.zapchain.com/a/FRsI5InA2e
Quote
DPOS: not too comfortable with people voting honestly as a security assumption (as I recall, there was an empirical result that showed that due to the mass of people non-voting you only need ~8% of stake to perform a "51% attack"), would prefer it used a more standard BFT algo between the delegates, but otherwise makes sense.

Except a 51% attack can only basically be used to collectively cease signing blocks. That means that it will be an expensive and likely ineffective attack in the medium to long run.