MIME-Version: 1.0
In-Reply-To: <16096345.A1MpJQQkRW@crushinator>
References: <16096345.A1MpJQQkRW@crushinator>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Fri, 8 May 2015 13:33:53 -0700
Message-ID: <CAOG=w-szbLgc1jLpkE_uMa3bkFTi-RiBEaQ6Y-u5aKLBC2HvUg@mail.gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>, 
	Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7bdcab348e6a08051597f3d1
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
Precedence: list

--047d7bdcab348e6a08051597f3d1
Content-Type: text/plain; charset=UTF-8

It is my professional opinion that raising the block size by merely
adjusting a constant without any sort of feedback mechanism would be a
dangerous and foolhardy thing to do. We are custodians of a multi-billion
dollar asset, and it falls upon us to weigh the consequences of our own
actions against the combined value of the entire bitcoin ecosystem. Ideally
we would take no action for which we are not absolutely certain of the
ramifications, with the information that can be made available to us. But
of course that is not always possible: there are unknown-unknowns, time
pressures, and known-unknowns where information has too high a marginal
cost. So where certainty is unobtainable, we must instead hedge against
unwanted outcomes.

The proposal to raise the block size now by redefining a constant carries
with it risk associated with infrastructure scaling, centralization
pressures, and delaying the necessary development of a constraint-based fee
economy. It also simply kicks the can down the road in settling these
issues because a larger but realistic hard limit must still exist, meaning
a future hard fork may still be required.

But whatever new hard limit is chosen, there is also a real possibility
that it may be too high. The standard response is that it is a soft-fork
change to impose a lower block size limit, which miners could do with a
minimal amount of coordination. This is however undermined by the
unfortunate reality that so many mining operations are absentee-run
businesses, or run by individuals without a strong background in bitcoin
protocol policy, or with interests which are not well aligned with other
users or holders of bitcoin. We cannot rely on miners being vigilant about
issues that develop, as they develop, or able to respond in the appropriate
fashion that someone with full domain knowledge and an objective
perspective would.

The alternative then is to have some sort of dynamic block size limit
controller, and ideally one which applies a cost to raising the block size
in some way the preserves the decentralization and/or long-term stability
features that we care about. I will now describe one such proposal:

  * For each block, the miner is allowed to select a different difficulty
(nBits) within a certain range, e.g. +/- 25% of the expected difficulty,
and this miner-selected difficulty is used for the proof of work check. In
addition to adjusting the hashcash target, selecting a different difficulty
also raises or lowers the maximum block size for that block by a function
of the difference in difficulty. So increasing the difficulty of the block
by an additional 25% raises the block limit for that block from 100% of the
current limit to 125%, and lowering the difficulty by 10% would also lower
the maximum block size for that block from 100% to 90% of the current
limit. For simplicity I will assume a linear identity transform as the
function, but a quadratic or other function with compounding marginal cost
may be preferred.

  * The default maximum block size limit is then adjusted at regular
intervals. For simplicity I will assume an adjustment at the end of each
2016 block interval, at the same time that difficulty is adjusted, but
there is no reason these have to be aligned. The adjustment algorithm
itself is either the selection of the median, or perhaps some sort of
weighted average that respects the "middle majority." There would of course
be limits on how quickly the block size limit can adjusted in any one
period, just as there are min/max limits on the difficulty adjustment.

  * To prevent perverse mining incentives, the original difficulty without
adjustment is used in the aggregate work calculations for selecting the
most-work chain, and the allowable miner-selected adjustment to difficulty
would have to be tightly constrained.

These rules create an incentive environment where raising the block size
has a real cost associated with it: a more difficult hashcash target for
the same subsidy reward. For rational miners that cost must be
counter-balanced by additional fees provided in the larger block. This
allows block size to increase, but only within the confines of a
self-supporting fee economy.

When the subsidy goes away or is reduced to an insignificant fraction of
the block reward, this incentive structure goes away. Hopefully at that
time we would have sufficient information to soft-fork set a hard block
size maximum. But in the mean time, the block size limit controller
constrains the maximum allowed block size to be within a range supported by
fees on the network, providing an emergency relief valve that we can be
assured will only be used at significant cost.

Mark Friedenbach

* There has over time been various discussions on the bitcointalk forums
about dynamically adjusting block size limits. The true origin of the idea
is unclear at this time (citations would be appreciated!) but a form of it
was implemented in Bytecoin / Monero using subsidy burning to increase the
block size. That approach has various limitations. These were corrected in
Greg Maxwell's suggestion to adjust the difficulty/nBits field directly,
which also has the added benefit of providing incentive for bidirectional
movement during the subsidy period. The description in this email and any
errors are my own.

On Fri, May 8, 2015 at 12: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.
>
> - 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
>

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

