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 3AE8B40D for ; Sat, 10 Dec 2016 23:12:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C8C0513B for ; Sat, 10 Dec 2016 23:12:26 +0000 (UTC) Received: by mail-io0-f175.google.com with SMTP id p42so120563241ioo.1 for ; Sat, 10 Dec 2016 15:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bittorrent-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=r2ZeL3VC3MwHwVD8mSSx59FWGmF+GZo6BO8GG9xJAu8=; b=nQcN925AxZVlEJaaa+7juKSz/tu/0ZlCEhN65HDi4hWSonXo1X3ZA8PF14cAx6qfEq Mvi9hgGnLwflK7kxzWVf/nZwNlzqy2j0umhtwVuC5tb7II91MJSU/61L3QdqVptyQpPH ZpFGWIv/jtq814FqnsUYPA5GzEyU5d2UarhpIsaChPYv9ndAnI+MPGpgmHdNciMA9Yl8 htvBrLJUChrczUR/VXHoe5gSvVnbNPXJ9SQQt9cGQcswGZITwdQLma5sGqIgaYcgerrA rS41mp2/fg+BwXpwEnSUdWOo2cGvUAqD1ciq6A1RGL+G+NJ+9Au6F2l0QLX1WWC4pmi3 stXw== 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:from:date :message-id:subject:to; bh=r2ZeL3VC3MwHwVD8mSSx59FWGmF+GZo6BO8GG9xJAu8=; b=XQX3BRWRt4xNgh2wJ6JIlByuWsYoeRR3brBWEeImGLouqiFyh+lOENy/RUXyaEXjDb sVe/h+Ct86I+dVbO4MOLiUkNXNfVSLXMwkw0X7Us1oXvo2epjFoIagek3vhI7eKFJRnB bXLMnl2U8sCsXjGTScvMkVDykRtFQA5oeluu6ZN8AYJj15tyLeMVJkucANbleDFJLK9w 4g3A+Wb8LavZvyNJYzVhTHrwozxrJ7aAoTHCAarslUbhSA/XuxJ4vtB7xdfN26lSP005 WjdxGzZvJ3LV8ZnEl7MEv1Cpniu/wTRLS97vS6L+w09Y2B793zgdPKfekqOjTjmy6yMB 0D6g== X-Gm-Message-State: AKaTC03ABA4I0npM8gijP2QHWNV5CtGh0INxtPvvNtneuveYNzKoLMe0yd74xl8K21aEumjmpjTGoj4GYeprlLjt X-Received: by 10.107.136.164 with SMTP id s36mr76471882ioi.214.1481411546227; Sat, 10 Dec 2016 15:12:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.224.199 with HTTP; Sat, 10 Dec 2016 15:12:25 -0800 (PST) In-Reply-To: References: From: Bram Cohen Date: Sat, 10 Dec 2016 15:12:25 -0800 Message-ID: To: "t. khan" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a113eb2c2fabbcc054356004a X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM 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] Managing block size the same way we do difficulty (aka Block75) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 23:12:27 -0000 --001a113eb2c2fabbcc054356004a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Put another way: let=E2=80=99s stop thinking about what the max block siz= e should > be and start thinking about how full we want the average block to be > regardless of size. Over the last year, we=E2=80=99ve had averages of 75%= or > higher, so aiming for 75% full seems reasonable, hence naming this concep= t > =E2=80=98Block75=E2=80=99. > That's effectively making the blocksize limit completely uncapped and only preventing spikes, and even in the case of spikes it doesn't differentiate between 'real' traffic and low value spam attacks. It suffers from the same fundamental problems as bitcoin unlimited: There are in the end no transaction fees, and inevitably some miners will want to impose some cap on block size for practical purposes, resulting in a fork. Difficulty adjustment works because there's a clear goal of having a certain rate of making new blocks. Without a target to attempt automatic adjustment makes no sense. --001a113eb2c2fabbcc054356004a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= itcoin-dev@lists.linuxfoundation.org> wrote:

Put another way: let= =E2=80=99s stop thinking about what the max block size should be and start = thinking about how full we want the average block to be regardless of size.= Over the last year, we=E2=80=99ve had averages of 75% or higher, so aiming= for 75% full seems reasonable, hence naming this concept =E2=80=98Block75= =E2=80=99.

That= 's effectively making the blocksize limit completely uncapped and only = preventing spikes, and even in the case of spikes it doesn't differenti= ate between 'real' traffic and low value spam attacks. It suffers f= rom the same fundamental problems as bitcoin unlimited: There are in the en= d no transaction fees, and inevitably some miners will want to impose some = cap on block size for practical purposes, resulting in a fork.
Difficulty adjustment works because there's a clear goal o= f having a certain rate of making new blocks. Without a target to attempt a= utomatic adjustment makes no sense.
--001a113eb2c2fabbcc054356004a--