Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 817D29C for ; Mon, 17 Aug 2015 11:57:49 +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 8B85117F for ; Mon, 17 Aug 2015 11:57:48 +0000 (UTC) Received: by igxp17 with SMTP id p17so53720604igx.1 for ; Mon, 17 Aug 2015 04:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gq0+4hcY5NFNGvxQE8RLDHH5IDeJV6bXC51yKXy/P6k=; b=lfus97CIbtygvZmJqj7Wc2rDk+9E0JNvsthkQzU/NXIpcJfI+BNPbnsTHFWCrVV9H6 76whCyZDZrs/x5dnsu8aTBLxIaDNdZ23m3aaEHPluI5HFaUz0zkF87ikLwxyVGFvR+mU 4DBTfhuSoLfxO0/MGZbupNzA88TcqsKlLLPXwrjsCGUKIsBw6Fp6+lGiEFG3Nuy66Zvt TlWDvngsdq3G6IT0X6PkX/+tYfTNgH+jR47CFGb0ovPNztHoWeVaVub/gZ76J6KVVXbu QuwI+xTsh+9xCW7tShDwdGxmJS5ELLdOErxyoXoAIb4xZxh5MkZ5CEnOl5jZZvOGuVEK GjzQ== MIME-Version: 1.0 X-Received: by 10.50.7.35 with SMTP id g3mr15557781iga.39.1439812667943; Mon, 17 Aug 2015 04:57:47 -0700 (PDT) Received: by 10.79.22.198 with HTTP; Mon, 17 Aug 2015 04:57:47 -0700 (PDT) Date: Mon, 17 Aug 2015 21:57:47 +1000 Message-ID: From: Rodney Morris To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=089e0122eda89db35a051d8082c6 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: Mon, 17 Aug 2015 11:57:49 -0000 --089e0122eda89db35a051d8082c6 Content-Type: text/plain; charset=UTF-8 Words cannot capture how much I wish Satoshi had put logic like this (or even just a simple block size doubling every reward halving) in place when he put in the "temporary" 1MB anti-spam block size limit... 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 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. A 90% full block 1 minute after the previous block is a more "serious" problem than a 90% full block 30 minutes after the previous block. A 90% full block after a 90% full block is a more "serious" problem than a 90% full block after an empty block. I would expect a robust approach in this manner to look at block sizes weighted by block times, but this is an interesting proposal regardless. But I think you'll run up against one of the great schisms in this debate - those that believe blocks should always be full (or close to it), to encourage a "fee market" and to encourage off-chain transactions, and those that think that the blockchain should be useable by almost anyone for almost anything, implying there should always be spare space in blocks, with off-chain transactions reserved for microtransactions and zero-conf (and possibly low-fee transactions). At least, that's my take on it. Rodney > > > Date: Mon, 17 Aug 2015 11:51:26 +0100 > From: Btc Drak > To: Patrick Strateman > Cc: Bitcoin Dev > Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size > Max Cap > Message-ID: > vVyw@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Nobody is going to click that... > > I guess I am nobody. Here's a copy of the text:- > > *Dynamically Controlled Bitcoin Block Size Max Cap > * > > *Assumption*: This article is for those, who already understand the bitcoin > protocol and aware of the block size controversy. Details of the problem > statement can be found in BIP 100 > . > Satoshi's opinion regarding block size can be found here > . I will > be > directly going into the solution without explaining the problem in details. > > > *Solution*: Difficulty changes at every 2016 block, i.e. at every 2016 > block each full node does a calculation to find the next target. We will do > just another calculation here. Nodes will also calculate what % of blocks > in the last difficulty period is higher than 90% of the maximum block size, > which is 1 MB for now. If it is found that more than 90% blocks in the last > difficulty period is higher than 90% of the maximum block size, then double > the maximum block size. If not, then calculate what % of blocks in the last > difficulty period is less than 50% of the maximum block size. If it is > higher than 90%, then half the maximum block size. If none of the above > condition satisfies, keep the maximum block size as it is. > > Please note that, while calculating the % of blocks, it is better to take > into account the first 2000 of the 2016, than the whole of 2016. This helps > to avoid the calculation mistake if some of the last few blocks get > orphaned. > > > *Reasoning*: This solution is derived directly from the indication of the > problem. If transaction volume increases, then we will naturally see bigger > blocks. On the contrary, if there are not enough transaction volume, but > maximum block size is high, then only few blocks may sweep the mempool. > Hence, if block size is itself taken into consideration, then maximum block > size can most rationally be derived. Moreover, this solution not only > increases, but also decreases the maximum block size, just like difficulty. > > > *Other Solutions of this Problem*:- > > Making Decentralized Economic Policy > - by > Jeff Garzik > > Elastic block cap with rollover penalties > ? by Meni Rosenfeld > > Increase maximum block size > - by > Gavin > Andresen > > Block size following technological growth > - by Pieter Wuille > > The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments > - by Joseph Poon & > Thaddeus Dryja > > > Please share your opinion regarding this solution below. For mail > communication, feel free to write me at bitcoin [at] upalc.com. > > --089e0122eda89db35a051d8082c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Words cannot capture how much I wish Satoshi had put logic like this (or e= ven just a simple block size doubling every reward halving) in place when h= e put in the "temporary" 1MB anti-spam block size limit...
<= div>
I see problems to this approach.=C2=A0 The biggest one I= see is that a miner with 11% of hash power could sabotage block size incre= ases by only ever mining empty blocks.

