Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C129125A for ; Sun, 1 Nov 2015 19:06:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 6865B15E for ; Sun, 1 Nov 2015 19:06:58 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 06A1B38A6077 for ; Sun, 1 Nov 2015 19:06:45 +0000 (UTC) X-Hashcash: 1:25:151101:bitcoin-dev@lists.linuxfoundation.org::uk5zI6Zh5MoTfu4J:a6T0n From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org Date: Sun, 1 Nov 2015 19:06:43 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; ) X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201511011906.44081.luke@dashjr.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD 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] BIP 113: Median time-past is a HARDfork, not a softfork! 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: Sun, 01 Nov 2015 19:06:58 -0000 BIP 113 makes things valid which currently are not (any transaction with a locktime between the median time past, and the block nTime). Therefore it is a hardfork. Yet the current BIP describes and deploys it as a softfork. Furthermore, Bitcoin Core one week ago merged #6566 adding BIP 113 logic to the mempool and block creation. This will probably produce invalid blocks (which CNB's safety TestBlockValidity call should catch), and should be reverted until an appropriate solution is determined. Rusty suggested something like adding N hours to the median time past for comparison, and to be a proper hardfork, this must be max()'d with the block nTime. On the other hand, if we will have a hardfork in the next year or so, it may be best to just hold off and deploy as part of that. Further thoughts/input? Luke