Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.171 as permitted sender)
	client-ip=209.85.220.171; envelope-from=voisine@gmail.com;
	helo=mail-qk0-f171.google.com; 
MIME-Version: 1.0
In-Reply-To: <CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
	<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
Date: Fri, 29 May 2015 10:45:39 -0700
Message-ID: <CACq0ZD7hQGsR+-AORrjMYBzLzW80goKAsUEKf_GPfyL5bXN5iA@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a113a5d5265159105173c0b29
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
Precedence: list

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

> miners would definitely be squeezing out transactions / putting pressure
to increase transaction fees

I'd just like to re-iterate that transactions getting "squeezed out"
(failure after a lengthy period of uncertainty) is a radical change from
the current behavior of the network. There are plenty of avenues to create
fee pressure without resorting to such a drastic change in how the network
works today.


Aaron Voisine
co-founder and CEO
breadwallet.com

On Thu, May 28, 2015 at 8:53 AM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock <bip@mattwhitlock.name>
> wrote:
>
>> 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.
>>
>
> A lot of people like this idea, or something like it. It is nice and
> simple, which is really important for consensus-critical code.
>
> With this rule in place, I believe there would be more "fee pressure"
> (miners would be creating smaller blocks) today. I created a couple of
> histograms of block sizes to infer what policy miners are ACTUALLY
> following today with respect to block size:
>
> Last 1,000 blocks:
>   http://bitcoincore.org/~gavin/sizes_last1000.html
>
> Notice a big spike at 750K -- the default size for Bitcoin Core.
> This graph might be misleading, because transaction volume or fees might
> not be high enough over the last few days to fill blocks to whatever limit
> miners are willing to mine.
>
> So I graphed a time when (according to statoshi.info) there WERE a lot of
> transactions waiting to be confirmed:
>    http://bitcoincore.org/~gavin/sizes_357511.html
>
> That might also be misleading, because it is possible there were a lot of
> transactions waiting to be confirmed because miners who choose to create
> small blocks got lucky and found more blocks than normal.  In fact, it
> looks like that is what happened: more smaller-than-normal blocks were
> found, and the memory pool backed up.
>
> So: what if we had a dynamic maximum size limit based on recent history?
>
> The average block size is about 400K, so a 1.5x rule would make the max
> block size 600K; miners would definitely be squeezing out transactions /
> putting pressure to increase transaction fees. Even a 2x rule (implying
> 800K max blocks) would, today, be squeezing out transactions / putting
> pressure to increase fees.
>
> Using a median size instead of an average means the size can increase or
> decrease more quickly. For example, imagine the rule is "median of last
> 2016 blocks" and 49% of miners are producing 0-size blocks and 51% are
> producing max-size blocks. The median is max-size, so the 51% have total
> control over making blocks bigger.  Swap the roles, and the median is
> min-size.
>
> Because of that, I think using an average is better-- it means the max
> size will change (up or down) more slowly.
>
> I also think 2016 blocks is too long, because transaction volumes change
> quicker than that. An average over 144 blocks (last 24 hours) would be
> better able to handle increased transaction volume around major holidays,
> and would also be able to react more quickly if an economically irrational
> attacker attempted to flood the network with fee-paying transactions.
>
> So my straw-man proposal would be:  max size 2x average size over last 144
> blocks, calculated at every block.
>
> There are a couple of other changes I'd pair with that consensus change:
>
> + Make the default mining policy for Bitcoin Core neutral-- have its
> target block size be the average size, so miners that don't care will "go
> along with the people who do care."
>
> + Use something like Greg's formula for size instead of bytes-on-the-wire,
> to discourage bloating the UTXO set.
>
>
> ---------
>
> When I've proposed (privately, to the other core committers) some dynamic
> algorithm the objection has been "but that gives miners complete control
> over the max block size."
>
> I think that worry is unjustified right now-- certainly, until we have
> size-independent new block propagation there is an incentive for miners to
> keep their blocks small, and we see miners creating small blocks even when
> there are fee-paying transactions waiting to be confirmed.
>
> I don't even think it will be a problem if/when we do have
> size-independent new block propagation, because I think the combination of
> the random timing of block-finding plus a dynamic limit as described above
> will create a healthy system.
>
> If I'm wrong, then it seems to me the miners will have a very strong
> incentive to, collectively, impose whatever rules are necessary (maybe a
> soft-fork to put a hard cap on block size) to make the system healthy again.
>
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

<div dir=3D"ltr"><span style=3D"font-size:13px">&gt; miners would definitel=
y be squeezing out transactions / putting pressure to increase transaction =
fees</span><br><div><span style=3D"font-size:13px"><br></span></div><div>I&=
#39;d just like to re-iterate that transactions getting &quot;squeezed out&=
quot; (failure after a lengthy period of uncertainty) is a radical change f=
rom the current behavior of the network. There are plenty of avenues to cre=
ate fee=C2=A0pressure without resorting to such a drastic change in how the=
 network works today.</div></div><div class=3D"gmail_extra"><br clear=3D"al=
