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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
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 83FA4491
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Jul 2015 20:27:30 +0000 (UTC)
Received: by wibud3 with SMTP id ud3so41675137wib.0
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <CABm2gDoxr4yY6XPZOEG0CF_iPO+b1H3_yFoKnYa68Y4b=Tcwrw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 = <something>.
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.
|
