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

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

[Filipe Farinha]

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

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

[Mark Friedenbach]

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

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

[Filipe Farinha]

On 24/06/2015 10:15, Mark Friedenbach wrote:
>
> Anyone could lie.
>
True.
What would be the incentive for the majority of transaction broadcasting 
full-nodes to lie about the mempool size?

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

[Peter Todd]

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

On Wed, Jun 24, 2015 at 10:24:03AM +0800, Filipe Farinha wrote:
> On 24/06/2015 10:15, Mark Friedenbach wrote:
> >
> >Anyone could lie.
> >
> True.
> What would be the incentive for the majority of transaction
> broadcasting full-nodes to lie about the mempool size?

It might help you to answer the following: If your mempool consensus
idea worked, could you use it to replace proof-of-work? Why? Why not?

-- 
'peter'[:-1]@petertodd.org
00000000000000001256cc4d7dc7b68be627cbbf65f2b7827fb3e2cc41cf2517

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Filipe Farinha]

On 24/06/2015 10:43, Peter Todd wrote:
> It might help you to answer the following: If your mempool consensus 
> idea worked, could you use it to replace proof-of-work? Why? Why not? 
I shouldn't have to answer that, but the answer is clearly no.

Please consider this argument when evaluating the pros and cons of BIP 100.

Filipe Farinha