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 15BC17A9 for ; Wed, 5 Jul 2017 03:39:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5F3771DB for ; Wed, 5 Jul 2017 03:39:11 +0000 (UTC) Received: by mail-wm0-f45.google.com with SMTP id w126so209603728wme.0 for ; Tue, 04 Jul 2017 20:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bittorrent-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=65Yt9s32d4LOpjxU4aHCT8QwZ5rezmoA1vrIFHrRrns=; b=yPT9tWM8DLRkv51MTbFS7ckbM8P4wB0jJuUkn5+mHE7Ox7QhonDn2IPk5sYNmPpMrK 5aMRr5rJZeKEgG9ADoD5dAG9Wc9f1Uq30LbqNUYPLluU2vwjKt2T3vdOKnK7JUKGuzQa DffKKxCOL8iudH5P5vLNE10RzHs2Uh9s0eyCVIXFaF5QQYMzHQDV/msUieclEM29ZZ2w PsK7GttImorR1YHasQgC/Gy2BRMrZgk8SvvYS1CsLZQpp+DUmuNgTuzR169U97hyJtvO SJ3Aar3ojk+xfyVNrBtxoWmVw+qlf8yuAWwR48VTMHmA5mgYKsAIU/SdOsfY/EOMHEJJ pO7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=65Yt9s32d4LOpjxU4aHCT8QwZ5rezmoA1vrIFHrRrns=; b=F7N94WAFmhMVMUV7bY5tekJybBDYUKXDRNtTmGSBz2JSr7AJ0FDMvTt0WDOFA3WTQw C0T96O7xNDh0IFeGQmrnDrmeBHqk1A1GKMUFS772ni1GdAT6U/EqTLkLodlQ+zzgjwnE uPaU3QwY7re7VWHva3ptw9+kMNEX/KX26nIDEqJYvax40V7tRY0iLI7SfF962YUhZ8S+ BZpiAoYaXNGDvZsmANbJeGBjc/JCQ4rxHhd1weMeFDLOiP7m045OoOjmtKxVVZ+Y5zGI Z/B2joZCXdgXoA8Fv8Z3+psjmjdIBVB0cCYBs+8j/tukJJj+QPTd8Z0miplUDBTZNnmF jAwA== X-Gm-Message-State: AIVw112gvtIvP9NdMhXeESZNHKfT81kNaQ/YNXjYS/O3Or5saNaUCNl2 AfySWmOf2FDRV6mZ/RmZuwrDRtMGgCeK X-Received: by 10.28.7.211 with SMTP id 202mr15265878wmh.113.1499225949824; Tue, 04 Jul 2017 20:39:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.181.152 with HTTP; Tue, 4 Jul 2017 20:39:09 -0700 (PDT) In-Reply-To: References: From: Bram Cohen Date: Tue, 4 Jul 2017 20:39:09 -0700 Message-ID: Cc: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a114435122d7d96055389beec" X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, MISSING_HEADERS, RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 03:39:12 -0000 --001a114435122d7d96055389beec Content-Type: text/plain; charset="UTF-8" On Tue, Jul 4, 2017 at 6:30 PM, shaolinfry via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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). > > 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. > You could get most of the best of both with a combination of the two: Have the activation be a timestamp plus a certain number of blocks to come after maybe about 100, which is more than enough to make sure all the games which can be played with timestamps have passed but a small enough amount that it doesn't add much uncertainty to wall clock time. --001a114435122d7d96055389beec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 4, 2017 at 6:30 PM, shaolinfry via bitcoin-dev &l= t;bitcoin-dev@lists.linuxfoundation.org> wrote:
Some people have criticized BIP9's blocktime = based thresholds arguing they are confusing (the first retarget after thres= hold). It is also vulnerable to miners fiddling with timestamps in a way th= at could prevent or delay activation - for example by only advancing the bl= ock timestamp by 1 second you would never meet the threshold (although this= would come a the penalty of hiking the difficulty dramatically).
=

On the other hand, the exact date of a height based thr= esholds is hard to predict a long time in advance due to difficulty fluctua= tions. However, there is certainty at a given block height and it's eas= y to monitor.

You could get most = of the best of both with a combination of the two: Have the activation be a= timestamp plus a certain number of blocks to come after maybe about 100, w= hich is more than enough to make sure all the games which can be played wit= h timestamps have passed but a small enough amount that it doesn't add = much uncertainty to wall clock time.

--001a114435122d7d96055389beec--