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
|
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 3D301AAE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 10:39:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com
[209.85.220.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2A6A132
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 10:39:39 +0000 (UTC)
Received: by qkbp125 with SMTP id p125so223041471qkb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 03:39:38 -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=yUf/uM6PVZz4Xn+K3+yeb7qzGPF+PPB3GcQzqxl1dgw=;
b=y7+Mpmtp55XogUSxl4QD8/MatiwwUsEdEPrL9D3fyFpgrR4nsYkiSi6fTzTal1tY/S
3KjaFmEinrc2OM15nx+pASvZ1kUNLhw/0MGeqyFISXi3pf3oUcS5WK6Ppo8Dcq9+XTNE
pR0LJKS0wP08kysyJAuIQL519M7fOUQTtnJFubLW8mT4aR42L6yomVOzEasM4Q8gvGWQ
cuNidyLfdoCW5Mj6zrbJ8lHrQuv0qKYkwFzONC9SP27fVJVdt5aTqTwKGuH28LDknjKa
gsr6nk2/Ub7R/z9axSJZd9BmWW+AZz9wAoYqZ+JiEUF4dQpYVoX6oDI1hqPrrX+apLAP
IGfg==
MIME-Version: 1.0
X-Received: by 10.55.43.75 with SMTP id r72mr40066688qkh.80.1436611178386;
Sat, 11 Jul 2015 03:39:38 -0700 (PDT)
Received: by 10.140.93.162 with HTTP; Sat, 11 Jul 2015 03:39:38 -0700 (PDT)
In-Reply-To: <CABm2gDoAa5F5crO4enKO-Qqb+Zd3=9b8ohBDYmrygsPSWdevoQ@mail.gmail.com>
References: <CAFdHNGg2dezj4V-i-E6dRLp99nZMQ_ErKdBo0OgQJ=9WPm90jQ@mail.gmail.com>
<CABm2gDoAa5F5crO4enKO-Qqb+Zd3=9b8ohBDYmrygsPSWdevoQ@mail.gmail.com>
Date: Sat, 11 Jul 2015 11:39:38 +0100
Message-ID: <CAE-z3OWOoHfMaEN04CQ-j8tzmAr1+Evjh+tfHRDbF6F1jxykHA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1147732ef7d9af051a971a0d
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] SPV Mining reveals a problematic incentive issue.
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, 11 Jul 2015 10:39:40 -0000
--001a1147732ef7d9af051a971a0d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Jul 11, 2015 at 10:24 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:
> I think it would be more rational for them to keep mining on top of the
> old block until they've fully validated the new block (which shouldn't ta=
ke
> so long anyway), even if this slightly increases the orphan rate.
Increased orphan rate means that the network is (slightly) less secure.
If miners have a 5% orphan rate, then an attacker can launch a 51% attack
with 49% of the network.
It isn't a massive difference, but it is there.
As long as miners switch back to non-SPV mining after a timeout, SPV-mining
is safe for everyone.
The average cost to the miner from building on an invalid block is small,
as long as invalid blocks only happen rarely.
Miners still have an incentive to do full validation, so that they can
include transactions and get transaction fees.
SPV-mining is to prevent hashing hardware from having to waste power when
it isn't needed.
It may be less of a problem if (when?) electricity costs dominate hardware
capital costs.
--001a1147732ef7d9af051a971a0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jul 11, 2015 at 10:24 AM, Jorge Tim=C3=B3n <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think it would be m=
ore rational for them to keep mining on top of the old block until they'=
;ve fully validated the new block (which shouldn't take so long anyway)=
, even if this slightly increases the orphan rate.
</blockquote><div><br></div><div>Increased orphan rate means that the netwo=
rk is (slightly) less secure.<br></div><div><br></div><div>If miners have a=
5% orphan rate, then an attacker can launch a 51% attack with 49% of the n=
etwork.<br><br></div><div>It isn't a massive difference, but it is ther=
e.<br><br></div><div>As long as miners switch back to non-SPV mining after =
a timeout, SPV-mining is safe for everyone.<br><br></div><div>The average c=
ost to the miner from building on an invalid block is small, as long as inv=
alid blocks only happen rarely.<br></div><br></div>Miners still have an inc=
entive to do full validation, so that they can include transactions and get=
transaction fees.<br><br></div><div class=3D"gmail_extra">SPV-mining is to=
prevent hashing hardware from having to waste power when it isn't need=
ed.<br><br></div><div class=3D"gmail_extra">It may be less of a problem if =
(when?) electricity costs dominate hardware capital costs.<br></div></div>
--001a1147732ef7d9af051a971a0d--
|
