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 DE44D895 for ; Tue, 18 Aug 2015 20:58:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 482C71B7 for ; Tue, 18 Aug 2015 20:58:51 +0000 (UTC) Received: by obbhe7 with SMTP id he7so151940415obb.0 for ; Tue, 18 Aug 2015 13:58:50 -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 :cc:content-type; bh=flP4rxSRzKh6fw2oFSroyt443OV004brdqfnSmnKq2k=; b=wBhhVeBkTTlUsjldDk/M3KVOqdXLN6ndTrmHx559hnQ7BRF+WFvQ5v5KlWoiZd7la4 0pOCMaBlDdRBXcU4Sqqo2K02ZjY+/3jl0qxKJAjtz3drFno3/v5TzQTXz8qjksY4U2IQ hj6sfY7WCIkLYFYkWRq60tNlqv2IW5Dqoniq+YFyZFT1AQ9TeFcFNf+6X8VL3lRdb26E yloOVL2P0hTJZDU+AtfzhbluZqFkRVs11FheGTK9x2PiTnOdxKLjdeVwdfrZZz2ucI1M RvbestlYnPzkYI3pTaO+rRRAOcMfLPr/avWoonO33mUQU9MJhoO6BKGh16OHJyW5usec 54OA== MIME-Version: 1.0 X-Received: by 10.182.250.137 with SMTP id zc9mr7492498obc.79.1439931530633; Tue, 18 Aug 2015 13:58:50 -0700 (PDT) Received: by 10.202.134.78 with HTTP; Tue, 18 Aug 2015 13:58:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Aug 2015 13:58:50 -0700 Message-ID: From: Danny Thorpe To: Upal Chakraborty Content-Type: multipart/alternative; boundary=089e01537b22626ae8051d9c2f9f 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 20:58:52 -0000 --089e01537b22626ae8051d9c2f9f Content-Type: text/plain; charset=UTF-8 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 > > --089e01537b22626ae8051d9c2f9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like the simplicity of this approach.=C2=A0 Demand drive= n response.

Is there really a need to reduce the max blo= ck size at all?=C2=A0 It is just a maximum limit, not a required size for e= very block.=C2=A0 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 decre= ased transaction volume?

I'd argue to remove t= he reduction step, making the max block size calculation a monotonic increa= sing function. Cut the complexity in half.

-Danny<= /div>

On Tue= , Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Regarding:=C2=A0http://lists.linuxfoundation.org/pipermail/bitcoin-dev/20= 15-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 e= mpty blocks.


First, I wo= uld like to argue from economics' point of view. If someone wants to ho= ld 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 losi= ng 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 s= lightly modified technical solution to this problem in algorithmic format..= .

If more than 50% of block's size, found in t= he first 2000 of the last difficulty period, is more than 90% MaxBlockSize<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Double MaxBlockSize
<= div>Else if more than 90% of block's size, found in the first 2000 of t= he last difficulty period, is less than 50% MaxBlockSize
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Half MaxBlockSize
Else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keep 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 th= an 10% hash power, but must mine more than 50% of MaxBlockSize in all block= s. 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 T= x to fill up the blocks. Please note that, taking first 2000 of the last 20= 16 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 havi= ng 16 confirmation.

Looking for comments.





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


--089e01537b22626ae8051d9c2f9f--