maaku
commented
5 years ago A couple of fixes from the prior version, which I force-pushed since it hadn't been reviewed. Mostly changes to make a couple of assert calls into return false / return NULL so as to not unnecessarily crash the client and provide better feedback in erroneous situations.
I'm still undecided as to whether to accept the last output being an OP_RETURN data output. I'm going to run the numbers and see if that's a real efficiency gain with our anticipated use cases.
The testing code still needs to be written.
This series of patches adds "block-final transactions", which are a sort of second coinbase transaction generated by the miner, after all other transactions in a block, and a BIP9 soft-fork deployment mechanism for these features.
Having a block-final transaction under miner control allows the miner to collect certain anyone-can-spend outputs from within the block itself, return some of this value to the coinbase as fee, and to carry forward consensus-meaningful locked fund balances from block to block. It also provides a convenient location for consensus commitments that have value for lightweight nodes, as a proof of the block-final transaction is shorter for non-balanced Merkle trees. The last output of the last transaction is where the segwit commitment will go, where merged mining and the forward block shard commitments will go, and where non-consensus commitments like share chains will go. When forward blocks is deployed, it can become a consensus rule that the compatibility block contains 2^n+1 total transactions (2^n-1 user transactions), which makes the path to block-final commitments only a single 32-byte hash (the sub-tree of 2^n prior transactions) plus a midstate skipping to the end of the block-final transaction.
Miner coordination is required to deploy these features because the miner needs an output to spend in order to create a valid block-final transaction, since a transaction can't be without inputs, so coinbase of the first block upon activation has an anyone-can-spend output that starts the chain of block-final transactions. The first block-final transaction is
COINBASE_MATURITYblocks later, and spends this output. It is a consensus rule that each block-final transaction contains at least one anyone-can-spend output of a certain form, and that all such outputs are spent by the block-final transaction of the next block.TODO:
One area of review that can use some focus is interaction with the mempool. It is critical that the mempool never contain a transaction spending a block-final txout, and that this remain true even in the case of block reorgs