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
|
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 42B8E1510
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 23:24:41 +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 CE7FA26A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 23:24:39 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 1940F140AF3; Sat, 19 Sep 2015 09:24:37 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Tier Nolan <tier.nolan@gmail.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAE-z3OWu7HgHh=8nAZMfJaekL03HHXvHrkRBho=aBAoRtHR9Eg@mail.gmail.com>
References: <87mvwqb132.fsf@rustcorp.com.au>
<CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com>
<87r3lyjewl.fsf@rustcorp.com.au>
<CABm2gDqh=Dv2Ygctg+jEt61N_nJDRBMqdZypSPtmfM2QrY4AYQ@mail.gmail.com>
<CAE-z3OXATJ6HGKqU=vxc8k-yCMAMwXiWQJxvO3D_O256_ZODtw@mail.gmail.com>
<CABm2gDppFsTbh3JtdJkAkV_GzKFYAOLiEmtQPCgS9O6b7eWFuw@mail.gmail.com>
<CAE-z3OXbUhsyzd=8hxzFAST9rEQyTg9whn+CMh92S0FMdLH4ug@mail.gmail.com>
<CABm2gDo4f6bpJeobwRyoukKw9t=ApuRtHMYWpWFXjv9=K7aFyA@mail.gmail.com>
<CAE-z3OUyNpmG5uhSCExf39zmmB-b9xDrn+gkp3UFeg7M3G8E5g@mail.gmail.com>
<CABm2gDphLRQ6huhxvcx1YvbsmaBHA_sk6MEZF+hgdxoC472P+w@mail.gmail.com>
<CDB1F26E-FE26-44F3-9A86-CDAE33A51B8B@gmail.com>
<CAE-z3OWu7HgHh=8nAZMfJaekL03HHXvHrkRBho=aBAoRtHR9Eg@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
(x86_64-pc-linux-gnu)
Date: Fri, 18 Sep 2015 07:27:51 +0930
Message-ID: <87h9msiu8w.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DATE_IN_PAST_24_48,
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
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: Fri, 18 Sep 2015 23:24:41 -0000
Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
writes:
> The advantage of enforcing the rule when 75% is reached (but only for
> blocks with the bit set) is that miners get early notification that they
> have implemented the rule incorrectly. They might produce blocks that
> they think are fine, but which aren't.
Indeed. There are three believable failure possibilties:
1) You don't implement the rule at all, and don't set the bit.
2) You implement it and set bit, but think some valid block is invalid.
3) You implement it and set bit, but think some invalid block is valid.
#1 is by far the most common, and the proposal is designed so they
*always* get ~2 weeks warning before those drop to SPV security.
Assuming the mining majority isn't buggy (otherwise, it's arguably not a
bug but a feature!) #2 is the worst case: some miners fork off and don't
rejoin.
So there is a slight advantage in doing this early: those buggy miners
no longer contribute to the 95% threshold. But that's outweighed IMHO
by:
1) We would need another delay at 75% so #1 nodes can upgrade.
2) The new feature won't be exercised much before impliciation, since
it's useless before then, so it might not find bugs anyway.
In conclusion, I'm not convinced by the extra complexity.
Cheers,
Rusty.
|
