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 82DA77AF for ; Tue, 4 Aug 2015 20:02:56 +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 D499818E for ; Tue, 4 Aug 2015 20:02:55 +0000 (UTC) Received: by wicgj17 with SMTP id gj17so165385246wic.1 for ; Tue, 04 Aug 2015 13:02:54 -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; bh=8wGLCjaL9856arM/0dev7H3ESsAjasC8GAu6xgiwErY=; b=A2q2KwlSCxOBP49+5k5N9RKKQV8ylk+f14QWFMBOWY1tr0tq8noW4tIAU780Tl+Cqc GF/V6wwawl0AS48D3wB1Ly4EyVQajsmjaqYOe5wNpBGGaqKwok+egsDBAdW7F9XjOnEg 6iSIB3pCOFgwnn3fp2J3TV4R3uYUOUbXjahh1qWsFOXgRY2DqMaT4TnA25H8pHGbv6lJ YunfoHKlGTMvRptTeMlVe2pLTaIHbiHCZUo9IR/ed/AfHeElgJjL1knqI4nuq1qZXL05 FFCtVNVVasB40csPGyhc7CpPFNMuvhg2fvcn9iGojBWJIN7Jcxa60t4Vf8g9ZSnJFLNs k7Mg== X-Gm-Message-State: ALoCoQmKeAz8ErgkIdMb4XEhKQEYUFL+YrILRIBIpASkxx09n8TiTHBZtKmY5j+wQebKBYFycnc2 MIME-Version: 1.0 X-Received: by 10.194.122.97 with SMTP id lr1mr11597917wjb.26.1438718574279; Tue, 04 Aug 2015 13:02:54 -0700 (PDT) Received: by 10.194.31.230 with HTTP; Tue, 4 Aug 2015 13:02:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Aug 2015 22:02:53 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 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 Subject: Re: [bitcoin-dev] Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight 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: Tue, 04 Aug 2015 20:02:56 -0000 On Thu, Jul 30, 2015 at 8:16 PM, Gavin Andresen wrote: > I still think using the version and timestamp fields in the block header are > simplest and best. To be clear, all options can use the version. > Advantages: > Available to SPV nodes with no change to the network protocol > Available after headers downloaded, before full block data is available > Once well past a fork, allows all block validation except validation > against the UTXO to happen in parallel, out-of-order, independent of any > other block. All advantages shared with the height option. > Disadvantages: > Not monotonically increasing > > > I think discussion about transactions in the memory pool are just a > distraction: no matter what criteria is used (timestamp, height, median > time), a blockchain re-organization could mean the validity of transactions > you've accepted into the memory pool (if you're accepting transactions that > switch from valid to invalid at the consensus change -- Core tries hard not > to do that via IsStandard policy) must be re-evaluated. I'm talking about the non-reorg case. Without reorg, you know what the next height or current median time is, but you don't know what the next block time is. > I don't strongly care if median time or block timestamp is used, I think > either will work. I don't like height, there are too many cases where the > time is known but the block height isn't (see, for example, the > max-outputs-in-a-transaction sanity check computation at line 190 of > bitcoin-tx.cpp -- bitcoin-tx.cpp has no idea what the current block height > is). How does bitcoin-tx know about the next block time? It doesn't. You would need to use the current time as a proxy for the median time or the block.nTime which you don't know either. Or just keep the sanity check as it is. Note that this case is blocksize-specific: other hardforks (like my previous example, or the code proposal in BIP99) don't share that concern. One thing I've noticed there seems to be disagreement on is whether miners' upgrade confirmation (aka voting) is necessary for uncontroversial hardforks or not. In BIP99 the advice for uncontroversial hardforks is setting a threshold (based on height, but we can change it) and then wait for 95% of the hashrate to upgrade to enforce the chain. But maybe the "voting" can happen first and then the threshold is added to the "miners' confirmation height/time". I think that may influence which of the three discussed options (height, block time and median time) is better, so maybe we should discuss that first.