I haven'= ;t run any statistics or simulations, but I'm concerned that the interp= lay between the random distribution of transaction arrival and the random d= istribution of block times may lead to false signals.

<= div>A 90% full block 1 minute after the previous block is a more "seri= ous" problem than a 90% full block 30 minutes after the previous block= .=C2=A0 A 90% full block after a 90% full block is a more "serious&quo= t; problem than a 90% full block after an empty block.

=
I would expect a robust approach in this manner to look at block sizes= weighted by block times, but this is an interesting proposal regardless.

But I think you'll run up against one of the gr= eat schisms in this debate - those that believe blocks should always be ful= l (or close to it), to encourage a "fee market" and to encourage = off-chain transactions, and those that think that the blockchain should be = useable by almost anyone for almost anything, implying there should always = be spare space in blocks, with off-chain transactions reserved for microtra= nsactions and zero-conf (and possibly low-fee transactions).=C2=A0 At least= , that's my take on it.

Rodney

<= /div>
=C2=A0


Date: Mon, 17 Aug 2015 11:51:26 +0100
From: Btc Drak <btcdrak@gmail.com>
To: Patrick Strateman <pa= trick.strateman@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Max Cap
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CADJgMzvV7cSW9aBnAf5zX7FDxN5E=3DAW=3DrET2i9= EnysLao=3DvVyw@mail.gmail.com>= ;
Content-Type: text/plain; charset=3D"utf-8"

On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev < bitcoin-dev@lists.= linuxfoundation.org> wrote:
> Nobody is going to click that...

I guess I am nobody. Here's a copy of the text:-

*Dynamically Controlled Bitcoin Block Size Max Cap
<http://upalc.com/maxblocksize.php>*

*Assumption*: This article is for those, who already understand the bitcoin=
protocol and aware of the block size controversy. Details of the problem statement can be found in BIP 100
<http://gtf.org/garzik/bitcoin/BI= P100-blocksizechangeproposal.pdf>.
Satoshi's opinion regarding block size can be found here
<https://bitcointalk.org/index.ph= p?topic=3D1347.msg15366#msg15366>. I will be
directly going into the solution without explaining the problem in details.=


*Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
block each full node does a calculation to find the next target. We will do=
just another calculation here. Nodes will also calculate what % of blocks in the last difficulty period is higher than 90% of the maximum block size,=
which is 1 MB for now. If it is found that more than 90% blocks in the last=
difficulty period is higher than 90% of the maximum block size, then double=
the maximum block size. If not, then calculate what % of blocks in the last=
difficulty period is less than 50% of the maximum block size. If it is
higher than 90%, then half the maximum block size. If none of the above
condition satisfies, keep the maximum block size as it is.

Please note that, while calculating the % of blocks, it is better to take into account the first 2000 of the 2016, than the whole of 2016. This helps=
to avoid the calculation mistake if some of the last few blocks get
orphaned.


*Reasoning*: This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger=
blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool.
Hence, if block size is itself taken into consideration, then maximum block=
size can most rationally be derived. Moreover, this solution not only
increases, but also decreases the maximum block size, just like difficulty.=


*Other Solutions of this Problem*:-

Making Decentralized Economic Policy
<http://gtf.org/garzik/bitcoin/BI= P100-blocksizechangeproposal.pdf> - by
Jeff Garzik

Elastic block cap with rollover penalties
<https://bitcointalk.org/index.php?topic=3D10785= 21> ? by Meni Rosenfeld

Increase maximum block size
<https://github.com/bitcoin/bips/bl= ob/master/bip-0101.mediawiki> - by Gavin
Andresen

Block size following technological growth
<https://gist.github.com/sipa/c65665fc360ca7a176= a6> - by Pieter Wuille

The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
<https://lightning.network/lightning-netwo= rk-paper.pdf> - by Joseph Poon &
Thaddeus Dryja


Please share your opinion regarding this solution below. For mail
communication, feel free to write me at bitcoin [at] upalc.com.

--089e0122eda89db35a051d8082c6--