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 C57F61243 for ; Thu, 3 Sep 2015 03:38:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E63D1143 for ; Thu, 3 Sep 2015 03:38:34 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so5556376wic.1 for ; Wed, 02 Sep 2015 20:38:33 -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:to :cc:content-type; bh=FDQIlD5i5p8pVt0chsGMmonXOtxd5ki0P00akFVB5YU=; b=wXu1Or5t+f0mR9832NB6j/+pK/3yd7+jLttaTgORf50xpOJElko4jCz+lOXjxTTWYH fphagK+EzqDKQAO9egHla02PnxX9Mxljd6kEgsY8y7RGqRNTRzKdU59KoLjHwfYVXsaO PafYUnyJbHPM+oFZRLrzuQhIW2hodb7lNwi2QhcA55mdLmePRWKVpJ3orAI/NwLrA74k Y8rC44tf6nio0rgFba5dyj7UByP8t+pazMM8dJFAfsG9dqSKX/M8Q9/E2zbezgUeBvh6 we69D78eMCyw0OXtgrQzTGiqEIW5SRIBtojhhf2dqJTZKtIOkKLVJ+HElnWsR4nMdnbs nzvw== MIME-Version: 1.0 X-Received: by 10.180.75.11 with SMTP id y11mr10364524wiv.46.1441251513582; Wed, 02 Sep 2015 20:38:33 -0700 (PDT) Received: by 10.28.15.11 with HTTP; Wed, 2 Sep 2015 20:38:33 -0700 (PDT) In-Reply-To: <201509030017.43036.luke@dashjr.org> References: <201509030017.43036.luke@dashjr.org> Date: Wed, 2 Sep 2015 23:38:33 -0400 Message-ID: From: Jeff Garzik To: Luke Dashjr Content-Type: multipart/alternative; boundary=f46d043c7cd87fc920051ecf8449 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 Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP 100 repo 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: Thu, 03 Sep 2015 03:38:35 -0000 --f46d043c7cd87fc920051ecf8449 Content-Type: text/plain; charset=UTF-8 Luke, - Definitely agree with most of your suggestions on the practical side; several clarification could be made. - The power to decrease the hard limit appears riskier long term in my analysis. This is mitigated somewhat by the ease at which miners may locally or collectively lower the block size at any time, without a vote. On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr wrote: > On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev > wrote: > > The repo: https://github.com/jgarzik/bip100 > > What is the purpose of the newly added 1 MB floor? It seems clear from the > current information available that 1 MB is presently too high for the > limit, > and it is entirely one-sided to only allow increases when decreases are > much > more likely to be needed in the short term. > > Must the new size limit votes use 11 bytes of coinbase? Why not just use a > numeric value pushed after height? Since this is a hardfork, I suggest > increasing the coinbase length to allow for 100 bytes *in addition* to the > pushed height and size-vote. > > I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32 > MB > (or whatever value is deemed appropriate) to make it clear that the limit > remains a part of the consensus protocol and p2p protocol limits are not to > have an effect on consensus rules. > > Furthermore, I suggest modifying the voting to require 50% to set the limit > floor. This has the effect of merely coordinating what miners can already > effectively do today by rejecting blocks larger than some collusion- > determined limit. > > Thoughts? > > Luke > --f46d043c7cd87fc920051ecf8449 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Luke,

- Definitely agree with most of y= our suggestions on the practical side; several clarification could be made.=
- The power to decrease the hard limit appears riskier long term in my= analysis.=C2=A0 This is mitigated somewhat by the ease at which miners may= locally or collectively lower the block size at any time, without a vote.<= /div>


On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <luke@dashjr.or= g> wrote:
On Wednesday, Sep= tember 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
wrote:
> The repo: https://github.com/jgarzik/bip100

What is the purpose of the newly added 1 MB floor? It seems clear from the<= br> current information available that 1 MB is presently too high for the limit= ,
and it is entirely one-sided to only allow increases when decreases are muc= h
more likely to be needed in the short term.

Must the new size limit votes use 11 bytes of coinbase? Why not just use a<= br> numeric value pushed after height? Since this is a hardfork, I suggest
increasing the coinbase length to allow for 100 bytes *in addition* to the<= br> pushed height and size-vote.

I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to = 32 MB
(or whatever value is deemed appropriate) to make it clear that the limit remains a part of the consensus protocol and p2p protocol limits are not to=
have an effect on consensus rules.

Furthermore, I suggest modifying the voting to require 50% to set the limit=
floor. This has the effect of merely coordinating what miners can already effectively do today by rejecting blocks larger than some collusion-
determined limit.

Thoughts?

Luke

--f46d043c7cd87fc920051ecf8449--