Quote from: DrGrid on January 20, 2015, 11:13:04 PM

I think I am starting to understand the concept now thanks to the graphics, explanation and further discussion. If this system really would host a larger majority of good actors this sounds like it could work really well. However, when we are looking at a possible large minority of bad actors, the conflict resolution seems somewhat slow. Bitcoin was made to attack proof until really the network is being compromised, but instead sacrificed on scalability. To me this system looks like it has full scalability, but lacks efficient protection and quick solution against an all out attack.
Could you expand on how you envision stake being counted into solving the consensus problem?

I'll list some of my thoughts and feel free to ask or suggest if you want more detail in another area.

With Bitcoin, forks and rollbacks are a moderately common occurrence due to race conditions of multiple miners finding a solution or transactions being publish near a block solution boundary. Unfortunately this rollback affects everyone during the block interval to some degree though it's mitigated. With RaiBlocks there aren't these race conditions so need for agreements due to benign situations is eliminated.

There only time an agreement is ever needed is when there is a definite malicious actor. This opens up some policy decisions where we can treat accounts with forks as second-class citizens and accounts without forks with priority and be sure we're not accidentally penalizing good people.

The exact stake counting algorithm is as follows:
* A published block arrives from the network, is checked for validity on the signature, balance delta etc.
   * If block was not rejected for invalidity
   * If we're not a representative, publish the block to everyone we're aware of without our signature.
   * Else if we're representative, sign a vote from our representative account including the block we're voting for and broadcast to everyone we know.
   * Else if the block was rejected for a definitive reason, bad signature, account balance is invalid e.g. greater, or we don't have the previous block in our ledger at all, drop the block and do nothing
   * Else if the block was rejected for a non-definitive reason i.e. some other block in the ledger already claimed this "previous" block meaning this is a fork signed by the account owner
   * If we're not a representative, wait and listen for votes and rollback and replace our block if some other block receives a majority tally
   * Else if we are a representative
   * Loop until one block has >95% of the vote tally and the total tallied vote weight > 95% of total supply
   * Tally the votes we have, if the winning block is different than our block, rollback and replace our block with the winner
   * Increase our vote sequence count and rebroadcast our view of the winning block
   * Wait a time period before doing another voting round

For receivers the algorithm is extended a little:
* A valid published send block is received that names an account we have signing keys for as the recipient.
* Start tallying votes and wait a couple network propagation periods.
* Every time a publish from a non-representative or a vote from a representative arrives, add it to the tally
* After our wait time has expired:
   * If no conflicts have been observed i.e. no one anywhere has published a conflicting block, receive the send in to our chain
   * Else if there's a conflict, wait until the tally is > 95% in favor of our block before accepting or do not accept if the block is rejected by votes

From this algorithm flow we can see that if no fork is observed only the receiver will tally votes. We can also see that non-representative don't sign votes or run a voting loop. Since everyone who inserts a block in to their local ledger rebroadcasts it to everyone they know, we can be sure blocks will be propagated quickly. If a receiver waits a couple propagation periods and receives no conflicting block broadcast, they can be sure if a conflict ever is broadcast, it will be quickly rejected because all the representatives have already made their decision and nodes only change their block if a majority says otherwise but we've already settled 100% one way.