Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.218.49 as permitted sender)
	client-ip=209.85.218.49; envelope-from=joel.kaartinen@gmail.com;
	helo=mail-oi0-f49.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAP63atbdFSw0rDeuwgtjsDYsXnKSHNN9=zedzip2MsZ0hSY59w@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
	<CAP63atbdFSw0rDeuwgtjsDYsXnKSHNN9=zedzip2MsZ0hSY59w@mail.gmail.com>
Date: Fri, 8 May 2015 15:32:00 +0300
Message-ID: <CAGKSKfW7fJB6n3B-OoyXOep7hAQqWGGDTiZCkpJ7vXxWRFgveA@mail.gmail.com>
From: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: multipart/alternative; boundary=001a1137c846f7d06605159136f0
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
Precedence: list

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

Matt,

It seems you missed my suggestion about basing the maximum block size on
the bitcoin days destroyed in transactions that are included in the block.
I think it has potential for both scaling as well as keeping up a constant
fee pressure. If tuned properly, it should both stop spamming and increase
block size maximum when there are a lot of real transactions waiting for
inclusion.

- Joel

On Fri, May 8, 2015 at 1:30 PM, Cl=C3=A9ment Elbaz <clem.ds@gmail.com> wrot=
e:

> 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 sam=
e
> 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 si=
ze
> 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 =
and
>> 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 th=
e
>> miners. Each miner could embed a desired block size limit in the coinbas=
e
>> 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
>>
>
>
> -------------------------------------------------------------------------=
-----
> 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
>
>

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

<div dir=3D"ltr"><div>Matt,</div><div><br></div>It seems you missed my sugg=
estion about basing the maximum block size on the bitcoin days destroyed in=
 transactions that are included in the block. I think it has potential for =
both scaling as well as keeping up a constant fee pressure. If tuned proper=
ly, it should both stop spamming and increase block size maximum when there=
 are a lot of real transactions waiting for inclusion.<div><br></div><div>-=
 Joel<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, =
May 8, 2015 at 1:30 PM, Cl=C3=A9ment Elbaz <span dir=3D"ltr">&lt;<a href=3D=
"mailto:clem.ds@gmail.com" target=3D"_blank">clem.ds@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div=
>Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my f=
avorite.<br><br></div><div>I see two problems with proposal #2.<br></div>Th=
e first problem with proposal #2 is that, as we see in democracies,=C2=A0 t=
here is often a mismatch between the people conscious vote and these same p=
eople behavior. <br><br>Relying on an=C2=A0 intentional vote made conscious=
ly by miners by choosing a configuration value can lead to twisted results =
if their actual behavior doesn&#39;t correlate with their vote (eg, they al=
l vote for a small block size because it is the default configuration of th=
eir software, and then they fill it completely all the time and everything =
crashes).<br><br></div><div>The second problem with proposal #2 is that if =
Gavin and Mike are right, there is simply no time to gather a meaningful am=
ount of votes over the coinbases, after the fork but before the Bitcoin sca=
lability crash. <br></div><div><br></div>I like proposal #1 because the &qu=
ot;vote&quot; is made using already available data. Also there is no possib=
le mismatch between behavior and vote. As a miner you vote by choosing to c=
reate a big (or small) block, and your actions reflect your vote. It is sim=
ple and straightforward.<br><br></div>My feelings on proposal #3 is it is a=
 little bit mixing apples and oranges, but I may not seeing all the implica=
tions.<div><div class=3D"h5"><br><div><div><div><div><div><br><div class=3D=
"gmail_quote">Le=C2=A0ven. 8 mai 2015 =C3=A0=C2=A009:21, Matt Whitlock &lt;=
<a href=3D"mailto:bip@mattwhitlock.name" target=3D"_blank">bip@mattwhitlock=
.name</a>&gt; a =C3=A9crit=C2=A0:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Between=
 all the flames on this list, several ideas were raised that did not get mu=
ch attention. I hereby resubmit these ideas for consideration and discussio=
n.<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></div></div>
<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">Bitcoin-develo=
pment@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>
<br></blockquote></div><br></div></div></div>

--001a1137c846f7d06605159136f0--