Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7601640D for ; Sun, 11 Dec 2016 00:53:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C35C814B for ; Sun, 11 Dec 2016 00:52:59 +0000 (UTC) Received: by mail-vk0-f53.google.com with SMTP id p9so26074311vkd.3 for ; Sat, 10 Dec 2016 16:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ukPpIi6SxnU6sC36T+VIwjHQhH6odsFNesHU6DBUGeU=; b=LLMstDGIGL41+M1O7Yoywo0Vduo0ZFJz9c4EZw/Dd/xnv8DpHHD/dGnVvi15tidyhA 0/eogc/dDFbrqKkUaAIiTK2ERsv82pKiB6GH35LZzU761XxmTJnrPv11NmAHbfZy2NoI kO5N3xMAFERSgHfN/+iGA2sPUKH2x1CsJ1LfVW3fn1KLrHeiPo0c6I+5FPn/zEjLTONb jFVX0ZNiW4MRH2fem71ZS22sZ4zNrWoZ1geL9tY/bwrgIdRdirKT68RPgOr1TtKExLin scB8vOdtPQQ47AZkg+XQ7RqLvczXNe01YdUBXvKqfiDtNX3F1uCe1XqDOeubB/yOoGxM I9hw== 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:cc; bh=ukPpIi6SxnU6sC36T+VIwjHQhH6odsFNesHU6DBUGeU=; b=Fb0baVhT9r+8eQog3L8EBXrTvCVu+j2DcSwPkZXYfGhy2E3qhlZnG8lBuol+gW6Ors fir0TRQJRp5qiWTExHPf47mmTyzoPVtjRCwR5h4pfrReFobcN5xkiUnpg1q9E0jv9Ds3 x/aXt2u1ZctNc5JZuEh271U3Y7KIllp3FI9j3KrJqsiLAovF8XfcXIzP+HUch55kkZkl btcNKFSALVRs+bMBgcjML96U/ntdeFiqy1zFjWHkr9FIYOuIQ/L4qjaz/vpUF7o/QJGL UXVqRY73v771D9F6tik+JwSOk5aYSY6dvofWm6NSQOizKGT9zlUN7rtQaTsSUI4vxHJw dExw== X-Gm-Message-State: AKaTC033H2ZSmw/fPgb+aPmtKoz6O59zvYSmRJ1Q/cshNqhtb600JsBVchfjpxItqDrTE9NjhMycL5xAJ8zyOQ== X-Received: by 10.31.65.3 with SMTP id o3mr28021133vka.3.1481417578998; Sat, 10 Dec 2016 16:52:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.49.144 with HTTP; Sat, 10 Dec 2016 16:52:58 -0800 (PST) In-Reply-To: References: From: "t. khan" Date: Sat, 10 Dec 2016 19:52:58 -0500 Message-ID: To: Bram Cohen Content-Type: multipart/alternative; boundary=001a114dd3f48f731e0543576803 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE 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: Sun, 11 Dec 2016 00:53:50 +0000 Cc: Bitcoin Protocol Discussion 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: Sun, 11 Dec 2016 00:53:00 -0000 --001a114dd3f48f731e0543576803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed, the clear goal of 10 minutes per block is why the difficulty adjustment works well. Blocks averaging 75% full is the clear goal of the described method. That's the target to attempt. Under Block75, there will still be full blocks. There will still be transaction fees and a fee market. The fees will be lower than they are now of course. Hardcoding a cap will inevitably become a roadblock (again), and we'll be back in the same position as we are now. Permanent solutions are preferred. On Sat, Dec 10, 2016 at 6:12 PM, Bram Cohen wrote: > 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 si= ze 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 conce= pt >> =E2=80=98Block75=E2=80=99. >> > > That's effectively making the blocksize limit completely uncapped and onl= y > preventing spikes, and even in the case of spikes it doesn't differentiat= e > between 'real' traffic and low value spam attacks. It suffers from the sa= me > 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. > --001a114dd3f48f731e0543576803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed, the clear goal of 10 minutes per block is why the = difficulty adjustment works well. Blocks averaging 75% full is the clear go= al of the described method. That's the target to attempt.

Under Block75, there will still be full blocks.=C2=A0There will still= be transaction fees and a fee market. The fees will be lower than they are= now of course.

Hardcoding a cap will inevitably b= ecome a roadblock (again), and we'll be back in the same position as we= are now. Permanent solutions are preferred.
=
On Sat, Dec 10, 2016 at 6:12 PM, Bram Cohen = <bram@bittorrent.com> wrote:
On Mon= , Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev <bit= coin-dev@lists.linuxfoundation.org> wrote:

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

That's= effectively making the blocksize limit completely uncapped and only preven= ting spikes, and even in the case of spikes it doesn't differentiate be= tween 'real' traffic and low value spam attacks. It suffers from th= e same fundamental problems as bitcoin unlimited: There are in the end no t= ransaction 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 havi= ng a certain rate of making new blocks. Without a target to attempt automat= ic adjustment makes no sense.

--001a114dd3f48f731e0543576803--