MIME-Version: 1.0
In-Reply-To: <CAJN5wHU59N68H7U-reANK9u=dF+906y-fyOj2cYRSFXZyLAT0g@mail.gmail.com>
References: <CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com>
	<CAJN5wHU59N68H7U-reANK9u=dF+906y-fyOj2cYRSFXZyLAT0g@mail.gmail.com>
Date: Tue, 18 Aug 2015 17:17:06 -0400
Message-ID: <CAEieSeSNusgBK4LX9SWT4iENQo66EbXRbha6AKQv_3dh8koz4g@mail.gmail.com>
From: Chris Wardell <wardell.c@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=94eb2c076e8eb66172051d9c7049
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Precedence: list

--94eb2c076e8eb66172051d9c7049
Content-Type: text/plain; charset=UTF-8

I agree with the simplicity of this approach and with removing the
reduction step... it's unlikely the block size would ever need to be
reduced, only increased with demand?

I like this solution better than either kicking the can, or raising the
block size based on chain height (another dynamic solution).

-Chris


On Tue, Aug 18, 2015 at 4:58 PM, Danny Thorpe via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I like the simplicity of this approach.  Demand driven response.
>
> Is there really a need to reduce the max block size at all?  It is just a
> maximum limit, not a required size for every block.  If a seasonal
> transaction surge bumps the max block size limit up a notch, what harm is
> there in leaving the max block size limit at the "high water mark"
> indefinitely, even though periods of decreased transaction volume?
>
> I'd argue to remove the reduction step, making the max block size
> calculation a monotonic increasing function. Cut the complexity in half.
>
> -Danny
>
> On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Regarding:
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
>>
>>
>> I am arguing with the following statement here...
>>
>> *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.*
>>
>>
>>
>> First, I would like to argue from economics' point of view. If someone
>> wants to hold back the block size increase with 11% hash power by mining
>> empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
>> hash power will most likely be a pool and pool miners will find out soon
>> that they are losing Tx fees because of pool owner's intention. Hence,
>> they'll switch pool and pool owner will lose out. This is the same reason
>> why 51% attack will never happen, even if a pool gets more than 51% hash
>> power.
>>
>>
>> Next, I would like to propose a slightly modified technical solution to
>> this problem in algorithmic format...
>>
>> If more than 50% of block's size, found in the first 2000 of the last
>> difficulty period, is more than 90% MaxBlockSize
>>          Double MaxBlockSize
>> Else if more than 90% of block's size, found in the first 2000 of the
>> last difficulty period, is less than 50% MaxBlockSize
>>          Half MaxBlockSize
>> Else
>>          Keep the same MaxBlockSize
>>
>> This is how, those who want to stop increase, need to have more than 50%
>> hash power. Those who want to stop decrease, need to have more than 10%
>> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
>> this approach, not only miners, but also the end user have their say.
>> Because, end users will fill up the mempool, from where miners will take Tx
>> to fill up the blocks. Please note that, taking first 2000 of the last 2016
>> blocks is important to avoid data discrepancy among different nodes due to
>> orphan blocks. It is assumed that a chain can not be orphaned after having
>> 16 confirmation.
>>
>> Looking for comments.
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div>I agree with the simplicity of this approach and with=
 removing the reduction step... it&#39;s unlikely the block size would ever=
 need to be reduced, only increased with demand?<br><br></div>I like this s=
olution better than either kicking the can, or raising the block size based=
 on chain height (another dynamic solution).<br><div><div><br></div><div>-C=
hris<br></div><div><br><div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On Tue, Aug 18, 2015 at 4:58 PM, Danny Thorpe via bitcoin-dev <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I like the simplici=
ty of this approach.=C2=A0 Demand driven response.<div><br></div><div>Is th=
ere really a need to reduce the max block size at all?=C2=A0 It is just a m=
aximum limit, not a required size for every block.=C2=A0 If a seasonal tran=
saction surge bumps the max block size limit up a notch, what harm is there=
 in leaving the max block size limit at the &quot;high water mark&quot; ind=
efinitely, even though periods of decreased transaction volume?</div><div><=
br></div><div>I&#39;d argue to remove the reduction step, making the max bl=
ock size calculation a monotonic increasing function. Cut the complexity in=
 half.</div><div><br></div><div>-Danny</div></div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Tue, Aug 18, 201=
5 at 5:13 AM, Upal Chakraborty via bitcoin-dev <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br></div></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr">Regarding:=
=C2=A0<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
5-August/010295.html" target=3D"_blank">http://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2015-August/010295.html</a><div><br><div><br></div><div=
>I am arguing with the following statement here...</div><div><br></div><div=
><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"><i>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></blockquote><div><br></div><div><br>=
</div><div>First, I would like to argue from economics&#39; point of view. =
If someone wants to hold back the block size increase with 11% hash power b=
y mining empty blocks, he has to sacrifice Tx fees, which is not economical=
. 11% hash power will most likely be a pool and pool miners will find out s=
oon that they are losing Tx fees because of pool owner&#39;s intention. Hen=
ce, they&#39;ll switch pool and pool owner will lose out. This is the same =
reason why 51% attack will never happen, even if a pool gets more than 51% =
hash power.</div></div></div><div><br></div><div><br></div><div>Next, I wou=
ld like to propose a slightly modified technical solution to this problem i=
n algorithmic format...</div><div><br></div><div>If more than 50% of block&=
#39;s size, found in the first 2000 of the last difficulty period, is more =
than 90% MaxBlockSize</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Double Ma=
xBlockSize</div><div><div>Else if more than 90% of block&#39;s size, found =
in the first 2000 of the last difficulty period, is less than 50% MaxBlockS=
ize</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Half MaxBlockSize</div></di=
v><div>Else</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keep the same MaxBl=
ockSize</div><div><br></div><div>This is how, those who want to stop increa=
se, need to have more than 50% hash power. Those who want to stop decrease,=
 need to have more than 10% hash power, but must mine more than 50% of MaxB=
lockSize in all blocks. In this approach, not only miners, but also the end=
 user have their say. Because, end users will fill up the mempool, from whe=
re miners will take Tx to fill up the blocks. Please note that, taking firs=
t 2000 of the last 2016 blocks is important to avoid data discrepancy among=
 different nodes due to orphan blocks. It is assumed that a chain can not b=
e orphaned after having 16 confirmation.</div><div><br></div><div>Looking f=
or comments.</div><div><br></div><div><br></div><div><br></div><div><br></d=
iv></div>
<br></div></div><span class=3D"">__________________________________________=
_____<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div></div></div></div></div>

--94eb2c076e8eb66172051d9c7049--