Definitions

...

•  Medha Parlikar (Unlicensed): region is full - will we have maximums on validator counts?  - No, we will let economics handle that piece.  Validators will go where the money is.

Unbonding

Unbonding is triggered when the PoS contract is invoked (again in the normal way) with the signature of an existing validator along with a return channel. On the return channel, an unforgeable name is sent, which the now ex-validator can listen on. After the post-unbonding stake holding time has elapsed, a purse containing the ex-validaor's stake is sent on that name, thus allowing the validator to recover their bond. The unbonding is successful so long as it does not exceed the unbonding rate specified for the region.

• The the post-unbonding wait time can be set by the region, but the protocol should define a minimum, to prevent a shard from reducing security by allowing validators to unbond too quickly. 
• The maximum unbonding rate (N validators per 100 blocks) can be set within the region. 
• The validator remains on the list of validators until the post-unbonding period has elapsed.
• When an unbonding request comes into the contract, rewards are paid out to the bonded validators.  The validator that is unbonding has their rewards added to their bond purse only.  This is to prevent cheating in the event transaction fees exceed the bond amount forfeited.

•  Medha Parlikar (Unlicensed): If validator limits for a given shard do not exist, then the queue becomes a moot point.  The decision on validator limits has not been made yet.

Unbonding Wait Period

During this time the validator is not active.  The validator cannot propose blocks, nor receive rewards.  The stake is held by the PoS contract, and the validator can be slashed by other validators.  The other validators are not aware that the validator has requested to unbond.  The unbonding request is held by the PoS contract in the shard.   Note that no rewards are distributed at this time, only the exact original stake (minus any slashed amount) is returned. Unpaid rewards can be withdrawn from the shard's local PoS contract after unbonding has occurred (see below). 

The purpose of this wait time is to prevent a variant of the "long range attack" (reference Details of Proof-of-Stake in RChain )

...

• For invalid blocks that are missing any required fields. Note a block must contain at least a sender and a valid signature from that sender in order to be considered a block. This is 1 block.
• For blocks that have parents that don't lead back to a block in the blockDAG, show the justification chains up until at least X blocks including the block in question. Note that this should only be done after catching up to around the latest block. It is at least X blocks instead of exactly X because you want to make sure that other validators can reproduce seeing X blocks that don't lead back to something in the blockDAG. This can be any amount greater than X+1 blocks.
• For blocks that have hashes that aren't the same as the computed hashes. This includes the block hash, the parents hash list, the post state hash, the new code hash, and the transaction receipt logs hash. This is 1 block.
• For blocks with an invalid block number, show the parent block and the block in question. This is 2 blocks.
• For blocks with an invalid sequence number, show the creator justification block and the block in question. This is 2 blocks.
• For blocks that don't point to as many justifications blocks as there are bonded validatorshave bonded validators field reflecting the bonded validators in the proof of stake contract (including validating that the bonded stake is above a certain minimum threshold), show that invalid block. This is 1 block.
• For blocks that don't have a parent that matches the derived parent based on the estimator, show all the justification blocks and the block in question. This is one more than the number of validators.
• For blocks that contain invalid transactions/deployments (including invalid slashing transactions that are valid from the Rholang interpreter's standpoint), show that invalid block. This is 1 block.
• For block(s) in the chain that have the same (user, millisecond timestamp) transaction, show the invalid block(s) that contain those transactions. This is at least 2 blocks.
• For blocks that contain justifications that lead to invalid blocks but don't slash their creator, show the justification chain that leads to that invalid block including the invalid block itself. This is at least 2 blocks.
• For blocks that contain justifications that lead to knowledge of a equivocation but don't slash the equivocator, show the justification chain(s) that lead to three blocks that are enough to minimally prove the equivocation. This is at least 4 blocks.
• For equivocations, show the base equivocation block and the two that have sequence numbers that follow. This is 3 blocks.

...

•  Medha Parlikar (Unlicensed): Determine what the invalid blocks look like, and how these invalid blocks are generated.  

Rewards Distribution

Rewards distribution is handled by a local PoS contract. Fees will accrue within the PoS contract or a purse controlled by the PoS contract.  At a random interval, the PoS contract will divide the fees by the number of validators in the shard and distributes the fees to the validator set. 

Rewards will accrue until the validator withdraws their rewards. 

...