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
|
Return-Path: <rgrant@rgrant.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EDE5BC61
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Apr 2017 20:13:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb0-f172.google.com (mail-yb0-f172.google.com
[209.85.213.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7491B1AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Apr 2017 20:13:06 +0000 (UTC)
Received: by mail-yb0-f172.google.com with SMTP id l201so21019865ybf.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Apr 2017 13:13:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=rgrant-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:sender:from:date:message-id:subject:to;
bh=Ikny4ZBFU5q+8VY4ZGZ0Z6EjI73CIrfC7S/C7XuM+LA=;
b=p74TWPH1K3NFNUia+mTGl8s0IFoX+lLEqtVoCh1HZEtGiG0s8iBCRwMgJNXNLuOAbk
/oAcgBojLbVKv8ofOH5mKuoedh5dOfXvB9WJWaBwEWP5xYc+yi5xWEn8cfZK8588tKH0
7YpldoOJ8QttAFVB6iAe7G07vHuw+9UtWNDBTel32SPv6TJuWI0x9Q31ORBgDkGKu0Of
zzr+mR9NX+JLuinqe95Ghd4gh2RZtF5Ffeo7Fq7ocmRtGxpAgWYQnFFb8n8sB8ZhpHQU
S/GdI7dafuhJLx1yOcqFv/0KHGq2aXn3wpX6vQZqxJ6N6M5PddTAFK97DvQNI+5kpvQt
9Xxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
:to; bh=Ikny4ZBFU5q+8VY4ZGZ0Z6EjI73CIrfC7S/C7XuM+LA=;
b=PFomJcNxXFu0+22K54e1EEkYXL7vP3acw6tjIbjwLHL5ZiR44EvC22VB2efxtcO1w9
0H93FBBVPl2TN5+JWcmReycPQMZgHk3fLnwuJO2H0Vx57vp4elSuXB58qwmBEGlAoXLP
nO8g3Igsaf47l/UpIyCt9Fr4gwk07bWJ1envyYsOd1Wz1mFr4xt+8YMqLip71vsmwqIx
lFSrxru4IuskKs/YTBGRCGodlJarrQ9jWGkwgDgF7X44qFEhyWYnZ9jFsCrFAKnQ1eCA
0fAozvMZqJDaGKnvBlzhxSmR6cw6NKy4v/Rc4y3C49CLKPx44NgcxcEOG+geLTPjX7bN
5u0w==
X-Gm-Message-State: AN3rC/69KOFInnc6DdsqaH/fd3Qf6odGLCd5vxWw/aLUjUTBMHd3kCZx
Ua/9vfakTkEjAgNhxwPds1R5v4NQIeMWiSc=
X-Received: by 10.37.59.199 with SMTP id i190mr7489198yba.126.1492200785298;
Fri, 14 Apr 2017 13:13:05 -0700 (PDT)
MIME-Version: 1.0
Sender: rgrant@rgrant.org
Received: by 10.37.179.22 with HTTP; Fri, 14 Apr 2017 13:12:34 -0700 (PDT)
From: Ryan Grant <bitcoin-dev@rgrant.org>
Date: Fri, 14 Apr 2017 15:12:34 -0500
X-Google-Sender-Auth: nCxs8TYgLuYqHwzb9_CPqH8w-N0
Message-ID: <CAMnpzfr5hLFqRm0_KWb6=N8YsD4dfQBtRBPFwfjz-EHA31d34A@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] extended BIP9 activation of segwit, for legacy nodes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 14 Apr 2017 20:13:07 -0000
Segwit has proven more contentious to activate than anticipated
(although my read has long been that the technical consensus is clear,
despite noisy objections). No matter which method is used to
eventually activate segwit, or on what timeline, it would be
beneficial if validating nodes already capable of supporting segwit
could, without further upgrades, eventually participate to their
fullest capacity.
BIP9 assignments should reserve a backward compatibility bit which all
yet-unknown segwit-compatible proposals may utilize. These future
proposals must be consensus compatible with BIPs 141, 143, & 147,
except that they may use different deployment logic.
The motivation is so that any validating node software released after
this BIP9 assignment can eventually understand if segwit is activated
by alternate means, even when the node is itself a legacy version.
This is important because the realities of system administration on
the Bitcoin network are that upgrades occur slowly (which is inherent
in the security choice of not presenting an auto-upgrade feature).
Even though segwit in particular is backwards compatible with old
validating nodes, there are still distinct advantages to validating
and generating segregated witness transactions.
For example, future BIP9-compatible deployment attempts might
additionally include a date-dependent UASF fallback. If, either
during or after activation, deployment rules also require signaling
for segwit using the backwards-compatible bit here proposed, then
(after 95% of recent blocks signal for the alternate segwit
deployment) more legacy nodes would understand and validate
transactions using segregated witnesses.
An expiration time of five years seems conservative:
// Alternate Deployment 1 of SegWit (BIP141, BIP143, and BIP147)
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].bit = 2;
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nStartTime
= 1510704000; // November 15th, 2017.
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nTimeout =
1668470400; // November 15th, 2022.
Segwit deployment logic would then look like:
bool IsWitnessEnabled(const CBlockIndex* pindexPrev,
const Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev,
params,
Consensus::DEPLOYMENT_SEGWIT,
versionbitscache)
== THRESHOLD_ACTIVE)
|| (VersionBitsState(pindexPrev,
params,
Consensus::DEPLOYMENT_SEGWIT_ALT1,
versionbitscache)
== THRESHOLD_ACTIVE);
}
|
