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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C26A38ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 21:03:24 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149095.authsmtp.com (outmail149095.authsmtp.com
[62.13.149.95])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 15C61217
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 21:03:22 +0000 (UTC)
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7JL3JP2078751;
Wed, 19 Aug 2015 22:03:19 +0100 (BST)
Received: from muck (S0106e03f49079160.ok.shawcable.net [174.4.1.120])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7JL3FS3008612
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Wed, 19 Aug 2015 22:03:18 +0100 (BST)
Date: Wed, 19 Aug 2015 14:03:14 -0700
From: Peter Todd <pete@petertodd.org>
To: Mark Friedenbach <mark@friedenbach.org>
Message-ID: <20150819210314.GA31482@muck>
References: <20150819055036.GA19595@muck>
<CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com>
<CAE-z3OWjvR73jHrGhozxgqr_QUDu_hvDmHJWdiEGOcAGMB9oqA@mail.gmail.com>
<CAOG=w-uCPnSv9XxWLBteCFjU9B6Kg7RpFb=UknehMVPMUc0nag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ"
Content-Disposition: inline
In-Reply-To: <CAOG=w-uCPnSv9XxWLBteCFjU9B6Kg7RpFb=UknehMVPMUc0nag@mail.gmail.com>
X-Server-Quench: b7a4f02c-46b5-11e5-9f75-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwsUGUATAgsB AmMbWVZeUF57WGs7 ag1VcwFDY1RPXQV1
VUBOXVMcUAISfR93 ZR0eUhF0dgcIeXp4 ZkQsDHcKWBJ6dxVg
RkgGEHAHZDJldWlJ V0VFdwNWdQpKLx5G bwR8GhFYa3VsNCMk
FAgyOXU9MCtqYA9x fj9KBmksBksXFXh0 Sx0aGTI+GEADW204
KBo9K1IRBk8NM0I0 KhMtRF9QLxhwQj1i WGdKHGpzJkUKQCst
PT8SWE8YHSdGKT8G
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.4.1.120/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
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] CLTV/CSV/etc. deployment considerations due to
XT/Not-BitcoinXT miners
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, 19 Aug 2015 21:03:24 -0000
--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Aug 19, 2015 at 09:32:49AM -0700, Mark Friedenbach via bitcoin-dev =
wrote:
> I think you misunderstand my suggestion Tier. I am suggesting the same as
> BtcDrak, I think:
>=20
> Modify IsSuperMajority to take an (optional) mask field. Bits set in that
> mask are zero'd for the purpose of the IsSuperMajority calculation. For
> this vote we mask bits 0x20000007.
>=20
> Thus to signal support for CLTV/CSV/etc. (on Core, XT, or not-XT), you set
> bit 4. On Core this would mean a minimum version of 0x8, on XT/not-XT a
> minimum version of 0x20000008.
>=20
> However the vote is still over whether to enforce BIP 65, 68, etc. for
> blocks with nVersion>=3D4. So when this all clears up we haven't needless=
ly
> wasted an additional bit.
Ah, I see your point now re: wasting bits; my post was a bit incorrect
on that point.
So a subtle thing with the IsSuperMajority() mechanism, and the nVersion
bits proposal alternative, is one of the main objectives of the latter
proposal proposal is to allow forks to *fail* to be adopted cleanly.
To illustrate the problem, consider a hypothetical CLTV soft-fork,
implemented with IsSuperMajority() nVersion >=3D 4. We release Bitcoin
Core with that code, call it Bitcoin Core v0.12.0, however some
substantial fraction of the mining community refuses to upgrade,
believing CLTV to be a bad idea. This forms the community into Bitcoin
Core and Bitcoin Not-CLTV camps. The Not-CLTV camp then wants to do a
new soft-fork upgrade, say for CHECKSIG2
What now? If CHECKSIG2 is implemented via IsSuperMajority, nVersion >=3D
5, that'll falsely trigger Core nodes to think the upgrade has gone
though. You could safely define >=3D 5 semantics to be "OP_CLTV is now
disabled", but that's pretty ugly and unnecessarily uses up a NOP.
You can avoid this problem by assigning one bit out of nVersion for
every soft-fork, but then you can only do ~29 more soft-forks - ugly!
Come to think of it, if you're Really Sure=E2=84=A2 the soft-fork will be
adopted, you can recycle those bits by using the following rule:
if (IsFlagBitMaskSuperMajority(1 << 4, pindex->pprev) || block.nMedianT=
ime > CLTV_SOFTFORK_DEADLINE) {
flags |=3D SCRIPT_VERIFY_CLTV;
}
IsFlagBitMaskSuperMajority() is a masked version of the existing
IsSuperMajority() logic. CLTV_SOFTFORK_DEADLINE would be set some
reasonable amount of time in the future, perhaps 3 years.
This would probably be ok for non-controversial forks - implementing
DERSIG this way would have been fine - and an unlimited number of
soft-forks can be done this way safely. (even in parallel)
However, this idea still causes problems if forks ever fail to get
adoption, something the nVersion bits proposal handles cleanly, albeit
at the cost of a significantly more complex implementation. With a
sufficiently far off fork deadline in practice that may not be a big
issue - nearly everyone would have upgraded their software anyway - but
it's still technically creating hard-fork scenarios with respect to
older software whenever forks fail to get adoption.
--=20
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJV1O8PXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi
ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udxTcQf/deLEWwYkPVXXs+fd4B5VNQ4j
hf+s8KrdOB5aynMVz0z7S3PSIPAJHuI5UpmhMxkX1M8ymX2o0GjXyL/J+4V3VCFq
czQ3k0lwP2eRoSJ1iQGUWUP26YLm6PmFxDpkOQ9AIkFfmptCQPBuGxhrbTSmXTO1
G/bTAI78HO0+F8P2S9jQevOPlevX7RRxJ5ZhwGekgMBFs5xAMjnqBGsHL3D8Icku
21a8IbVXY5MxOMXPDy1/fte4tM92ch/84G96Ewx6EDJiz0MndG0D0nl4us7lnzaq
7LeZOzSiHtgwlLrwe+76sFhK8XOQm+v3Fg2hCan5T8SUIt2VffWl4IEk1efjdQ==
=iPyr
-----END PGP SIGNATURE-----
--rwEMma7ioTxnRzrJ--
|
