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
169
170
171
172
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1VeVpt-0004HP-TW
for bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 20:05:49 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.172 as permitted sender)
client-ip=209.85.215.172; envelope-from=adam.back@gmail.com;
helo=mail-ea0-f172.google.com;
Received: from mail-ea0-f172.google.com ([209.85.215.172])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VeVps-0002tj-Ku
for bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 20:05:49 +0000
Received: by mail-ea0-f172.google.com with SMTP id r16so602517ead.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 Nov 2013 12:05:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:user-agent;
bh=zCE8XpFGawSvFrmBDAaESesEWGBsKC4rtjw9k0/kqTw=;
b=AWy+gBLpz6hc8PCnzTLUTOI2s1jyoOqSOScVwfh0tnbrg2tJUx7nHIIZeCiVH/0hWA
Y6JrPkN1bEuii5v9YJ0FA0E1vFjNw7xPCm1Z1oKlpFLKD8lM4x3CiLXsjcdC18urDTPx
uwpKs2nWIPcmhSnw2Y2UAPLMZmxXGSChovi85IZLUDSF+pc2KzDHcPRF+KSf6LAbRjTG
Gi2BuflNVhE17T6lD4jJUMav2YoDrg9q8jO1iGQjcGntgnskH0t3egbkIdQfah3mxrbq
pTqy/STCsNdsh0vgVlQTDWXH4kH09/KFt/Mm3VcI4QELY1trjFxP1icmeNF6Cpqbu/bQ
u/fg==
X-Received: by 10.15.41.3 with SMTP id r3mr4105632eev.74.1383854742267;
Thu, 07 Nov 2013 12:05:42 -0800 (PST)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id a6sm13335705eei.10.2013.11.07.12.05.40
for <multiple recipients>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 07 Nov 2013 12:05:41 -0800 (PST)
Received: by netbook (Postfix, from userid 1000)
id 007472E288B; Thu, 7 Nov 2013 21:05:38 +0100 (CET)
Received: by flare (hashcash-sendmail, from uid 1000);
Thu, 7 Nov 2013 21:05:34 +0100
Date: Thu, 7 Nov 2013 21:05:34 +0100
From: Adam Back <adam@cypherspace.org>
To: Ittay <ittay.eyal@cornell.edu>
Message-ID: <20131107200534.GA27068@netbook.cypherspace.org>
References: <CABT1wWkOukEzxK5fLbnA4ZgJGN1hb_DMteCJOfA13FE_QZCi=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CABT1wWkOukEzxK5fLbnA4ZgJGN1hb_DMteCJOfA13FE_QZCi=Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:131107:ittay.eyal@cornell.edu::zO1b9WwN6O58wj9E:000000000000000
0000000000000000000000001U6U
X-Hashcash: 1:20:131107:bitcoin-development@lists.sourceforge.net::8hozK4W0GuAMT
s7s:000000000000000000002z8Q
X-Hashcash: 1:20:131107:gavin@bitcoinfoundation.org::ZJEzIt0Ngu1V/bCX:0000000000
000000000000000000000000EGPm
X-Hashcash: 1:20:131107:egs@systems.cs.cornell.edu::SKWz3XKUsP0HLStF:00000000000
0000000000000000000000005MKt
X-Hashcash: 1:20:131107:adam@cypherspace.org::P8IWZF2Y0Y8cikMP:00000000000000000
00000000000000000000000053qn
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(adam.back[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1VeVps-0002tj-Ku
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Gavin Andresen <gavin@bitcoinfoundation.org>,
Emin =?iso-8859-1?B?R/xu?= Sirer <egs@systems.cs.cornell.edu>
Subject: [Bitcoin-development] comments on selfish-mining model (Re: BIP
proposal - patch to raise selfish mining threshold.)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2013 20:05:50 -0000
(Talking about the paper, not the BIP). With regard to racing the other
winner which catches up when private pool length=1:
i) the model does not appear to take into account that when another pool
goes on to mine a block, and the attacker publishes their selfishly-withheld
block, the selfish pool will not be able to change the existing winners
mind. This is not insignificant as the pools have 30%, 20%, 15%, 7% etc.
ii) The miners already have an incentive, as other big bitcoin processors,
to maintain fast, secure and redundant links to other significant miners.
The attacker is giving up a large proportion of their winnings from the
times that they win at all. Say the attacker IS the 30% pool, when he wins
and waits for someone else to win, > 80% of the network is pool mined, so
there is a good chance that the other winner individually represents a
non-negligible proportion of the network or a sufficiently well connected
portion of the network that the attacker will be unable to race them to
publication with a useful proportion of the network.
iii) Also broadcast is not instantaneous, lets say network propagation takes
10 seconds; a big proportion of the time, the actual mining times will be
more than 5 seconds apart so that by the time the selfish miner learns of
the block, much of the network will already have accepted it block as first.
iv) Even within the 10 seconds ambiguity period, the more powerful miner
will tend statistically to come first, and so reach a bigger portion of the
network, as well as having a stronger incentive to maintain links as in ii).
These four factors erode the achievable \gamma parameter. I suspect it
unlikely \gamma>0.5 would be achievable, putting the profitable threshold
\alpha in 25% - 33%. (And assuming whatever techniques to reduce latency
are used by the selfish pools can be used by other pools.)
Your main result that even with \gamma=0 (if you dont win any races) that
you still win once the selfish pool reaches 33% is an important new
indication, which needs further consideration. (And you could expect to win
some percentage \gamma>0 even with the factors I mention, and full
implementation of the same latency reduction techniques in all moderate
sized miners, selfish and normal).
It is also not clear what will happen if multiple selfish miners compete
with each other. A selfish miner cooperating as a peer to increase
percentage runs risk of mutual sabotage - he has to announce his private
block to his co-conspirator, and the co-conspirator may publish, or collude
with another non-selfish miner.
Your supposition is there is a profit motive to collude. However there are
other profit motives in bitcoin that are not exercised - for example there
were for sometime 2 pools that had excess of 50% power, and yet this was not
abused for double spending. Of course increasing profit by a new mining
strategy is not theft as double spending which has a clear loser. Miners
even exercised restraint and volutarily avoided growing over 50%.
As others have I think said by now analysis is welcome. It seems that Peter
Todd may have observed the same or something similar wrt miner incentives
some months ago, though it wasnt as widely read nor formally verified.
It might be useful to release the source for your simulator if that is open
to you.
In my opinion a constructive direction for reducing centralization risks is
to try to reduce the use of and motivation for pools. Even at <51% per pool
there is (probabilistic) miner risk in double-spends. And there is risk
that the large miners evolve to become a defacto policy enforcement point
for policies not aligned with user interests, or with fungibility of bitcoin
which itself presents another kind of risk (defacto reduced fungibility
should this arise would also be bad for bitcoin).
Also without even having mining power, there is scope to network hacking (eg
of routers in front of miners) to influence the mining profit, and even
double spend. As I mentioned large miners have an incentive to maintain
secure redudant links (probably some links using Tor for blocks) as a
counter-measure.
Adam
On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
> Hello,
> Please see below our BIP for raising the selfish mining threshold.
> Looking forward to your comments.
|
