Re: [bitcoin-dev] Mempool size consensus + dynamic block size re-targetting

[Mark Friedenbach <mark@friedenbach.org>]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

Anyone could lie.
On Jun 23, 2015 7:12 PM, "Filipe Farinha" <filipe@ktorn.com> wrote:

> 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
>

[-- Attachment #2: Type: text/html, Size: 2121 bytes --]