<div dir=3D"ltr"><div>It is my professional opinion that raising the block =
size by merely adjusting a constant without any sort of feedback mechanism =
would be a dangerous and foolhardy thing to do. We are custodians of a mult=
i-billion dollar asset, and it falls upon us to weigh the consequences of o=
ur own actions against the combined value of the entire bitcoin ecosystem. =
Ideally we would take no action for which we are not absolutely certain of =
the ramifications, with the information that can be made available to us. B=
ut of course that is not always possible: there are unknown-unknowns, time =
pressures, and known-unknowns where information has too high a marginal cos=
t. So where certainty is unobtainable, we must instead hedge against unwant=
ed outcomes.<br><br>The proposal to raise the block size now by redefining =
a constant carries with it risk associated with infrastructure scaling, cen=
tralization pressures, and delaying the necessary development of a constrai=
nt-based fee economy. It also simply kicks the can down the road in settlin=
g these issues because a larger but realistic hard limit must still exist, =
meaning a future hard fork may still be required.<br><br>But whatever new h=
ard limit is chosen, there is also a real possibility that it may be too hi=
gh. The standard response is that it is a soft-fork change to impose a lowe=
r block size limit, which miners could do with a minimal amount of coordina=
tion. This is however undermined by the unfortunate reality that so many mi=
ning operations are absentee-run businesses, or run by individuals without =
a strong background in bitcoin protocol policy, or with interests which are=
 not well aligned with other users or holders of bitcoin. We cannot rely on=
 miners being vigilant about issues that develop, as they develop, or able =
to respond in the appropriate fashion that someone with full domain knowled=
ge and an objective perspective would.<br><br>The alternative then is to ha=
ve some sort of dynamic block size limit controller, and ideally one which =
applies a cost to raising the block size in some way the preserves the dece=
ntralization and/or long-term stability features that we care about. I will=
 now describe one such proposal:<br><br>=C2=A0 * For each block, the miner =
is allowed to select a different difficulty (nBits) within a certain range,=
 e.g. +/- 25% of the expected difficulty, and this miner-selected difficult=
y is used for the proof of work check. In addition to adjusting the hashcas=
h target, selecting a different difficulty also raises or lowers the maximu=
m block size for that block by a function of the difference in difficulty. =
So increasing the difficulty of the block by an additional 25% raises the b=
lock limit for that block from 100% of the current limit to 125%, and lower=
ing the difficulty by 10% would also lower the maximum block size for that =
block from 100% to 90% of the current limit. For simplicity I will assume a=
 linear identity transform as the function, but a quadratic or other functi=
on with compounding marginal cost may be preferred.<br><br>=C2=A0 * The def=
ault maximum block size limit is then adjusted at regular intervals. For si=
mplicity I will assume an adjustment at the end of each 2016 block interval=
, at the same time that difficulty is adjusted, but there is no reason thes=
e have to be aligned. The adjustment algorithm itself is either the selecti=
on of the median, or perhaps some sort of weighted average that respects th=
e &quot;middle majority.&quot; There would of course be limits on how quick=
ly the block size limit can adjusted in any one period, just as there are m=
in/max limits on the difficulty adjustment.<br><br>=C2=A0 * To prevent perv=
erse mining incentives, the original difficulty without adjustment is used =
in the aggregate work calculations for selecting the most-work chain, and t=
he allowable miner-selected adjustment to difficulty would have to be tight=
ly constrained.<br><br>These rules create an incentive environment where ra=
ising the block size has a real cost associated with it: a more difficult h=
ashcash target for the same subsidy reward. For rational miners that cost m=
ust be counter-balanced by additional fees provided in the larger block. Th=
is allows block size to increase, but only within the confines of a self-su=
pporting fee economy.<br><br>When the subsidy goes away or is reduced to an=
 insignificant fraction of the block reward, this incentive structure goes =
away. Hopefully at that time we would have sufficient information to soft-f=
ork set a hard block size maximum. But in the mean time, the block size lim=
it controller constrains the maximum allowed block size to be within a rang=
e supported by fees on the network, providing an emergency relief valve tha=
t we can be assured will only be used at significant cost.<br><br>Mark Frie=
denbach<br><br>* There has over time been various discussions on the bitcoi=
ntalk forums about dynamically adjusting block size limits. The true origin=
 of the idea is unclear at this time (citations would be appreciated!) but =
a form of it was implemented in Bytecoin / Monero using subsidy burning to =
increase the block size. That approach has various limitations. These were =
corrected in Greg Maxwell&#39;s suggestion to adjust the difficulty/nBits f=
ield directly, which also has the added benefit of providing incentive for =
bidirectional movement during the subsidy period. The description in this e=
mail and any errors are my own.<br></div></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Fri, May 8, 2015 at 12:20 AM, Matt Whitloc=
k <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:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">Between all the flames on this list, several ideas were raised t=
hat did not get much attention. I hereby resubmit these ideas for considera=
tion 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">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>
</blockquote></div><br></div>

--047d7bdcab348e6a08051597f3d1--