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 AF9E5409 for ; Mon, 17 Aug 2015 12:43:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5679663 for ; Mon, 17 Aug 2015 12:43:47 +0000 (UTC) Received: by qkcs67 with SMTP id s67so45899873qkc.1 for ; Mon, 17 Aug 2015 05:43:46 -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:cc :content-type; bh=AUXFvkDnttwV9mK9Pj2D3nEZtzgEh6NR1P3gaPW8oKc=; b=J73YRqlEnIfinjUkbKYUlmUMeDyo/0zTu4LAmNMGmiFK85TesDrwVs1bm4xUlmLieP 9CT0xgDO4pqN05JyqKvYM/pN7G+A14Wr5mqGW+ZFTrNeFzXsnPGGYK353oa2ZpQnBqdX RmSpTwW925FGafN/YMd910K1VhR4x5kfZOMNLlZ7CI/Lkt5bxRPlEo1Csr+6SaEoumjO WmSKc8wX9fCjDjWErCgw+lvGl8P2hrhoZXFKHpiGPCLXKZUHvM2CindI5fd+ivgozuCD m8MC2uyDISs8TIRBBT5tw+mNYzThL77Z2ndBxky7al4H8V2abckOh0qNjDB2YjOfowmf 5nsA== MIME-Version: 1.0 X-Received: by 10.55.215.144 with SMTP id t16mr1995171qkt.107.1439815426724; Mon, 17 Aug 2015 05:43:46 -0700 (PDT) Received: by 10.140.31.181 with HTTP; Mon, 17 Aug 2015 05:43:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Aug 2015 13:43:46 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a114661980d6033051d812788 X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MALFORMED_FREEMAIL, MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no 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: Mon, 17 Aug 2015 12:43:47 -0000 --001a114661980d6033051d812788 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I haven't run any statistics or simulations, but I'm concerned that the > interplay between the random distribution of transaction arrival and the > random distribution of block times may lead to false signals. > You could just take the average of all the block sizes for the last 2016 window. If average of last 2016 > 50% of the limit, then increase by 6.25% Otherwise, decrease by 6.25% This means that the average would be around 50% of the limit. This gives margin to create larger blocks when blocks are happening slowly. A majority of miners could force the limit upwards by creating spam but full blocks. It could be coupled with a hard limit that grows at whatever is seen as the maximum reasonable. This would be both a maximum and a minimum. All of these schemes add state to the system. If the schedule is predictable, then you can check determine the maximum block size purely from the header and coinbase. --001a114661980d6033051d812788 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I haven't run any statistics or simulations,= but I'm concerned that the interplay between the random distribution o= f transaction arrival and the random distribution of block times may lead t= o false signals.

Yo= u could just take the average of all the block sizes for the last 2016 wind= ow.

If average of last 2016 > 50% of the limit, then i= ncrease by 6.25%
Otherwise, decrease by 6.25%

This means that the average would be around 50% of the limit.=C2=A0 This= gives margin to create larger blocks when blocks are happening slowly.
=
A majority of miners could force the limit upwards by creati= ng spam but full blocks.

It could be coupled with a= hard limit that grows at whatever is seen as the maximum reasonable.=C2=A0= This would be both a maximum and a minimum.

All of these schemes add state to the system.=C2=A0 If the schedu= le is predictable, then you can check determine the maximum block size pure= ly from the header and coinbase.
--001a114661980d6033051d812788--