summaryrefslogtreecommitdiff
path: root/b3/9f934a3a2119118d0df2f2debdc0a6987e6fe9
blob: e0bae616a770925cd56809ae9f76665c5d8136e7 (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <robert@mckay.com>) id 1UO4Z1-0000En-Sd
	for bitcoin-development@lists.sourceforge.net;
	Fri, 05 Apr 2013 11:12:13 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of mckay.com
	designates 37.1.88.131 as permitted sender)
	client-ip=37.1.88.131; envelope-from=robert@mckay.com;
	helo=mail.mckay.com; 
Received: from mail.mckay.com ([37.1.88.131])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1UO4Z0-0001LK-6a
	for bitcoin-development@lists.sourceforge.net;
	Fri, 05 Apr 2013 11:12:11 +0000
Received: from www-data by mail.mckay.com with local (Exim 4.76)
	(envelope-from <robert@mckay.com>)
	id 1UO4De-0003Q7-Vw; Fri, 05 Apr 2013 11:50:07 +0100
To: Mike Hearn <mike@plan99.net>
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 05 Apr 2013 11:50:06 +0100
From: Robert McKay <robert@mckay.com>
In-Reply-To: <CANEZrP3S7b+uh2LW4vH=53opopLJRmmJ-_Uad6yEQxZ3kHW47A@mail.gmail.com>
References: <CAKaEYhLqnzrhdJNTSBccDA68Mb-hUnaZaCa9Gn43FuVpa410sg@mail.gmail.com>
	<CANEZrP3S7b+uh2LW4vH=53opopLJRmmJ-_Uad6yEQxZ3kHW47A@mail.gmail.com>
Message-ID: <bd376018d72b65a64a5124ebc2770d1a@webmail.mckay.com>
X-Sender: robert@mckay.com
User-Agent: Roundcube Webmail/0.5.3
X-Spam-Score: -4.0 (----)
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 SPF_PASS               SPF: sender matches SPF record
	-2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UO4Z0-0001LK-6a
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] A mining pool at 46%
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: Fri, 05 Apr 2013 11:12:13 -0000

On Fri, 5 Apr 2013 11:48:51 +0200, Mike Hearn wrote:
> However, youre somewhat right in the sense that its a self-defeating
> attack. If the pool owner went bad, he could pull it off once, but 
> the
> act of doing so would leave a permanent record and many of the people
> mining on his pool would leave. As he doesnt own the actual mining
> hardware, he then wouldnt be able to do it again.

Unless all the miners are monitoring the work they do for their pools 
and the actual miners that found the blocks noticed (unlikely) - the 
only way anyone knows which pool did anything is the source IP that 
first disseminates the new block. Also since it's unlikely that both of 
the doublespend blocks would be found by the same end miner, neither of 
them would know that the pool operator was responsible even if they were 
monitoring their work.

There's nothing stopping the pool owner from channeling the doublespend 
blocks through some other previously unknown IP, so I don't think they 
would suffer any reputational damage from doing this repeatidly.

Robert