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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 46348AE7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 4 Jul 2015 10:04:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com
[209.85.220.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C8A11161
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 4 Jul 2015 10:04:41 +0000 (UTC)
Received: by qkhu186 with SMTP id u186so87222109qkh.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 04 Jul 2015 03:04:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=0YERvtrfN3yPQL1MI8Hz0Ojkq9MJzmPzH5x/Y4HtIM4=;
b=ocPYKtJZGVPT2Ap5rP7Nu2jKCVYyPY0rkmvNS0o9UONC13fivBr1jLqy8OOA9khN3Q
mx3vc9allwi7Ry1AkUBkSLGoCCpc4QUP74tmvQnDjKU1pIMshjrnWLhP208i5WbyH3Kj
a7yVGRSsoTCL7lBEBgF77n08IvjS96RhP0cfx9VJgfjSKHwo8++VBWOiKwxQzOwU0B7X
FoLcK47PF4EO93wnJK4wQBG2hqy1Y+FQnOgQwD0P3Bc00wz7DMG+RfMwlb6uxH4iAV9b
u2+uMnEzHaGT6I3BoiMkI5/uJEbYbOXj/w3ZrR50RSR+tKfwFMpA2SKPMugADo+gWP0Z
sDqw==
MIME-Version: 1.0
X-Received: by 10.140.38.167 with SMTP id t36mr56816000qgt.69.1436004280979;
Sat, 04 Jul 2015 03:04:40 -0700 (PDT)
Received: by 10.140.93.162 with HTTP; Sat, 4 Jul 2015 03:04:40 -0700 (PDT)
In-Reply-To: <20150704033016.GA14836@savin.petertodd.org>
References: <COL402-EAS128602FDFB9DA83AC6C1BD2CD950@phx.gbl>
<CAAS2fgQR15_1JVbtSD2yS9o5cpY-rNLsxpzuaeW2sexbQMuwQg@mail.gmail.com>
<20150704033016.GA14836@savin.petertodd.org>
Date: Sat, 4 Jul 2015 11:04:40 +0100
Message-ID: <CAE-z3OVJE4Gtgu3jzqCOCWF04V7jKqXrhGbQ5z7dGM+oxo4MmA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c12ce41058ae051a09cd8f
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Fork of invalid blocks due to BIP66 violations
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: Sat, 04 Jul 2015 10:04:42 -0000
--001a11c12ce41058ae051a09cd8f
Content-Type: text/plain; charset=UTF-8
On Sat, Jul 4, 2015 at 4:30 AM, Peter Todd <pete@petertodd.org> wrote:
> As for what "SPV mining" is:
>
> While blocks are propagating throughout the network, frequently it's
> possible for miners to get the header of the block before they get and
> fully validate the block itself. This is just a few seconds to tens of
> seconds, but that's a big deal for profitability. So miners have been
> running custom patches that mine on top of the longest chain they know
> about, even if they haven't actually verified the blocks in it due to
> propagation delays.
>
Is the invalid fork pretty much all empty blocks then?
SPV mining isn't inherently dangerous, if it is only for a short period of
time. It can boost the total work for the block chain.
Inherently, invalid blocks are rare, so assuming a header is valid is the
correct assumption.
For safety (for the miner), SPV miners should switch back to full mining
after 20-30 seconds without fully validating the chain that they are on.
- header received
- header verified (they skipped this step)
- build on header with empty block
- receive full block
-- mark header as invalid if this step times out
- verify full block
-- mark header as invalid if verification fails
- build on full block with non-empty block
An easier rule is that you only build on a header if the header's parent
(or even grandparent) has been fully verified. That rule would prevent the
illegal fork from growing past 1-2 blocks. It would mean that SPV miners
would start wasting hashing power once the invalid fork hit 2 blocks. They
wouldn't even build on their own block.
I guess miners never added code of that kind? That is pretty shocking that
a majority would SPV mine without that safeguard against the main
vulnerability of SPV mining.
Even waiting a few minutes before switch back would protect against this.
Worse, in this case, is that it wasn't just an invalid block, it was an
invalid header chain. They could have done the check with headers only.
--001a11c12ce41058ae051a09cd8f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Jul 4, 2015 at 4:30 AM, Peter Todd <span dir=3D"ltr"><<a href=3D"mai=
lto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
</span>As for what "SPV mining" is:<br>
<br>
While blocks are propagating throughout the network, frequently it's<br=
>
possible for miners to get the header of the block before they get and<br>
fully validate the block itself. This is just a few seconds to tens of<br>
seconds, but that's a big deal for profitability. So miners have been<b=
r>
running custom patches that mine on top of the longest chain they know<br>
about, even if they haven't actually verified the blocks in it due to<b=
r>
propagation delays.<br></blockquote><div><br></div><div>Is the invalid fork=
pretty much all empty blocks then?<br><br></div><div>SPV mining isn't =
inherently dangerous, if it is only for a short period of time.=C2=A0 It ca=
n boost the total work for the block chain.<br><br></div><div>Inherently, i=
nvalid blocks are rare, so assuming a header is valid is the correct assump=
tion.<br></div><div><br></div><div>For safety (for the miner), SPV miners s=
hould switch back to full mining after 20-30 seconds without fully validati=
ng the chain that they are on.<br><br></div><div>- header received<br></div=
><div>- header verified (they skipped this step)<br></div><div>- build on h=
eader with empty block<br></div><div>- receive full block<br></div><div>-- =
mark header as invalid if this step times out<br></div><div>- verify full b=
lock<br></div><div>-- mark header as invalid if verification fails<br></div=
><div>- build on full block with non-empty block<br><br></div><div>An easie=
r rule is that you only build on a header if the header's parent (or ev=
en grandparent) has been fully verified.=C2=A0 That rule would prevent the =
illegal fork from growing past 1-2 blocks.=C2=A0 It would mean that SPV min=
ers would start wasting hashing power once the invalid fork hit 2 blocks.=
=C2=A0 They wouldn't even build on their own block.<br></div><div><br><=
/div><div>I guess miners never added code of that kind?=C2=A0 That is prett=
y shocking that a majority would SPV mine without that safeguard against th=
e main vulnerability of SPV mining. <br><br></div><div>Even waiting a few m=
inutes before switch back would protect against this.<br><br></div><div>Wor=
se, in this case, is that it wasn't just an invalid block, it was an in=
valid header chain.=C2=A0 They could have done the check with headers only.=
<br></div></div></div></div>
--001a11c12ce41058ae051a09cd8f--
|
