From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 862B97AA for ; 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 ; Tue, 18 Aug 2015 21:17:07 +0000 (UTC) Received: by ykfw73 with SMTP id w73so118640536ykf.3 for ; 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: References: Date: Tue, 18 Aug 2015 17:17:06 -0400 Message-ID: From: Chris Wardell 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 s= olution better than either kicking the can, or raising the block size based= on chain height (another dynamic solution).

-C= hris


On Tue, Aug 18, 2015 at 4:58 PM, Danny Thorpe via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:
I like the simplici= ty of this approach.=C2=A0 Demand driven response.

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 "high water mark" ind= efinitely, even though periods of decreased transaction volume?
<= br>
I'd argue to remove the reduction step, making the max bl= ock size calculation a monotonic increasing function. Cut the complexity in= half.

-Danny

On Tue, Aug 18, 201= 5 at 5:13 AM, Upal Chakraborty via bitcoin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:
Regarding:= =C2=A0http://lists.linuxfoundation.org/pi= permail/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 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's intention. Hen= ce, 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 wou= ld like to propose a slightly modified technical solution to this problem i= n algorithmic format...

If more than 50% of block&= #39;s size, found in the first 2000 of the last difficulty period, is more = than 90% MaxBlockSize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Double Ma= xBlockSize
Else if more than 90% of block's size, found = in the first 2000 of the last difficulty period, is less than 50% MaxBlockS= ize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Half MaxBlockSize
Else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keep the same MaxBl= ockSize

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.

Looking f= or comments.





__________________________________________= _____
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--94eb2c076e8eb66172051d9c7049--