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
|
Return-Path: <rusty@ozlabs.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8BEA41358
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 20:20:09 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (ozlabs.org [103.22.144.67])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3388B1D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 20:20:08 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 28773140518; Thu, 17 Sep 2015 06:20:05 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Tier Nolan <tier.nolan@gmail.com>
In-Reply-To: <CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com>
References: <87mvwqb132.fsf@rustcorp.com.au>
<CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
(x86_64-pc-linux-gnu)
Date: Thu, 17 Sep 2015 05:49:22 +0930
Message-ID: <87r3lyjewl.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and
delay.
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, 16 Sep 2015 20:20:09 -0000
Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
writes:
> On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> '''States'''
>> With every softfork proposal we associate a state BState, which begins
>> at ''defined'', and can be ''locked-in'', ''activated'',
>> or ''failed''. Transitions are considered after each
>> retarget period.
>>
>
> I think the 75% rule should be maintained. It confirms that miners who are
> setting the bit are actually creating blocks that meet the new rule (though
> it doesn't check if they are enforcing it).
I couldn't see a use for it, since partial enforcement of a soft fork is
pretty useless.
Your point about checking that miners are actually doing it is true,
though all stuff being forked in in future will be nonstandard AFAICT.
I bias towards simplicity for this.
> What is the reason for aligning the updated to the difficulty window?
Miners already have that date in their calendar, so prefer to anchor to
that.
> *defined*
> Miners set bit
> If 75% of blocks of last 2016 have bit set, goto tentative
>
>
> *tentative*
> Miners set bit
> Reject blocks that have bit set that don't follow new rule
> If 95% of blocks of last 2016 have bit set, goto locked-in
>
>
> *locked-in*
>
> Point of no return
> Miners still set bit
> Reject blocks that have bit set that don't follow new rule
> After 2016 blocks goto notice
OK, *that* variant makes perfect sense, and is no more complex, AFAICT.
So, there's two weeks to detect bad implementations, then you everyone
stops setting the bit, for later reuse by another BIP.
> I think counting in blocks is easier to be exact here.
Easier for code, but harder for BIP authors.
> If two bits were allocated per proposal, then miners could vote against
> forks to recover the bits. If 25% of the miners vote against, then that
> kills it.
You need a timeout: an ancient (non-mining, thus undetectable) node
should never fork itself off the network because someone reused a failed
BIP bit.
> In the rationale, it would be useful to discuss effects on SPV clients and
> buggy miners.
>
> SPV clients should be recommended to actually monitor the version field.
SPV clients don't experience a security change when a soft fork occurs?
They're already trusting miners.
Greg pointed out that soft forks tend to get accompanied by block forks
across activation, but SPV clients should *definitely* be taking those
into account whenever they happen, right?
Thanks!
Rusty.
|
