public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 100 repo
Date: Wed, 2 Sep 2015 23:38:33 -0400	[thread overview]
Message-ID: <CADm_WcapYX+4wqd+6JLALt9FLJif8EL3v4dmuGHO5rnhTHpJSw@mail.gmail.com> (raw)
In-Reply-To: <201509030017.43036.luke@dashjr.org>

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

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 <luke@dashjr.org> 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
>

[-- Attachment #2: Type: text/html, Size: 2191 bytes --]

  reply	other threads:[~2015-09-03  3:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-02 23:51 [bitcoin-dev] BIP 100 repo Jeff Garzik
2015-09-02 23:58 ` Jeff Garzik
2015-09-03  0:17   ` Luke Dashjr
2015-09-03  3:38     ` Jeff Garzik [this message]
2015-09-03  4:09     ` Jeff Garzik
2015-09-03  4:55       ` Benjamin
2015-09-03  6:41   ` odinn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADm_WcapYX+4wqd+6JLALt9FLJif8EL3v4dmuGHO5rnhTHpJSw@mail.gmail.com \
    --to=jgarzik@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox