A concern brought up in the context of block content diverging from the default mempool policy is the reduced compact block reconstruction rates. In this context, I have seen the extra pool brought up. A frequent claim is that a sufficiently large extra pool would hold most of the missing transactions and therefore mitigate the hit to the block reconstruction from the node not having a large portion of the block content.
An example for such a claim can be seen in an answer to Implications of OP_RETURN changes in upcoming Bitcoin Core version 30.0:
- Compact Block relay latency: There is certainly a way to keep transactions in memory and not relay them.
blockreconstructionextratxn
is a config that already implements this with a default of 100 txs,
users/small-miners can increase that value as needed if it’s a
concern. In fact, Bitcoin Knots 29.1 ships with a much higher default
and also adds additional config calledblockreconstructionextratxnsize
which can be used to do same but by allocating memory size instead of
just number of transactions.
How effective would we expect the extra pool to be at facilitating fast block reconstruction in the context of a node operating with mempool policies that filter 20–40% of transactions appearing in blocks?
