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
|
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 C282E13FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 15:05:49 +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 E805D243
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 15:05:48 +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 t8SF5lhU038905;
Mon, 28 Sep 2015 16:05:47 +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 t8SF5h7X080267
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 28 Sep 2015 16:05:46 +0100 (BST)
Date: Mon, 28 Sep 2015 11:05:43 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <hearn@vinumeris.com>
Message-ID: <20150928150543.GB28939@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>
<20150928142953.GC21815@savin.petertodd.org>
<CA+w+GKTUz2eVJOpixSebWiQ59ovoELNhsZWSsbLHXWqk2eCn0A@mail.gmail.com>
<20150928144318.GA28939@savin.petertodd.org>
<CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="wzJLGUyc3ArbnUjN"
Content-Disposition: inline
In-Reply-To: <CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 65ab6dc8-65f2-11e5-9f76-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAoUC1AEAgsB AmMbWlJeUFh7XWU7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRRi cBtGVXFyfwVEfnk+ bEVrWj5dWRUocxIu
SlNSEDsEeGZhPWUC WRZfcR5UcAFPdx8U a1N6AHBDAzANdhEy
HhM4ODE3eDlSNhEd ZgwRYklaTUsTGjkt DzojJWtyVWYlag4Q
CzsNCWI9OWsvH38T H2poMf9/
X-Authentic-SMTP: 61633532353630.1024: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 15:05:49 -0000
--wzJLGUyc3ArbnUjN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Sep 28, 2015 at 04:51:22PM +0200, Mike Hearn wrote:
> >
> > Ok, so again, if that's your security criteria, what's the issue
> > with soft-forks?
>=20
>=20
> Please read my article as it's all explained there.
I have read your article. In fact we reviewed it at a NY BitDevs meetup
that I attended.
> But to reiterate: the risk is that miners will build invalid blocks on top
> of the best work chain, instead of an ignored lower work side chain. This
> opens users to payment fraud. With a hard fork, all the blocks by miners
> that aren't checking all the rules anymore get neatly collected together =
on
> a side chain after the split, and wallets all know how to ignore that cha=
in.
Can you explain exactly how you think wallets will "know" how to ignore
the invalid chain?
With an advertised soft-fork, e.g. the IsSuperMajority() mechanism,
ignoring the invalid chain is easy: use nVersion to detect invalid
blocks when you know what soft-forks are coming up, and if presented
with an unknown - but advertised - soft-fork at minimum loudly warn the
user. In the case of a hard-fork identical logic can be used. (BIP101
being an example of a hard-fork triggered in a way that can be detected
by SPV clients, both explicitly (BIP101 specific) and implicitly
(general unknown block nVersion warnings))
> Yes, you made OP_NOPs be non-standard. So out of the box, miners won't
> create invalid blocks, as long as they're running Core past that version.
> But this makes the IsStandard function very much like a part of the
> consensus rules, as bypassing it can result in invalid blocks being
> created.
How so? Miners can always choose to create invalid blocks, thus
attacking SPV wallets; my statement with regard to pull-req #5000 comes
=66rom a risk-based approach, knowing that every invalid block is
expensive and the new concern created by a soft-fork is whether or not
miners will create them accidentally; miners can always create invalid
blocks delibrately.
> Miners have always understood that they can modify this function,
> or even bypass it entirely, without affecting the validity of their block=
s.
> And some miners do exactly that.
That's incorrect: Miners bypassing IsStandard() risk creating invalid
blocks in the event of a soft-fork. Equally, we design soft-forks to
take advantage of this.
> So I'll repeat the question that I posed before - given that there are
> clear, explicit downsides, what is the purpose of doing things this way?
> Where is the gain for ordinary Bitcoin users?
We seem to be in strong disagreement about which option has "clear,
explicit downsides"
--=20
'peter'[:-1]@petertodd.org
0000000000000000006f2abe95e361b73289e4a79ba3124801896f6b7dc8d977
--wzJLGUyc3ArbnUjN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWCVdDXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZDZjYTE2YjNiNTRjMWQ5ODI0NGZkYmZmYzg1ZjJhZjAy
MDY4MjlkMDc3OGEyNWEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftiIggAnkcSgmIn5hsltGI0lmPeiylp
ZhMjUsXl40ZkOYq5/KIpVw9JBO6zUvG+C7dsd6TbOdcCfVyMaXhbBa0J41XiipBM
PU4FdlpNhMJuqHcu9i4wNdljnN0zBpw0QO1n1vSZuY6w5dGze/z5OvSxbAEW1Klx
3U7U+HV5cbcpZRPp9QEgswP5Ocstryxatw9pqz7NrOZNI8Af4qSm7IactigO4qhw
pq3c4irSk9zAsDDZ7sMZvlyIeyEUcy3EAdYCqyU6cHr27TcoXG4Sy74CPNWGw5V9
xpCH5ZiO6AswdD1f/SCHvxAS3FTKTYDY8d3qZh3nnjJ9jWN0hIg6rDM6xMdo2g==
=6i5f
-----END PGP SIGNATURE-----
--wzJLGUyc3ArbnUjN--
|
