Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.169 as permitted sender)
	client-ip=209.85.223.169; envelope-from=clem.ds@gmail.com;
	helo=mail-ie0-f169.google.com; 
MIME-Version: 1.0
References: <16096345.A1MpJQQkRW@crushinator>
In-Reply-To: <16096345.A1MpJQQkRW@crushinator>
From: =?UTF-8?Q?Cl=C3=A9ment_Elbaz?= <clem.ds@gmail.com>
Date: Fri, 08 May 2015 10:30:22 +0000
Message-ID: <CAP63atbdFSw0rDeuwgtjsDYsXnKSHNN9=zedzip2MsZ0hSY59w@mail.gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>,
	bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=20cf303ea102062fb405158f84c7
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
Precedence: list

--20cf303ea102062fb405158f84c7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my
favorite.

I see two problems with proposal #2.
The first problem with proposal #2 is that, as we see in democracies,
there is often a mismatch between the people conscious vote and these same
people behavior.

Relying on an  intentional vote made consciously by miners by choosing a
configuration value can lead to twisted results if their actual behavior
doesn't correlate with their vote (eg, they all vote for a small block size
because it is the default configuration of their software, and then they
fill it completely all the time and everything crashes).

The second problem with proposal #2 is that if Gavin and Mike are right,
there is simply no time to gather a meaningful amount of votes over the
coinbases, after the fork but before the Bitcoin scalability crash.

I like proposal #1 because the "vote" is made using already available data.
Also there is no possible mismatch between behavior and vote. As a miner
you vote by choosing to create a big (or small) block, and your actions
reflect your vote. It is simple and straightforward.

My feelings on proposal #3 is it is a little bit mixing apples and oranges,
but I may not seeing all the implications.

Le ven. 8 mai 2015 =C3=A0 09:21, Matt Whitlock <bip@mattwhitlock.name> a =
=C3=A9crit :

> Between all the flames on this list, several ideas were raised that did
> not get much attention. I hereby resubmit these ideas for consideration a=
nd
> discussion.
>
> - Perhaps the hard block size limit should be a function of the actual
> block sizes over some trailing sampling period. For example, take the
> median block size among the most recent 2016 blocks and multiply it by 1.=
5.
> This allows Bitcoin to scale up gradually and organically, rather than
> having human beings guessing at what is an appropriate limit.
>
> - Perhaps the hard block size limit should be determined by a vote of the
> miners. Each miner could embed a desired block size limit in the coinbase
> transactions of the blocks it publishes. The effective hard block size
> limit would be that size having the greatest number of votes within a
> sliding window of most recent blocks.
>
> - Perhaps the hard block size limit should be a function of block-chain
> length, so that it can scale up smoothly rather than jumping immediately =
to
> 20 MB. This function could be linear (anticipating a breakdown of Moore's
> Law) or quadratic.
>
> I would be in support of any of the above, but I do not support Mike
> Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the
> road without actually solving the problem, and it does so in a
> controversial (step function) way.
>
>
> -------------------------------------------------------------------------=
-----
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

<div dir=3D"ltr"><div><div><div>Matt : I think proposal #1 and #3 are a lot=
 better than #2, and #1 is my favorite.<br><br></div><div>I see two problem=
s with proposal #2.<br></div>The first problem with proposal #2 is that, as=
 we see in democracies,=C2=A0 there is often a mismatch between the people =
conscious vote and these same people behavior. <br><br>Relying on an=C2=A0 =
intentional vote made consciously by miners by choosing a configuration val=
ue can lead to twisted results if their actual behavior doesn&#39;t correla=
te with their vote (eg, they all vote for a small block size because it is =
the default configuration of their software, and then they fill it complete=
ly all the time and everything crashes).<br><br></div><div>The second probl=
em with proposal #2 is that if Gavin and Mike are right, there is simply no=
 time to gather a meaningful amount of votes over the coinbases, after the =
fork but before the Bitcoin scalability crash. <br></div><div><br></div>I l=
ike proposal #1 because the &quot;vote&quot; is made using already availabl=
e data. Also there is no possible mismatch between behavior and vote. As a =
miner you vote by choosing to create a big (or small) block, and your actio=
ns reflect your vote. It is simple and straightforward.<br><br></div>My fee=
lings on proposal #3 is it is a little bit mixing apples and oranges, but I=
 may not seeing all the implications.<br><div><div><div><div><div><br><div =
class=3D"gmail_quote">Le=C2=A0ven. 8 mai 2015 =C3=A0=C2=A009:21, Matt Whitl=
ock &lt;<a href=3D"mailto:bip@mattwhitlock.name">bip@mattwhitlock.name</a>&=
gt; a =C3=A9crit=C2=A0:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Between all the f=
lames on this list, several ideas were raised that did not get much attenti=
on. I hereby resubmit these ideas for consideration and discussion.<br>
<br>
- Perhaps the hard block size limit should be a function of the actual bloc=
k sizes over some trailing sampling period. For example, take the median bl=
ock size among the most recent 2016 blocks and multiply it by 1.5. This all=
ows Bitcoin to scale up gradually and organically, rather than having human=
 beings guessing at what is an appropriate limit.<br>
<br>
- Perhaps the hard block size limit should be determined by a vote of the m=
iners. Each miner could embed a desired block size limit in the coinbase tr=
ansactions of the blocks it publishes. The effective hard block size limit =
would be that size having the greatest number of votes within a sliding win=
dow of most recent blocks.<br>
<br>
- Perhaps the hard block size limit should be a function of block-chain len=
gth, so that it can scale up smoothly rather than jumping immediately to 20=
 MB. This function could be linear (anticipating a breakdown of Moore&#39;s=
 Law) or quadratic.<br>
<br>
I would be in support of any of the above, but I do not support Mike Hearn&=
#39;s proposed jump to 20 MB. Hearn&#39;s proposal kicks the can down the r=
oad without actually solving the problem, and it does so in a controversial=
 (step function) way.<br>
<br>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div></div></div></div></div></div></div>

--20cf303ea102062fb405158f84c7--