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 2C309722 for ; Wed, 5 Jul 2017 02:28:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from bc.grid.coop (bc.grid.coop [162.221.205.91]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id B00378D for ; Wed, 5 Jul 2017 02:28:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) (uid 1000) by bc.grid.coop with local; Wed, 05 Jul 2017 02:25:33 +0000 id 0000000000080088.00000000595C4E1D.0000177C Date: Wed, 5 Jul 2017 02:25:33 +0000 From: Troy Benjegerdes To: shaolinfry Message-ID: <20170705022533.GH4885@hostname.unassigned> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 05 Jul 2017 02:31:52 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Height based vs block time based thresholds X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 02:28:32 -0000 On Tue, Jul 04, 2017 at 09:30:26PM -0400, shaolinfry via bitcoin-dev wrote: > Some people have criticized BIP9's blocktime based thresholds arguing they are confusing (the first retarget after threshold). It is also vulnerable to miners fiddling with timestamps in a way that could prevent or delay activation - for example by only advancing the block timestamp by 1 second you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically). If there are miners that start doing 1 second timestamp advances, it would be simpler (and probably safer) to require a minimum block time spacing of say 30 seconds or 1 minute, and orphan blocks that are too close in time and more than say an hour behind real-time. I cannot picture any realistic scenario in which an attempt to block activation in this way is in anything other than a very expensive temper tantrum for any miners foolish enough to attempt it. It *might* be a delay tactic as a 'nuclear option' attack vector for a mining cabal to run up the difficulty so high as to make it impractical to mine any new blocks after the adjustment, but there are plenty of altcoins that have hardforked and gotten along just fine after the same kind of thing due to profit-switching pools. > On the other hand, the exact date of a height based thresholds is hard to predict a long time in advance due to difficulty fluctuations. However, there is certainty at a given block height and it's easy to monitor. > If there is sufficient interest, I would be happy to amend BIP8 to be height based. I originally omitted height based thresholds in the interests of simplicity of review - but now that the proposal has been widely reviewed it would be a trivial amendment. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev