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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E218A9F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Jul 2015 18:37:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com
[209.85.212.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 14F4D25D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Jul 2015 18:37:20 +0000 (UTC)
Received: by wiga1 with SMTP id a1so51425354wig.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Jul 2015 11:37:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=sqYm2FBm4kx1Mas5lhZ4xDPLJz321ubHBZNsERpDXTg=;
b=k7gObErTEbgsSxxkNr8+BH5P2oFhOlxGmraChvY1FVn4YQTxQBeg9NYX6uK/AxKBLc
v7TYZiUXUhK/Vu5JJCf/GNKcy7Evw1BE8ls4y4U5zT1032nVhlggq/NaSKVDhM9sfA4F
zDx/NUE5N9Ea+4HT1ykFpINWPzXkJLynhoO0rHZn8/41wur+wLt4NDiWTzeWHYytvLsy
ImuMxT2ks3FeKXrxAZPCE2j6WUdzIF1K69LhONPJnbpckcGnrcrNFYxl5TqLlzAwo28T
e82d/CWtoREIAQzw7ZaiKbYKs4Nuxkv6PGC3kMFgm7p+Jh1WVwUsN0wonJkGVrpgPFg8
wpIg==
X-Gm-Message-State: ALoCoQmcoJCU3Wx8IcmXR75y23zamr/B52vGt/i80CDu7LC+sv8NZVmoZz4F4vuGDFt/gq4Bn8l2
MIME-Version: 1.0
X-Received: by 10.181.13.195 with SMTP id fa3mr15393762wid.7.1436726239443;
Sun, 12 Jul 2015 11:37:19 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Sun, 12 Jul 2015 11:37:19 -0700 (PDT)
In-Reply-To: <CAE-z3OWOoHfMaEN04CQ-j8tzmAr1+Evjh+tfHRDbF6F1jxykHA@mail.gmail.com>
References: <CAFdHNGg2dezj4V-i-E6dRLp99nZMQ_ErKdBo0OgQJ=9WPm90jQ@mail.gmail.com>
<CABm2gDoAa5F5crO4enKO-Qqb+Zd3=9b8ohBDYmrygsPSWdevoQ@mail.gmail.com>
<CAE-z3OWOoHfMaEN04CQ-j8tzmAr1+Evjh+tfHRDbF6F1jxykHA@mail.gmail.com>
Date: Sun, 12 Jul 2015 20:37:19 +0200
Message-ID: <CABm2gDrPesyv95UHfDCRThaEkAQQ+rdQ1FN0ad0mFX9hTRj33A@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.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: Sun, 12 Jul 2015 18:37:22 -0000
On Sat, Jul 11, 2015 at 12:39 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
>
>
> On Sat, Jul 11, 2015 at 10:24 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wro=
te:
>>
>> 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 t=
ake
>> 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.
If miners aren't validating the blocks they mine on top of, an
attacker can do more nasty things I think.
> As long as miners switch back to non-SPV mining after a timeout, SPV-mini=
ng
> 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.
As long as miners switch back to the new longest chain after they
validate the block, mining on top of the
non-most-work-but-surely-valid may be less risky than mining on top of
a most-work-but-potentially-invalid block.
This has risks too. In both cases, if they don't mine a block during
the block validation, everything is fine.
If they successfully SPV mine, they risk having mined on top of an
invalid block, which not only means lost coins for them but high risk
for regular SPV users.
If they successfully mine on top of the previous block, they start a
mini-race that they can win or not, but the impact to regular SPV
users is much lower.
The later may be slightly less profitable, but I bet the difference is
negligible. It would be interesting to know if miners actually did
this numbers and how (in case their model is incomplete or flawed).
It is important to note that while SPV mining requires you to produce
empty blocks, mining on the previous on top of the previous block
allows you to include transactions and earn fees.
In a future where block rewards aren't so overwhelmingly dominated by
subsidies, the numbers will run against SPV mining.
In a future without (or with negligible) subsidy, SPV mining is always
inferior to just keep mining on top of the same block you were mining
until you fully validate the next one.
> It may be less of a problem if (when?) electricity costs dominate hardwar=
e
> capital costs.
This seems correct (for both cases).
It's also less worrying the shorter the full validation time of a block is.
|
