Message-ID: <5588807B.7030400@gmail.com>
Date: Mon, 22 Jun 2015 14:39:07 -0700
From: Patrick Strateman <patrick.strateman@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
References: <dd09d1e5-57fb-46ef-8bc0-0fdccf9e7abb@me.com>	<20150622205420.GA8892@savin.petertodd.org>
	<CABsx9T2FxNEEUx7_ZRf2NpQk1fdqMKtfzccX-duBjOn-ksS0cg@mail.gmail.com>
In-Reply-To: <CABsx9T2FxNEEUx7_ZRf2NpQk1fdqMKtfzccX-duBjOn-ksS0cg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------020804050407050102040706"
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Precedence: list

This is a multi-part message in MIME format.
--------------020804050407050102040706
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

If you truly have a consensus then the rational behavior is to
permanently change the nodes behavior after the trigger.

On 06/22/2015 02:21 PM, Gavin Andresen wrote:
> On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd <pete@petertodd.org
> <mailto:pete@petertodd.org>> wrote:
>
>     > Since it's possible that block timestamps aren't chronological
>     in order, what would happen if a block following a size increase
>     trigger is back in the past before the size increase? Would that
>     block have a lower size restriction again? Would using block
>     height not be a more stable number to work with?
>
>     In the nVersion bits proposal that I co-authored we solved that
>     issue by
>     comparing the timestamp against the median time, which is
>     guaranteed by
>     the protocol rules to monotonically advance.
>
>
> That complicates the implementation quite a bit.
>
> I mostly implemented a variant that replaced the MAX_BLOCK_SIZE
> constant with a function that took both a timestamp and a block
> height, and there are several places in the current reference
> implementation where digging out the block height (or, worse,
> calculating the median timestamp for the block) would involve changing
> quite a few functions in the call-chain or acquiring the cs_main lock
> to consult the current best chain.
>
> -- 
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------020804050407050102040706
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    If you truly have a consensus then the rational behavior is to
    permanently change the nodes behavior after the trigger.<br>
    <br>
    <div class="moz-cite-prefix">On 06/22/2015 02:21 PM, Gavin Andresen
      wrote:<br>
    </div>
    <blockquote
cite="mid:CABsx9T2FxNEEUx7_ZRf2NpQk1fdqMKtfzccX-duBjOn-ksS0cg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Mon, Jun 22, 2015 at 4:54 PM,
            Peter Todd <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div class="HOEnZb">
                <div class="h5">&gt; Since it's possible that block
                  timestamps aren't chronological in order, what would
                  happen if a block following a size increase trigger is
                  back in the past before the size increase? Would that
                  block have a lower size restriction again? Would using
                  block height not be a more stable number to work with?<br>
                  <br>
                </div>
              </div>
              In the nVersion bits proposal that I co-authored we solved
              that issue by<br>
              comparing the timestamp against the median time, which is
              guaranteed by<br>
              the protocol rules to monotonically advance.<br>
            </blockquote>
            <div><br>
            </div>
            <div>That complicates the implementation quite a bit.</div>
            <div><br>
            </div>
            <div>I mostly implemented a variant that replaced the
              MAX_BLOCK_SIZE constant with a function that took both a
              timestamp and a block height, and there are several places
              in the current reference implementation where digging out
              the block height (or, worse, calculating the median
              timestamp for the block) would involve changing quite a
              few functions in the call-chain or acquiring the cs_main
              lock to consult the current best chain.</div>
          </div>
          <div><br>
          </div>
          -- <br>
          <div class="gmail_signature">--<br>
            Gavin Andresen<br>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------020804050407050102040706--