public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Filipe Farinha <filipe@ktorn.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Mempool size consensus + dynamic block size re-targetting
Date: Wed, 24 Jun 2015 10:02:51 +0800	[thread overview]
Message-ID: <558A0FCB.2040908@ktorn.com> (raw)

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


             reply	other threads:[~2015-06-24  2:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-24  2:02 Filipe Farinha [this message]
2015-06-24  2:15 ` [bitcoin-dev] Mempool size consensus + dynamic block size re-targetting Mark Friedenbach
2015-06-24  2:24   ` Filipe Farinha
2015-06-24  2:43     ` Peter Todd
2015-06-24  3:02       ` Filipe Farinha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=558A0FCB.2040908@ktorn.com \
    --to=filipe@ktorn.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox