1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 82DA77AF
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 20:02:55 +0000 (UTC)
Received: by wicgj17 with SMTP id gj17so165385246wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <CABsx9T0c10SDHCBy5=iPKVvsNPmKr2ejUxLp0rJPZmPRPQpfig@mail.gmail.com>
References: <CABm2gDoxr4yY6XPZOEG0CF_iPO+b1H3_yFoKnYa68Y4b=Tcwrw@mail.gmail.com>
<CABsx9T0c10SDHCBy5=iPKVvsNPmKr2ejUxLp0rJPZmPRPQpfig@mail.gmail.com>
Date: Tue, 4 Aug 2015 22:02:53 +0200
Message-ID: <CABm2gDonaiD_VxGoRHjXC8Ut3jxRG-cHVfdL9Y4voZz5m=z7SA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 20:02:56 -0000
On Thu, Jul 30, 2015 at 8:16 PM, Gavin Andresen <gavinandresen@gmail.com> 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.
|
