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 7E0A2259 for ; Mon, 2 Jan 2017 20:41:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com [209.85.217.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EA58314C for ; Mon, 2 Jan 2017 20:41:43 +0000 (UTC) Received: by mail-ua0-f175.google.com with SMTP id 88so302818313uaq.3 for ; Mon, 02 Jan 2017 12:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SisfE1E8VE44Ma6mDI4eHmBASd/9zH4ZzVpzPmVHPc0=; b=U8Hc93Ok/3fHf1DNeOSlAkfMafjZd335/lBjTFVzh5uF3Vy31GR9PiLzQe+2v5RaNM 5QfEvf1YQ6vCHgg8Lnp+tvNexg9mznmPeBITljzZmKiptRaHYiu8XV/fsHtcEqgIJIQj IBqX2+2sVubLd4lsSx/X2xPyQzJ5NZJk1Vpu2xSs2um/MjX/rAQ//tw3GDuqPoUhB3Rp o33gCQmsyIBWrvcsi4GtXye7ZII3OOx3tROUFavVJXJ9s/IWlCi6q98UEzHBmT155esr +M5pMTSA5my6+Gdc9n7HbIxEjSr95cnbFlEgXJZf6j6DMXosCw5PW9n2XimK53seguFc pLgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SisfE1E8VE44Ma6mDI4eHmBASd/9zH4ZzVpzPmVHPc0=; b=oJKMhPIOansc7qxLHkP941xTddYW3/EofsUF9deKkdQkY4tIS2baQSa4/Wtrc5mD8J OP8pUd51nQQvpg9VCU/6kwtaefW/ToKQAZnpFLsMLboEvIvHG95JbaHSslRpbXbqQZSV LmgqvTHeCMI2VnmAkwK+8kjT2LGUrLE19R583EJ+1HHh2kmUPqDFTHZvVa+7llDF9Cfq /KMyeot9AvlF2P1hOEfo25icn6rgBiTXBj2bB3fUIh78VTuCLDKHMfB0SHnMTiYS5WuM 8ZXhapuEta2x+6Bk8mob6vLZ1GjNalzXQceotuFC//n2WdVj6/EYnMJ2IApZyr9emUwL Km0A== X-Gm-Message-State: AIkVDXIThziQJG/f3f7ac5nhqans/LwFMvW5dSvi+tgWN7411ur1BFezs97z0L5ug6drSmO2ruNv2WDTfaONyA== X-Received: by 10.159.48.203 with SMTP id k11mr42259784uab.42.1483389703140; Mon, 02 Jan 2017 12:41:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.49.144 with HTTP; Mon, 2 Jan 2017 12:41:42 -0800 (PST) In-Reply-To: <201701022004.57540.luke@dashjr.org> References: <201701022004.57540.luke@dashjr.org> From: "t. khan" Date: Mon, 2 Jan 2017 15:41:42 -0500 Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary=f403045e34f451cf6d0545229475 X-Spam-Status: No, score=-1.2 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, 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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 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: Mon, 02 Jan 2017 20:41:44 -0000 --f403045e34f451cf6d0545229475 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 2, 2017 at 3:04 PM, Luke Dashjr wrote: > It would probably behave as an ever-increasing block size limit. Spam has > typically filled blocks to the max, and miners have stopped self-enforcing > reasonable limits. Using the growth rate over the last year as a model ( https://blockchain.info/charts/avg-block-size?daysAverageString=14 ), Block75 would also have frequently decreased the limit. Though, yes, more transactions would equal larger blocks over time, but that's the entire point of this. What is your definition of "spam"? Also, can you point to data that supports the hypothesis that spam is filling blocks? > I doubt you'll get consensus for such a fundamentally broken proposal. > I certainly don't foresee any circumstance where I could reasonably support > it... The block size limit exists to restrict miners; it makes no sense to > put > it in their control. > Specifically, what is broken about it? There would still be a block size limit, it would just change slightly every two weeks. I agree that miners shouldn't have control of this, and Block75 doesn't give them any (at least none they can make a profit on). - t.k. --f403045e34f451cf6d0545229475 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 2, 2017 at 3:04 PM, Luke Dashjr <luke@dashjr.or= g> wrote:
It would probably behave as an ever-increasing block= size limit. Spam has
typically filled blocks to the max, and miners have stopped self-enforcing<= br> reasonable limits.

Using the growth rate ov= er the last year as a model ( https://blockchain.info/charts/avg-bloc= k-size?daysAverageString=3D14 ), Block75 would also have frequently dec= reased the limit. Though, yes, more transactions would equal larger blocks = over time, but that's the entire point of this.

What is your definition of "spam"? Also, can you point to data = that supports the hypothesis that spam is filling blocks?
=C2=A0<= /div>
I doubt you'll get consensus for such a fundament= ally broken proposal.
I certainly don't foresee any circumstance where I could reasonably sup= port
it... The block size limit exists to restrict miners; it makes no sense to = put
it in their control.

Specifically, what= is broken about it?

There would still be a block = size limit, it would just change slightly every two weeks. I agree that min= ers shouldn't have control of this, and Block75 doesn't give them a= ny (at least none they can make a profit on).

- t.= k.
--f403045e34f451cf6d0545229475--