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
165
166
167
168
|
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 6FBAF1B30
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 14:30:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149081.authsmtp.net (outmail149081.authsmtp.net
[62.13.149.81])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 5467E22E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 14:29:59 +0000 (UTC)
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t8SETwJ6028581;
Mon, 28 Sep 2015 15:29:58 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t8SETrwN086318
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 28 Sep 2015 15:29:56 +0100 (BST)
Date: Mon, 28 Sep 2015 10:29:53 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <hearn@vinumeris.com>
Message-ID: <20150928142953.GC21815@savin.petertodd.org>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<20150928132127.GA4829@savin.petertodd.org>
<CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="wxDdMuZNg1r63Hyj"
Content-Disposition: inline
In-Reply-To: <CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 64433c67-65ed-11e5-b399-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAoUC1AEAgsB AmMbWlFeUlR7XGU7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRRi c3pcFWdyfwNFeXY+ bEJjXj5dWEB5dhV7
RVNSEDhSeGZhPWUC AkNRfh5UcAFPdx8U a1UrBXRDAzANdhEy
HhM4ODE3eDlSNhEd ZgwRYklaTUsTGjkt DzojJWtyVWYlag4Q
CzsNCWI9OWsvH38T H2poMf9/
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/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] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
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: Mon, 28 Sep 2015 14:30:00 -0000
--wxDdMuZNg1r63Hyj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Sep 28, 2015 at 03:41:56PM +0200, Mike Hearn wrote:
> >
> > 1) Do you agree that CLTV should be added to the Bitcoin protocol?
> >
> > Ignoring the question how exactly it is added, hard-fork or soft-fork.
> >
>=20
> The opcode definition seems OK.
Good!
> > 2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it
> > is added to Bitcoin Core?
> >
>=20
> Yes. It might be worth putting the version bit change behind a command li=
ne
> flag though: the BIP, as written, has problems (with deployment).
Could you elaborate on what exatly you mean by this.
> > 3) Will you add soft-fork detection to bitcoinj, to allow SPV clients to
>=20
> detect advertised soft-forks and correctly handle them?
> >
>=20
> I'd really hate to do that. It'd be a Rube Goldberg machine:
>=20
> https://krypt3ia.files.wordpress.com/2011/11/rube.jpg
>=20
> There's no really good way to do what you propose, and we already have a
> perfectly workable mechanism to tell SPV clients about chain forks: the
> block chain itself. This has the advantage of being already implemented,
> already deployed, and it works correctly.
SPV wallets can't detect hard-forks, so in both cases you will have
invalid blocks be accepted by SPV clients; there's no deployment
scenario for either hard or soft forks that guarantees all miners adopt
a fork.
What does prevent invalid blocks being accepted by SPV clients is
checking the block nVersion field and applying forking logic. Of course,
that only works for advertised forks, but again, that's equally true for
soft and hard forks.
> Attempting to strap a different mechanism on top to try and make soft for=
ks
> more like hard forks would be a large and pointless waste of people's time
> and effort, not just mine (bitcoinj is not the only widely used SPV
> implementation nowadays). You may as well go straight to the correct
> outcome instead of trying to simulate it with ever more complex mechanism=
s.
Again, in neither case do you get the "correct outcome" of SPV clients
accepting no invalid blocks without nVersion field checking.
However, in the hard-fork case, because the non-adopting miners reject
the fork, they build a chain which could be used to attack SPV clients
with false confirmations by sybil attacking those clients. In the
soft-fork case, the non-adopting miners keep accepting the longer chain
built by the adopting miners, preventing the creation of a chain that
could be used to attack SPV miners.
BTW, what's the other widely used SPV implementation you're thinking of?
I'll contact them directly and help them implement proper SPV fork
protections if they haven't already; if bitcoinj is unwilling to do this
at least we could have an alternative implementation that does.
(equally, if anyone wants to fork bitcoinj and correct this flaw I'd be
happy to help advise)
--=20
'peter'[:-1]@petertodd.org
00000000000000000ca626374f25dadbbb9245e60563a4d876f3c73070ad3849
--wxDdMuZNg1r63Hyj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWCU7eXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMGIwZjU1MDU2MmI3NDNjMmU0ZGM1YWYwMzg1ZWE1OGE2
ZWNlMzJkODc4M2EwOTEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuEUAf/ctluFVQKYmay0wtzHidgFA+7
PM7rs91XvfcyJOxW9ZU8LUV7Bjgb3IeJt+aFfweZPBQ4JuLS1JNXaPgF1O6kp24H
tn8AXMhqju4UP8F0n1Y1VmqR7tmzpRxOW+lQh/6LbG+CFbilFb7qIpmwUOqrV63t
xvkGQ1ffORFYro7BIFT61Y6c7amRYfKxV7OJgSd3rCWNHuPa+3NnsKUWciUYWGDk
iGPHisZ4Lj74pWgouud3SCUa3DVUJmiInipUWstJ8WpPGMpAzQtHp8+KtLqffbym
nvLGI5GzLh2OWK104ku181Dv6hUowugWR2XCE9tvpopTMhaW+/6Jt0RDsAvZxA==
=omlC
-----END PGP SIGNATURE-----
--wxDdMuZNg1r63Hyj--
|
