MIME-Version: 1.0
Date: Mon, 17 Aug 2015 21:57:47 +1000
Message-ID: <CABerxhEwA7Pz0hdSuOf+RwWZiZpY1fSArB+UiyVUwr6S2fr3vQ@mail.gmail.com>
From: Rodney Morris <rodney.morris@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e0122eda89db35a051d8082c6
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Precedence: list

--089e0122eda89db35a051d8082c6
Content-Type: text/plain; charset=UTF-8

Words cannot capture how much I wish Satoshi had put logic like this (or
even just a simple block size doubling every reward halving) in place when
he put in the "temporary" 1MB anti-spam block size limit...

I see problems to this approach.  The biggest one I see is that a miner
with 11% of hash power could sabotage block size increases by only ever
mining empty blocks.

I haven't run any statistics or simulations, but I'm concerned that the
interplay between the random distribution of transaction arrival and the
random distribution of block times may lead to false signals.

A 90% full block 1 minute after the previous block is a more "serious"
problem than a 90% full block 30 minutes after the previous block.  A 90%
full block after a 90% full block is a more "serious" problem than a 90%
full block after an empty block.

I would expect a robust approach in this manner to look at block sizes
weighted by block times, but this is an interesting proposal regardless.

But I think you'll run up against one of the great schisms in this debate -
those that believe blocks should always be full (or close to it), to
encourage a "fee market" and to encourage off-chain transactions, and those
that think that the blockchain should be useable by almost anyone for
almost anything, implying there should always be spare space in blocks,
with off-chain transactions reserved for microtransactions and zero-conf
(and possibly low-fee transactions).  At least, that's my take on it.

Rodney



>
>
> Date: Mon, 17 Aug 2015 11:51:26 +0100
> From: Btc Drak <btcdrak@gmail.com>
> To: Patrick Strateman <patrick.strateman@gmail.com>
> Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size
>         Max Cap
> Message-ID:
>         <CADJgMzvV7cSW9aBnAf5zX7FDxN5E=AW=rET2i9EnysLao=
> vVyw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Nobody is going to click that...
>
> I guess I am nobody. Here's a copy of the text:-
>
> *Dynamically Controlled Bitcoin Block Size Max Cap
> <http://upalc.com/maxblocksize.php>*
>
> *Assumption*: This article is for those, who already understand the bitcoin
> protocol and aware of the block size controversy. Details of the problem
> statement can be found in BIP 100
> <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf>.
> Satoshi's opinion regarding block size can be found here
> <https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366>. I will
> be
> directly going into the solution without explaining the problem in details.
>
>
> *Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
> block each full node does a calculation to find the next target. We will do
> just another calculation here. Nodes will also calculate what % of blocks
> in the last difficulty period is higher than 90% of the maximum block size,
> which is 1 MB for now. If it is found that more than 90% blocks in the last
> difficulty period is higher than 90% of the maximum block size, then double
> the maximum block size. If not, then calculate what % of blocks in the last
> difficulty period is less than 50% of the maximum block size. If it is
> higher than 90%, then half the maximum block size. If none of the above
> condition satisfies, keep the maximum block size as it is.
>
> Please note that, while calculating the % of blocks, it is better to take
> into account the first 2000 of the 2016, than the whole of 2016. This helps
> to avoid the calculation mistake if some of the last few blocks get
> orphaned.
>
>
> *Reasoning*: This solution is derived directly from the indication of the
> problem. If transaction volume increases, then we will naturally see bigger
> blocks. On the contrary, if there are not enough transaction volume, but
> maximum block size is high, then only few blocks may sweep the mempool.
> Hence, if block size is itself taken into consideration, then maximum block
> size can most rationally be derived. Moreover, this solution not only
> increases, but also decreases the maximum block size, just like difficulty.
>
>
> *Other Solutions of this Problem*:-
>
> Making Decentralized Economic Policy
> <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf> - by
> Jeff Garzik
>
> Elastic block cap with rollover penalties
> <https://bitcointalk.org/index.php?topic=1078521> ? by Meni Rosenfeld
>
> Increase maximum block size
> <https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki> - by
> Gavin
> Andresen
>
> Block size following technological growth
> <https://gist.github.com/sipa/c65665fc360ca7a176a6> - by Pieter Wuille
>
> The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
> <https://lightning.network/lightning-network-paper.pdf> - by Joseph Poon &
> Thaddeus Dryja
>
>
> Please share your opinion regarding this solution below. For mail
> communication, feel free to write me at bitcoin [at] upalc.com.
>
>

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Words cannot capture how much I wish Satoshi had put logic like this (or e=
ven just a simple block size doubling every reward halving) in place when h=
e put in the &quot;temporary&quot; 1MB anti-spam block size limit...</div><=
div><br></div><div>I see problems to this approach.=C2=A0 The biggest one I=
 see is that a miner with 11% of hash power could sabotage block size incre=
ases by only ever mining empty blocks.</div><div><br></div><div>I haven&#39=
;t run any statistics or simulations, but I&#39;m concerned that the interp=
lay between the random distribution of transaction arrival and the random d=
istribution of block times may lead to false signals.</div><div><br></div><=
div>A 90% full block 1 minute after the previous block is a more &quot;seri=
ous&quot; problem than a 90% full block 30 minutes after the previous block=
.=C2=A0 A 90% full block after a 90% full block is a more &quot;serious&quo=
t; problem than a 90% full block after an empty block.</div><div><br></div>=
<div>I would expect a robust approach in this manner to look at block sizes=
 weighted by block times, but this is an interesting proposal regardless.</=
