Block Validation

The following validation rule has been added in the Common Goods Pool Update:

• The coinbase transaction may now contain an output with a contract lock, along with the usual coinbase output.

• To be sure that the CGP contract can always be executed we increase the upper limit of the block weight.

Block Rewards

The previous implementation invalidates a coinbase transaction if it locks an output to anything besides the Coinbase lock.

We relax this restriction and consider a coinbase transaction valid if its outputs are locked to either a Coinbase lock or a Contract lock.

Whereas currently there is a fixed amount paid entirely to the miner who mines a block (using a Coinbase lock), this proposal would allow users to accept a block as valid only if the correct amount of ZP is locked to the CGP contract.

It will be possible to vote during a voting interval for a particular distribution of the block reward between the miner and the CGP.

The distribution of the block reward between the miner and CGP in a particular block will be determined by the vote in the previous voting interval.

The allocation winner resulting from votes in a particular voting interval will be the weighted median of votes for the allocation in that voting interval.

There will be a limit as to the largest possible percentage change in block reward distribution resulting from a vote in a single voting interval.

This proposal sets the bounds to the largest possible percentage change in the block reward distribution (% to miner's income) resulting from a vote in a single voting interval at 15%.

The winning allocation % comes into effect 100 blocks (the size of the coinbase maturity) after the voting interval finishes.

Connection

When extending the local blockchain we check:

1. The correct distribution of the block reward + fees, according to the allocations declared by the allocation tally winner.

2. The contract lock output is locked to the CGP contract, and the amount matches the payout tally winner.

The CGP contract must be executed one block before and added to the payout block.

For the payout block - the node checks that the following conditions hold:

1. If there is a payout winner for the tally of the previous interval - there must also be a payout in the payout block after that interval.

2. There is at most one payout transaction per payout block.

3. The payout transaction matches the payout winner of the tally.