path: root/46/838b7685be1aa0caf630ed4ac3e9281e9a41a3

Return-Path: <bitcoin@upalc.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DEA9994F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 17:21:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com
	[209.85.213.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B2BF611D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 17:21:52 +0000 (UTC)
Received: by igui7 with SMTP id i7so113217702igu.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 10:21:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=KZ+VSeXCDdvTteURfYM5vxbg8l3mRusA4Rnvh9AwJqQ=;
	b=VU2KTG+GwUfPlNRTIbgXTb5icH+lDfPbhF5Sdo/h1RTlSlJDYuo6orJO51rrp0j7Zv
	SDr3dTxpJgBC9+04rr9rkV/gdcoSFM/7ZpYdVu543N7mN4lXkd8TKHfAdkOpQO/+ujiE
	mD+dHkXWjeM0kg8meCurouCzenJO5IKbNmQCAfoFFo70tbMNTPDh26nWt/WJvVawpPxr
	SEojlGndqIuVw/Os6CIPpm2P7pbXkoXy0VmWJNn8I+od6JQiALsjKDZWDvo9/XshRTRP
	XOLXC4FMMXN/4W3DaQ+eRWrrBF5jAy1gPoZPAsypM6deB9MM8BcgEdtjTeW3KCpu8G9E
	iSPA==
X-Gm-Message-State: ALoCoQmLo8RQUmXPshT2Zzs7fGQAzPM2yM35i3OHSgTxHgsZa1zb0gu+p0hya8+27PmnhfeA5kAg
MIME-Version: 1.0
X-Received: by 10.50.66.129 with SMTP id f1mr27593878igt.7.1440004912118; Wed,
	19 Aug 2015 10:21:52 -0700 (PDT)
Received: by 10.107.18.155 with HTTP; Wed, 19 Aug 2015 10:21:52 -0700 (PDT)
X-Originating-IP: [115.187.37.206]
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: Wed, 19 Aug 2015 22:51:52 +0530
Message-ID: <CAED3CWhGgsAPrsCj+zMt2D_Cs7qHRznEok=oHgqU8VhPDZHL0g@mail.gmail.com>
From: Upal Chakraborty <bitcoin@upalc.com>
To: Danny Thorpe <danny.thorpe@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bdc0cf4432167051dad45cc
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2015 17:21:54 -0000

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

I think, keeping the reduction part is necessary to have it demand driven.
Otherwise, we could just increase it to a fixed size. If the max cap is
high, but there is not enough Tx in the mempool, then after one big block
many will go small. This will not be good when block reward become small
and mining revenue become dependent on Tx fee. But, if reduction is there,
max cap will come down soon and all miners will see revenue from Tx fee
again.

Proposal details: http://upalc.com/maxblocksize.php

On Wed, Aug 19, 2015 at 2:28 AM, Danny Thorpe <danny.thorpe@gmail.com>
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
>>
>>
>

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

<div dir=3D"ltr">I think, keeping the reduction part is necessary to have i=
t demand driven. Otherwise, we could just increase it to a fixed size. If t=
he max cap is high, but there is not enough Tx in the mempool, then after o=
ne big block many will go small. This will not be good when block reward be=
come small and mining revenue become dependent on Tx fee. But, if reduction=
 is there, max cap will come down soon and all miners will see revenue from=
 Tx fee again.<div><br></div><div>Proposal details:=C2=A0<a href=3D"http://=
upalc.com/maxblocksize.php">http://upalc.com/maxblocksize.php</a></div><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Aug 19, 2015 =
at 2:28 AM, Danny Thorpe <span dir=3D"ltr">&lt;<a href=3D"mailto:danny.thor=
pe@gmail.com" target=3D"_blank">danny.thorpe@gmail.com</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I like the simplicity =
of this approach.=C2=A0 Demand driven response.<div><br></div><div>Is there=
 really a need to reduce the max block size at all?=C2=A0 It is just a maxi=
mum limit, not a required size for every block.=C2=A0 If a seasonal transac=
tion 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; indefi=
nitely, even though periods of decreased transaction volume?</div><div><br>=
</div><div>I&#39;d argue to remove the reduction step, making the max block=
 size calculation a monotonic increasing function. Cut the complexity in ha=
lf.</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, 2015 a=
t 5:13 AM, Upal Chakraborty via bitcoin-dev <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br></div></div><blockq=
uote 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>_______________________________________________<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></blockquote></div><br></div>
</blockquote></div><br></div></div>

--047d7bdc0cf4432167051dad45cc--