div><div><br></div><div>But I think you&#39;ll run up against one of the gr=
eat schisms in this debate - those that believe blocks should always be ful=
l (or close to it), to encourage a &quot;fee market&quot; and to encourage =
off-chain transactions, and those that think that the blockchain should be =
useable by almost anyone for almost anything, implying there should always =
be spare space in blocks, with off-chain transactions reserved for microtra=
nsactions and zero-conf (and possibly low-fee transactions).=C2=A0 At least=
, that&#39;s my take on it.</div><div><br></div><div>Rodney</div><div><br><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br>
Date: Mon, 17 Aug 2015 11:51:26 +0100<br>
From: Btc Drak &lt;<a href=3D"mailto:btcdrak@gmail.com">btcdrak@gmail.com</=
a>&gt;<br>
To: Patrick Strateman &lt;<a href=3D"mailto:patrick.strateman@gmail.com">pa=
trick.strateman@gmail.com</a>&gt;<br>
Cc: Bitcoin Dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Max Cap<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;CADJgMzvV7cSW9aBnAf5zX7FDxN5E=3DAW=3DrET2i9=
EnysLao=3D<a href=3D"mailto:vVyw@mail.gmail.com">vVyw@mail.gmail.com</a>&gt=
;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev &lt;<br=
>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt; wrote:<br>
&gt; Nobody is going to click that...<br>
<br>
I guess I am nobody. Here&#39;s a copy of the text:-<br>
<br>
*Dynamically Controlled Bitcoin Block Size Max Cap<br>
&lt;<a href=3D"http://upalc.com/maxblocksize.php" rel=3D"noreferrer" target=
=3D"_blank">http://upalc.com/maxblocksize.php</a>&gt;*<br>
<br>
*Assumption*: This article is for those, who already understand the bitcoin=
<br>
protocol and aware of the block size controversy. Details of the problem<br=
>
statement can be found in BIP 100<br>
&lt;<a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal=
.pdf" rel=3D"noreferrer" target=3D"_blank">http://gtf.org/garzik/bitcoin/BI=
P100-blocksizechangeproposal.pdf</a>&gt;.<br>
Satoshi&#39;s opinion regarding block size can be found here<br>
&lt;<a href=3D"https://bitcointalk.org/index.php?topic=3D1347.msg15366#msg1=
5366" rel=3D"noreferrer" target=3D"_blank">https://bitcointalk.org/index.ph=
p?topic=3D1347.msg15366#msg15366</a>&gt;. I will be<br>
directly going into the solution without explaining the problem in details.=
<br>
<br>
<br>
*Solution*: Difficulty changes at every 2016 block, i.e. at every 2016<br>
block each full node does a calculation to find the next target. We will do=
<br>
just another calculation here. Nodes will also calculate what % of blocks<b=
r>
in the last difficulty period is higher than 90% of the maximum block size,=
<br>
which is 1 MB for now. If it is found that more than 90% blocks in the last=
<br>
difficulty period is higher than 90% of the maximum block size, then double=
<br>
the maximum block size. If not, then calculate what % of blocks in the last=
<br>
difficulty period is less than 50% of the maximum block size. If it is<br>
higher than 90%, then half the maximum block size. If none of the above<br>
condition satisfies, keep the maximum block size as it is.<br>
<br>
Please note that, while calculating the % of blocks, it is better to take<b=
r>
into account the first 2000 of the 2016, than the whole of 2016. This helps=
<br>
to avoid the calculation mistake if some of the last few blocks get<br>
orphaned.<br>
<br>
<br>
*Reasoning*: This solution is derived directly from the indication of the<b=
r>
problem. If transaction volume increases, then we will naturally see bigger=
<br>
blocks. On the contrary, if there are not enough transaction volume, but<br=
>
maximum block size is high, then only few blocks may sweep the mempool.<br>
Hence, if block size is itself taken into consideration, then maximum block=
<br>
size can most rationally be derived. Moreover, this solution not only<br>
increases, but also decreases the maximum block size, just like difficulty.=
<br>
<br>
<br>
*Other Solutions of this Problem*:-<br>
<br>
Making Decentralized Economic Policy<br>
&lt;<a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal=
.pdf" rel=3D"noreferrer" target=3D"_blank">http://gtf.org/garzik/bitcoin/BI=
P100-blocksizechangeproposal.pdf</a>&gt; - by<br>
Jeff Garzik<br>
<br>
Elastic block cap with rollover penalties<br>
&lt;<a href=3D"https://bitcointalk.org/index.php?topic=3D1078521" rel=3D"no=
referrer" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D10785=
21</a>&gt; ? by Meni Rosenfeld<br>
<br>
Increase maximum block size<br>
&lt;<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0101.mediawi=
ki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/bl=
ob/master/bip-0101.mediawiki</a>&gt; - by Gavin<br>
Andresen<br>
<br>
Block size following technological growth<br>
&lt;<a href=3D"https://gist.github.com/sipa/c65665fc360ca7a176a6" rel=3D"no=
referrer" target=3D"_blank">https://gist.github.com/sipa/c65665fc360ca7a176=
a6</a>&gt; - by Pieter Wuille<br>
<br>
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments<br>
&lt;<a href=3D"https://lightning.network/lightning-network-paper.pdf" rel=
=3D"noreferrer" target=3D"_blank">https://lightning.network/lightning-netwo=
rk-paper.pdf</a>&gt; - by Joseph Poon &amp;<br>
Thaddeus Dryja<br>
<br>
<br>
Please share your opinion regarding this solution below. For mail<br>
communication, feel free to write me at bitcoin [at] <a href=3D"http://upal=
c.com" rel=3D"noreferrer" target=3D"_blank">upalc.com</a>.<br>
<br></blockquote></div></div></div>

--089e0122eda89db35a051d8082c6--