Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2B1077D for ; Fri, 25 Mar 2016 18:48:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com [209.85.213.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 731C513D for ; Fri, 25 Mar 2016 18:48:16 +0000 (UTC) Received: by mail-vk0-f46.google.com with SMTP id e6so99306491vkh.2 for ; Fri, 25 Mar 2016 11:48:16 -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; bh=JuadOQc526gvmYGw+8e6d3qexz/sDlNx/SnJD/9/cwE=; b=OCqynT3fEbzTjW+ImqvQKH1Tv20Y59e/41cbv3F+wEhOufxcWnGa3iNkYhoOhVzwQ6 1kFd8E3uFFha0dBjvPYjV7E1o4TMFYZrOox8ACv/EatstwJ0p5c8GF7qe2MJVryxfZM0 KVRWdprZ6YLLbRZfug+bPSLOg3N8fus+r4AbUJYiVkXVScbMAm8ZdPPq3ZvUX5BlbzJX T2+NbAsAEbCzjdSAH3BksgGKGDoJ+/KDXxsEvz5KwIWb7t+yco+cCsfbEm1xRZED8cj/ yIvWefJw8WwFjiX5/NV5SbI728vlZbSwWCnvMsS93SBOPHW0XrBou/Zn2G5JR59/C1Wj zweQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc; bh=JuadOQc526gvmYGw+8e6d3qexz/sDlNx/SnJD/9/cwE=; b=QA0YH+UIZsvvDQorASZu99W6HOGrAWjGyU/fg2RtuTvH+x6dkmGgmhnATcndGvhva2 IBT+tATlvYFwFtDA4q8+yqifbQ7yCJxw12RyBWluEEmryte6Uo2mnR4V4koj31zn7w7B n8QrApPiUaOhrmoor17oCj9rYnwc/Rk/c01czqB/aZZ2atZGw0XaaOUjd8Qus6dcFwen fC4nShpgvipnBbnge1bliE3SGYYPu4vSmaAulYq4kfpDQWXNSW4VTO1SYhNbm2xK4PMM QB5Z4AAWBfCKsj1RSmeckVNuA5SqGCv+Bqx2Y3nTi7irBPBw4wxvld24Kn1cfoPTGFRg rH7w== X-Gm-Message-State: AD7BkJKTOq7oYyWx0179wU8+RBEgkVwFaEmdLXiUgsTqQdTUDcJMdEk7ImSrAz2/WXmcWhFgDu1AlbzYRp9bOw== MIME-Version: 1.0 X-Received: by 10.31.150.215 with SMTP id y206mr7841320vkd.63.1458931695754; Fri, 25 Mar 2016 11:48:15 -0700 (PDT) Received: by 10.176.2.108 with HTTP; Fri, 25 Mar 2016 11:48:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Mar 2016 18:48:15 +0000 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1140fdd87a21da052ee401e7 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 X-Mailman-Approved-At: Fri, 25 Mar 2016 18:55:37 +0000 Subject: Re: [bitcoin-dev] Proposed BIP: Maximum block size consensus rule based on median block size (adaptive block size) 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: Fri, 25 Mar 2016 18:48:17 -0000 --001a1140fdd87a21da052ee401e7 Content-Type: text/plain; charset=UTF-8 I think you will have a hard time getting something related to block size accepted in the current climate. Using floating point calculations in consensus code is a bad idea. The standard practice is to use very large integers to fake it. That has the advantage that it is exact. You don't even need to do this here. Your get median function could just as easily use an array of integers. You are dividing by 2.0 and then getting casting it to int after using a floor function. The standard integer divide by 2 does that automatically. The median function is sufficiently defined that I don't think you need the exact function (especially if you use integers). Since the block size has to be an integer, even if the size was 1,234,567.5, the limit would still be 1,234,567. It would likely help to gain acceptance if you added a 2nd limiter to the growth rate. For example, you could make it so that the size isn't allowed to more than double every year. This is similar to the 1MB limit on the lower end. A 45 day doubling time (granted subject to miner veto) is likely unacceptable. Miners could spam max size blocks by filling them with transactions created for that purpose. The graphs likely understate the growth rate, since the 1MB limit inherently restricts things to 1MB. On Fri, Mar 25, 2016 at 5:27 PM, Chris Kleeschulte via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The following draft BIP proposes changing the MAX_BLOCK_SIZE consensus > rule to be a function of the median block size over the last 12,960 blocks > (about three months) multiplied by 2 and calculated when a block is > connected to the blockchain. > > Motivation: > > The purpose of this consensus rule change is to allow the maximum block > size to increase or decrease based on actual network usage. A block size > limit, as discussed here, prevents certain types of denial of service > attacks on the Bitcoin network, however a fixed limit does not allow the > capacity of the network to increase as advancements in scaling are > realized. By adjusting the limit based on the sizes of blocks in the > recent past, the throughput of the network can adjust to changes in user > demand and scaling related technology advancements while still being > protected from denial of service attacks. > > > Full proposal here: > > https://github.com/bitpay/bips/blob/master/bip-adaptiveblocksize.mediawiki > > I look forward to your consideration. > > thank you, > -- > Chris Kleeschulte > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1140fdd87a21da052ee401e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think you will have a hard time= getting something related to block size accepted in the current climate.
Using floating point calculations in consensus code is a bad id= ea.=C2=A0 The standard practice is to use very large integers to fake it.= =C2=A0 That has the advantage that it is exact.=C2=A0 You don't even ne= ed to do this here.

Your get median function could just as eas= ily use an array of integers.=C2=A0 You are dividing by 2.0 and then gettin= g casting it to int after using a floor function.=C2=A0 The standard intege= r divide by 2 does that automatically.

The median function is = sufficiently defined that I don't think you need the exact function (es= pecially if you use integers).=C2=A0

Since the block size has to be= an integer, even if the size was 1,234,567.5, the limit would still be 1,2= 34,567.

It would likely help to gain acceptance if you added a= 2nd limiter to the growth rate.=C2=A0 For example, you could make it so th= at the size isn't allowed to more than double every year.=C2=A0 This is= similar to the 1MB limit on the lower end.=C2=A0 A 45 day doubling time (g= ranted subject to miner veto) is likely unacceptable.=C2=A0 Miners could sp= am max size blocks by filling them with transactions created for that purpo= se.

The graphs likely understate the growth rate, since the 1M= B limit inherently restricts things to 1MB.

On Fri, Mar 25, 2016 at 5:27 PM, Chris = Kleeschulte via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
The following draft BIP proposes changing the MAX_BLOCK_SIZE con= sensus rule to be a function of the median block size over the last 12,960 = blocks (about three months) multiplied by 2 and calculated when a block is = connected to the blockchain.

Motivation:

<= /div>
The purpose of this consensus rule change is to allow the maximum= block size to increase or decrease based on actual network usage. A block = size limit, as discussed here, prevents certain types of denial of service = attacks on the Bitcoin network, however a fixed limit does not allow the ca= pacity of the network to increase as advancements in scaling are realized.= =C2=A0 By adjusting the limit based on the sizes of blocks in the recent pa= st, the throughput of the network can adjust to changes in user demand and = scaling related technology advancements while still being protected from de= nial of service attacks.


Full propo= sal here:

https://gi= thub.com/bitpay/bips/blob/master/bip-adaptiveblocksize.mediawiki

I look forward to your consideration.

=
thank you,
<= div>--
Chris Kleeschulte


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


--001a1140fdd87a21da052ee401e7--