path: root/68/8b7bd1a219a37c4f4493b1a4f4e80e13b67b49

Return-Path: <wardell.c@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 862B97AA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Aug 2015 21:17:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f179.google.com (mail-yk0-f179.google.com
	[209.85.160.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6AA83191
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Aug 2015 21:17:07 +0000 (UTC)
Received: by ykfw73 with SMTP id w73so118640536ykf.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Aug 2015 14:17:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=6e0Lnu3NmkmsMOjQWswu0v50kjN9RQMvSjIFn9MCgjw=;
	b=hsip53gl7/I94xnKno1EOl1HU3DLt0y1s/+IysonYU5IuoasG+Z07jB0vZ+OoqJeCF
	fv8WfqYdeOv24+rnWunr1ljmCCyLS0B5529RJqTg61nqd2SyWUkaa9FW540Z9NLzoZq8
	cL0aXCSl2EPkBRZksUxp4KjoK0XGdVug38Nn31jKBxlXY9goRiHv7aW4iAi+xqUnRVBz
	VYRtVtKALWtr6Yu2j2Esr06CQIxunjKf7OUeAYTTTUcIRUqyDLjA3bmV/HekWURbBrQ6
	o6X1t5iZBp+sUQhaYr6jn087rL9aGVm2tBpZDBQ+BykkeajHBCmQikHdz97f/5CQaY3W
	s6XQ==
MIME-Version: 1.0
X-Received: by 10.13.225.66 with SMTP id k63mr10224837ywe.148.1439932626653;
	Tue, 18 Aug 2015 14:17:06 -0700 (PDT)
Received: by 10.37.2.69 with HTTP; Tue, 18 Aug 2015 14:17:06 -0700 (PDT)
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
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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
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: Tue, 18 Aug 2015 21:17:08 -0000

--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--