l"><div><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"lt=
r"><div><br>Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"http:/=
/breadwallet.com" target=3D"_blank">breadwallet.com</a></div></div></div></=
div></div></div>
<br><div class=3D"gmail_quote">On Thu, May 28, 2015 at 8:53 AM, Gavin Andre=
sen <span dir=3D"ltr">&lt;<a href=3D"mailto:gavinandresen@gmail.com" target=
=3D"_blank">gavinandresen@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><span class=3D"">On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:bip@mattwhitlock.name" target=3D"_=
blank">bip@mattwhitlock.name</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Betw=
een all the flames on this list, several ideas were raised that did not get=
 much attention. I hereby resubmit these ideas for consideration and discus=
sion.<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></blockquote><div><br>=
</div></span><div>A lot of people like this idea, or something like it. It =
is nice and simple, which is really important for consensus-critical code.<=
/div><div><br></div><div>With this rule in place, I believe there would be =
more &quot;fee pressure&quot; (miners would be creating smaller blocks) tod=
ay. I created a couple of histograms of block sizes to infer what policy mi=
ners are ACTUALLY following today with respect to block size:</div><div><br=
></div><div>Last 1,000 blocks:</div><div>=C2=A0=C2=A0<a href=3D"http://bitc=
oincore.org/~gavin/sizes_last1000.html" target=3D"_blank">http://bitcoincor=
e.org/~gavin/sizes_last1000.html</a></div><div><br></div><div>Notice a big =
spike at 750K -- the default size for Bitcoin Core.</div><div>This graph mi=
ght be misleading, because transaction volume or fees might not be high eno=
ugh over the last few days to fill blocks to whatever limit miners are will=
ing to mine.<br></div><div><br></div><div>So I graphed a time when (accordi=
ng to <a href=3D"http://statoshi.info" target=3D"_blank">statoshi.info</a>)=
 there WERE a lot of transactions waiting to be confirmed:</div><div>=C2=A0=
 =C2=A0<a href=3D"http://bitcoincore.org/~gavin/sizes_357511.html" target=
=3D"_blank">http://bitcoincore.org/~gavin/sizes_357511.html</a></div><div><=
br></div><div>That might also be misleading, because it is possible there w=
ere a lot of transactions waiting to be confirmed because miners who choose=
 to create small blocks got lucky and found more blocks than normal.=C2=A0 =
In fact, it looks like that is what happened: more smaller-than-normal bloc=
ks were found, and the memory pool backed up.</div><div><br></div><div>So: =
what if we had a dynamic maximum size limit based on recent history?</div><=
div><br></div><div>The average block size is about 400K, so a 1.5x rule wou=
ld make the max block size 600K; miners would definitely be squeezing out t=
ransactions / putting pressure to increase transaction fees. Even a 2x rule=
 (implying 800K max blocks) would, today, be squeezing out transactions / p=
utting pressure to increase fees.</div><div><br></div><div>Using a median s=
ize instead of an average means the size can increase or decrease more quic=
kly. For example, imagine the rule is &quot;median of last 2016 blocks&quot=
; and 49% of miners are producing 0-size blocks and 51% are producing max-s=
ize blocks. The median is max-size, so the 51% have total control over maki=
ng blocks bigger.=C2=A0 Swap the roles, and the median is min-size.</div><d=
iv><br></div><div>Because of that, I think using an average is better-- it =
means the max size will change (up or down) more slowly.</div><div><br></di=
v><div>I also think 2016 blocks is too long, because transaction volumes ch=
ange quicker than that. An average over 144 blocks (last 24 hours) would be=
 better able to handle increased transaction volume around major holidays, =
and would also be able to react more quickly if an economically irrational =
attacker attempted to flood the network with fee-paying transactions.</div>=
<div><br></div><div>So my straw-man proposal would be: =C2=A0max size 2x av=
erage size over last 144 blocks, calculated at every block.</div><div><br><=
/div><div>There are a couple of other changes I&#39;d pair with that consen=
sus change:</div><div><br></div><div>+ Make the default mining policy for B=
itcoin Core neutral-- have its target block size be the average size, so mi=
ners that don&#39;t care will &quot;go along with the people who do care.&q=
uot;</div><div><br></div><div>+ Use something like Greg&#39;s formula for s=
ize instead of bytes-on-the-wire, to discourage bloating the UTXO set.</div=
><div><br></div><div><br></div><div>---------</div><div><br></div><div>When=
 I&#39;ve proposed (privately, to the other core committers) some dynamic a=
lgorithm the objection has been &quot;but that gives miners complete contro=
l over the max block size.&quot;</div><div><br></div><div>I think that worr=
y is unjustified right now-- certainly, until we have size-independent new =
block propagation there is an incentive for miners to keep their blocks sma=
ll, and we see miners creating small blocks even when there are fee-paying =
transactions waiting to be confirmed.</div><div><br></div><div>I don&#39;t =
even think it will be a problem if/when we do have size-independent new blo=
ck propagation, because I think the combination of the random timing of blo=
ck-finding plus a dynamic limit as described above will create a healthy sy=
stem.</div><div><br></div><div>If I&#39;m wrong, then it seems to me the mi=
ners will have a very strong incentive to, collectively, impose whatever ru=
les are necessary (maybe a soft-fork to put a hard cap on block size) to ma=
ke the system healthy again.</div></div><span class=3D"HOEnZb"><font color=
=3D"#888888"><div><br></div><div><br></div>-- <br><div>--<br>Gavin Andresen=
<br></div><div><br></div>
</font></span></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
<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>

--001a113a5d5265159105173c0b29--