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
|
Return-Path: <operator@bitminter.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 493E510AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 00:45:53 +0000 (UTC)
X-Greylist: delayed 00:08:08 by SQLgrey-1.7.6
Received: from outpost.bitwarp.com (outpost.bitwarp.com [144.76.39.233])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7D32FE0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Dec 2015 00:45:52 +0000 (UTC)
To: bitcoin-dev@lists.linuxfoundation.org
References: <20151219184240.GB12893@muck>
<CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com>
<219f125cee6ca68fd27016642e38fdf1@xbt.hk>
<CAAcC9ys_t7X0WpQ8W3577M8GLiA5sPV2F1BJ9qZbnMkE-1j3+Q@mail.gmail.com>
<aff8da46a69bdd7ef92ca87725866a5c@xbt.hk>
<CAPkFh0vNECi1OmBwki+8NNAQbe6EG2FEE4RR5z=kYVLLDFHUXg@mail.gmail.com>
<20151220132842.GA25481@muck>
<CAPkFh0t-+WhZYVLyT_auLa87zAATNOH=CpU4S5H=n6S1wmZ-oQ@mail.gmail.com>
From: Geir Harald Hansen <operator@bitminter.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <567DE16E.8040001@bitminter.com>
Date: Sat, 26 Dec 2015 01:38:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <CAPkFh0t-+WhZYVLyT_auLa87zAATNOH=CpU4S5H=n6S1wmZ-oQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 26 Dec 2015 02:27:42 +0000
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
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, 26 Dec 2015 00:45:53 -0000
On 20.12.2015 18:00, Emin Gün Sirer via bitcoin-dev wrote:
> Instead, we will have the bigger
> pools become more suspicious of signing up new hash power, which is a
> good thing.
Block withholding attacks do not differentiate between small and large
pools. When Eligius and BTCGuild got hit with this, they were far from
the biggest pools at the time.
When my pool, Bitminter, got a new large miner who found 1 block where
average luck would have had them find 3, one of the other miners claimed
they must be withholding blocks. Even if there is no logic or evidence
behind it, after one person cries wolf the others get nervous. This way
even the possibility of block withholding can keep smaller pools from
growing. It takes more hashpower to put a dent in a bigger pool, so you
will see less such panic.
> And we will have small groups of people who have some reason
> for trusting each other (e.g. they know each other from IRC, conferences,
> etc) band together into small pools. These are fantastic outcomes for
> decentralization.
Three guys with 1 TH/s, 2 TH/s and 100 GH/s meet at a conference and
decide to start a private pool? Obviously that doesn't work. Maybe three
people with huge warehouses of miners would work together if they knew
and trusted each other.
Those small miners need to mine with people they don't know to get an
acceptable variance.
If you kill off mining pools then small miners have no way to achieve
acceptable variance and they will disappear. There will only be big
warehouse miners left, the ones who are big enough to solo mine.
That's not helping decentralization.
> Right, it's not clear at all that yelling at people has much effect. As much
> fun as I had going to that meeting with GHash in London to ask them to
> back down off of the 51% boundary, I am pretty sure that yelling at large
> open pools will not scale. We needed better mechanisms for keeping pools
> in check.
I agree. It's very disappointing how most miners and pools handle this
(BTCGuild being the exception). But I do not think block withholding is
a good tool. It can easily destroy small pools, but it won't put a dent
in a pool that goes over 50%.
Block withholding is a tool big pools can use to put smaller competitors
out of business.
And even if it was effective I would not use block withholding to attack
other pools.
> And Miner's Dilemma (MD) attacks are clearly quite effective. This is a
> time when we should count our blessings, not work actively to render
> them inoperable.
Is it? Is there any example of block withholding leading to more
decentralized mining?
If I remember right, GHash being too big ended with BitFury moving some
of their hashpower out of the pool. I don't know where that hashpower
went and whether the problem was solved or merely hidden.
GHash profitability being very low for some time wasn't due to block
withholding, it was a bug that some miners abused to get paid for the
same work multiple times. This made it look like a lot of work was done
while finding few blocks.
> Basically you have the pool pick a secret k for each share, and commit
> to H(k) in the share. Additionally the share commits to a target divider
> D. The PoW validity rule is then changed from H(block header) < T, to be
> H(block header) < T * D && H(H(block header) + k) < max_int / D
>
>
> Thanks, this requires a change to the Bitcoin PoW. Good luck with that!
>
> Once again, this suggestion would make the GHash-at-51% situation
> possible again. Working extra hard to re-enable those painful days
> sounds like a terrible idea.
Block withholding didn't solve the problem back then. And guess what,
those painful days are here right now. China is at 65% and block
withholding isn't solving it.
I was disappointed when GHash got too big and refused to do anything. It
was sad when their miners didn't do anything. Then they used
double-spends to scam a casino. I was shocked that noone cared. Now two
thirds of the bitcoin hashpower is within the control of a single
government. This time I expected noone would care - but I'm still
disappointed. I'm also surprised at the irrational behavior; there are
so many who go out of their way to put their own investments in danger.
For a long time now many miners and pools have been irresponsible with
the hashpower. But block withholding just makes it worse.
Regards,
Geir H. Hansen, Bitminter mining pool
|
