Anyone could lie.
To my knowledge so far the main proposals regarding block size changes are either based on predictions, which traditionally we're not very good at, or a voting mechanism by a limited set of stakeholders (miners) whose interests may not be aligned with the rest of the community.
Neither strategy takes into account the most important factor: real-time changes to the mempool. This is for a valid reason, there is currently no consensus on the size of the mempool.
So my question is: has anyone considered the pros and cons of creating consensus around the current (approximate) mempool size?
I propose that, at the expense of some transaction overhead (3 or 4 extra bytes?), each full-node that broadcasts a new transaction can add a mempool_size field that represents their current view of the mempool. As blocks are mined with this new data (which may or not be aggregated in the block header), all nodes can quickly reach consensus on the current average/median/etc mempool size, and agree on a suitable periodic blocksize "re-targetting" (similarly to mining difficulty).
Since all full-nodes (not just miners) get to vote with their transactions the consensus is truly global, and we don't have to change blocksize blindly in anticipation of an unpredictable future.
Would this not work, and if not, why?
Filipe Farinha
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev