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 83FA4491 for ; Wed, 29 Jul 2015 20:27:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9FF4B254 for ; Wed, 29 Jul 2015 20:27:30 +0000 (UTC) Received: by wibud3 with SMTP id ud3so41675137wib.0 for ; Wed, 29 Jul 2015 13:27:29 -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:date:message-id:subject:from:to :content-type; bh=Iw6BRKhqhSpatnPbmypLmK0GijL5he188QQyc7zIFTI=; b=ccac0oXqewnxkDPba81QySEmbGyRC7ofDGOi8TxB8QmJORXvNlK3GKrA+JwpJ6r/nv lQCxiN/mOxSoBrbBHFy2b2ymhJdBQIlQZFA6BTDw3RTNjn2wKZdvcamEMYYtCVLn2Ms3 0vogEtdcD1xVz9vn2Ecr3JeJyD4U+P0fDQfPbVUuoH5cbU5C0FekdI2rMxdh0LNsBM+s 1OENtJpqYL+QFhyZY10QHKJLs5iA9I/B8p/IlquOaBqiQE6pJUZMZ7ZTIEShCmDo2NLV pevAawnAIKKUqrhxNH+etS1gNUej3B7/NHznJh3a2R9J6XMRhR7nEeSgZ84GVPSUgcS4 Xnag== X-Gm-Message-State: ALoCoQkCagmP7qj0CsLmLnmNf1Qkssxjaxwcwi8KZHDvzn+W11jxAegFXq/gmaImYPr6yUg5Apwt MIME-Version: 1.0 X-Received: by 10.181.13.195 with SMTP id fa3mr20965250wid.7.1438201649311; Wed, 29 Jul 2015 13:27:29 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Wed, 29 Jul 2015 13:27:29 -0700 (PDT) Date: Wed, 29 Jul 2015 22:27:29 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Bitcoin Dev 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 Subject: [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: Wed, 29 Jul 2015 20:27:31 -0000 When it comes to define thresholds for consensus fork activation there are 3 options that I know of and each of them has at least a disadvantage that the other 2 lack: -Block.nTime: It's not monotonic -median time: You cannot validate it without context (in contrast, nTime is contained in the block header and nHeight in the coinbase) -block.nHeight: You cannot know the exact time when a given height will be reached. I personally think that nHeight's disadvantage is the less worse, but others will likely disagree. The point is we need to find a solid criteria to decide. When combining the threshold with a later miner's "voting" (upgrade confirmation) on top of it, not being monotonic may be a real problem. Doing that on top of height seems straight forward: check if (prevBlockIndex.nHeight > threshold && IsSuperMajority(...,prevBlockIndex,...)) With median time, seems safe too: if (prevBlockIndex.CalculateMedianTime > threshold && IsSuperMajority(...,prevBlockIndex,...)) Just a little bit less efficient. It would look more like if (IsSuperMajority(...,prevBlockIndex,...) && GetFirstBlockUsedInVoting(prevBlockIndex).nTime > threshold) But in some cases (say, an emergency consensus fork) you won't combine the mining confirmation, so you may not have the prevBlockIndex available and you may need to pass the height or medianTime down. If the current block is not accessible from wherever the check is being made, you would need an additional blockTime parameter as well. Are there any example cases where a rule activation check doesn't have the block available? Of course, let's consider the following hardfork example: before the hardfork: consensus_size(tx) = real_size(tx) after the hardfork: after consensus_size(tx) = real_size(tx) + delta_utxo_size(tx) that would allow miners to create bigger blocks if the transactions help reducing the size of the utxo (and penalize transactions that make the utxo grow by considering bigger when it comes to block inclusion). Well, at the block validation level (the most important one), you obviously have block.nTime available. But what if you're checking an unconfirmed transaction? It's size (and thus it's validity and the policy relay decisions) depends on whether the hardfork is activated or not. So to check an unconfirmed transaction, you would need the block.nTime of the next block, which is unpredictable (unless you're a miner) because miners set those. AcceptToMemoryPool already uses the nHeight (in fact, there's nHeight and nSpendHeight there, not sure why we need to of them yet), so this case would be trivial to implement. Calculating the median time there wouldn't be difficult either: even if globals weren't so heavily-used in AcceptToMemoryPool, the prevIndex can always be passed down as parameter. Some people may think that I'm discussing tiny details, but I would really like that we can chose whatever is more generic for any type of consensus fork and always use that from now on (instead of risking of having to use 2 of them if we find out later that the chosen option is not general enough). It would be also nice to have only one uniform type of threshold in Consensus::Params, and height seems to be the choice for softforks that have been accepted long ago via miners' voting/upgrade_confirmation, like in : https://github.com/bitcoin/bitcoin/pull/5966/files That doesn't mean it needs to necessarily be height: in a rebased version of #5966 we could replace consensus.nBIP34Height = 227931 with consensus.nBIP34Time = . But I would really like to have a uniform threshold mechanism instead of using the 3 options depending on the fork. I had assumed that height was the preferred option for everyone and that's why I used it in http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html But judging from the existing blocksize hardfork proposals (using block.nTime, the option I like less ) I was too fast there and clearly I need to reopen the discussion.