Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-23 📝 Original message:Anyone could lie. On Jun ...

📅 Original date posted:2015-06-23
📝 Original message:Anyone could lie.
On Jun 23, 2015 7:12 PM, "Filipe Farinha" <filipe at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150623/819e7bde/attachment-0001.html>;