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 A22C5416 for ; Thu, 23 Jul 2015 11:24:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7E63417B for ; Thu, 23 Jul 2015 11:24:54 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so144230583wib.1 for ; Thu, 23 Jul 2015 04:24:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EYq1dXBGu6YDGff2c+c/CjkCP+cmpD7xRdwyTBBrl6Y=; b=MY+CA1sZh4P9pCd64hLF0OY9cWjP9hFjw0mvF1UhoCjsVts2Zlbgf9tjUowoycsUOV 4KRw7sFoSTQ88OFHajx9Qfq1bnC84CPjmkBJjgKSX2prr3O64ASo/59tu4BYn693c/ph QnuGEoRcQRXZl2G8bNhEZxz2dzYIs8+nGUwfK5YF+lZE2+Fjx0DqgsMKo/RV3SNEuhNY gUNE18XENUfpu9eIWNHtu8t+ASN6gdASJyWcI/2C6Z4mUxjAShQk61JM9ncUn/+x3Ak2 MM7zDKx7edIppdOxKhWxW374A4SNwcItIDBWkWP6Xyu7z9tBGUdUKXYmccP3AjV8FcI4 IZYQ== X-Gm-Message-State: ALoCoQlas84myeZm/lnhtg9Hvjl0mkNXPVt0jKNwaadGARFFbEGyBFk6ION55JGOP0O9FEUAHVhv MIME-Version: 1.0 X-Received: by 10.180.109.6 with SMTP id ho6mr52213703wib.58.1437650692936; Thu, 23 Jul 2015 04:24:52 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 04:24:52 -0700 (PDT) In-Reply-To: <55AEC21A.3090302@jrn.me.uk> References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <55AEC21A.3090302@jrn.me.uk> Date: Thu, 23 Jul 2015 13:24:52 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Ross Nicoll Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] BIP 102 - kick the can down the road to 2MB 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, 23 Jul 2015 11:24:55 -0000 Peter Todd, as discussed on IRC, I'm not opposed to median time, which has many of the properties nheight has, I'm just opposed to just using nTime which is what all "hardfork proposals" I've seen so far (including this one) do. On Wed, Jul 22, 2015 at 12:05 AM, Ross Nicoll wrote: > On 21/07/2015 10:26, Jorge Tim=C3=B3n wrote: >> >> I still disagree. Using height instead of time may make the >> implementation more complex by requiring some additional preparations >> but using height is in fact a simpler design. Why relay on clocks that >> we know will differ in different computers and places when we have a >> universal tick with every block? > > Not so much that the implementation is difficult, as it requires context = to > validate a block size, rather than being able to validate it without > requiring the preceeding blocks. Yes, time on different machines may vary= , > but block time is safe to use for this, because it's a straight-forward t= est > of "if block time is acceptable and block time is after then maxim= um > block size allowed is n MB otherwise m MB". No, the height is in the current block after bip34, no context required. In any case, you already have the nHeight in most functions that would require it (for example, main::ConnectBlock). The median time actually needs a context (the last 10 headers), but it's not hard to calculate and pass around either. But simply using nTime is not a good idea. Leaving aside time zones, einstein and all that it introduces edge cases and weird incentives for no good reason. If the goal is to make it "human-schedule-friendly", median time should be good enough. If we're going to make miners 95% confirm after the date/height, I still prefer the height, but as said median time seems a reasonable compromise. Can we move the "height/medianTime/nTime" and "is it good to confirm that the change is uncontroversial to miners by requiring 95% to activate the consensus change, like we do with uncontroversial softforks?" discussions to the thread with my bip draft ( http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.htm= l ) on precisely this subject? I have requested a bip number. Let's please have an uncontroversial hardfork to set a precedent. Hopefully that way we may decouple some parts of the blocksize discussion.