MIME-Version: 1.0
In-Reply-To: <558A0FCB.2040908@ktorn.com>
References: <558A0FCB.2040908@ktorn.com>
Date: Tue, 23 Jun 2015 19:15:55 -0700
Message-ID: <CAOG=w-vj8LQjun0u03nWRz1RV7NMw=ALdQkbiQcrOb=cpfWZZg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Filipe Farinha <filipe@ktorn.com>
Content-Type: multipart/alternative; boundary=001a113f0c5a48012905193a1618
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Mempool size consensus + dynamic block size
	re-targetting
Precedence: list

--001a113f0c5a48012905193a1618
Content-Type: text/plain; charset=UTF-8

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
>

--001a113f0c5a48012905193a1618
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Anyone could lie.</p>
<div class=3D"gmail_quote">On Jun 23, 2015 7:12 PM, &quot;Filipe Farinha&qu=
ot; &lt;<a href=3D"mailto:filipe@ktorn.com">filipe@ktorn.com</a>&gt; wrote:=
<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To my knowledge so =
far the main proposals regarding block size changes are either based on pre=
dictions, which traditionally we&#39;re not very good at, or a voting mecha=
nism by a limited set of stakeholders (miners) whose interests may not be a=
ligned with the rest of the community.<br>
<br>
Neither strategy takes into account the most important factor: real-time ch=
anges to the mempool. This is for a valid reason, there is currently no con=
sensus on the size of the mempool.<br>
<br>
So my question is: has anyone considered the pros and cons of creating cons=
ensus around the current (approximate) mempool size?<br>
<br>
I propose that, at the expense of some transaction overhead (3 or 4 extra b=
ytes?), 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 head=
er), all nodes can quickly reach consensus on the current average/median/et=
c mempool size, and agree on a suitable periodic blocksize &quot;re-targett=
ing&quot; (similarly to mining difficulty).<br>
<br>
Since all full-nodes (not just miners) get to vote with their transactions =
the consensus is truly global, and we don&#39;t have to change blocksize bl=
indly in anticipation of an unpredictable future.<br>
<br>
Would this not work, and if not, why?<br>
<br>
Filipe Farinha<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--001a113f0c5a48012905193a1618--