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 009B693E for ; Mon, 22 Jun 2015 21:21:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26825188 for ; Mon, 22 Jun 2015 21:21:42 +0000 (UTC) Received: by lagi2 with SMTP id i2so28415194lag.2 for ; Mon, 22 Jun 2015 14:21:40 -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=5rCmzgP5djzqCpEN2OGQ5wbl5BSE5qToc84IEKUjtLo=; b=X+WRf2vuTwttJpxBtFLqXL5QddRdevQI19PfvcXIWt40+qfI0ps2Po1kj9iLfOxP0w yKLyQyESSZp/B82W6Rv7uWdGQH6AxIjNYVezcpjnGqZ/1LfcE+cb51AdTp8NueySjra7 KY9MKWz88FXfSducqsct6dYVUD2hryurUemlw/mYTAOp6BzuzJn3mwpIGF6InAcMSgAF wotkQjJjUZdfwq2lS93e1lp/kDhRzFlwtu34aM7bM8Xrs42b+o9xPaJvA7dj72PSWMxY Om66sRDDhH/gJ3uVofPvWwIp0Fp/7NdHPXe6TBp+dJFMC+HZ9MyW35NIu39No44yHXet S9SQ== MIME-Version: 1.0 X-Received: by 10.112.210.9 with SMTP id mq9mr31907519lbc.4.1435008100423; Mon, 22 Jun 2015 14:21:40 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Mon, 22 Jun 2015 14:21:40 -0700 (PDT) In-Reply-To: <20150622205420.GA8892@savin.petertodd.org> References: <20150622205420.GA8892@savin.petertodd.org> Date: Mon, 22 Jun 2015 17:21:40 -0400 Message-ID: From: Gavin Andresen To: Peter Todd Content-Type: multipart/alternative; boundary=001a11c3c842135f3b051921dca5 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-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase 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: Mon, 22 Jun 2015 21:21:43 -0000 --001a11c3c842135f3b051921dca5 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd 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 --001a11c3c842135f3b051921dca5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 22, 2015 at 4:54 PM, Peter Todd <pete@petertodd.org> wrote:
> Since it's possible that block timestamps aren't chron= ological in order, what would happen if a block following a size increase t= rigger 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 stab= le 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 consta= nt with a function that took both a timestamp and a block height, and there= are several places in the current reference implementation where digging o= ut the block height (or, worse, calculating the median timestamp for the bl= ock) would involve changing quite a few functions in the call-chain or acqu= iring the cs_main lock to consult the current best chain.
<= br>
--
--
Gavin Andresen
--001a11c3c842135f3b051921dca5--