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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@ceptacle.com>) id 1VdJS0-0002ur-D7
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 12:40:12 +0000
X-ACL-Warn:
Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129]
helo=mail.ceptacle.com)
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VdJRz-0007Av-DJ for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 12:40:12 +0000
Received: from localhost (localhost [127.0.0.1])
by mail.ceptacle.com (Postfix) with ESMTP id 92D8E3678E4A;
Mon, 4 Nov 2013 13:40:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at ceptacle.com
Received: from mail.ceptacle.com ([127.0.0.1])
by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id LvQwLpFT+FWZ; Mon, 4 Nov 2013 13:40:05 +0100 (CET)
Received: from MacGronager.local (cpe.xe-3-1-0-415.bynqe10.dk.customer.tdc.net
[188.180.67.254])
by mail.ceptacle.com (Postfix) with ESMTPSA id 338DF3678E3F;
Mon, 4 Nov 2013 13:40:04 +0100 (CET)
Message-ID: <527795A0.3080400@ceptacle.com>
Date: Mon, 04 Nov 2013 13:40:00 +0100
From: Michael Gronager <gronager@ceptacle.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Mike Hearn <mike@plan99.net>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
<52778BCE.8030904@ceptacle.com>
<CANEZrP3cfZ_SvyPmfinkGqERKrOJ8NR5ZvC4VfjRv=GsiabbdQ@mail.gmail.com>
In-Reply-To: <CANEZrP3cfZ_SvyPmfinkGqERKrOJ8NR5ZvC4VfjRv=GsiabbdQ@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1VdJRz-0007Av-DJ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
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: Mon, 04 Nov 2013 12:40:12 -0000
"We propose a simple, backwards-compatible change to the Bitcoin
protocol to address this problem and raise the threshold. Specifically,
when a miner learns of competing branches of the same length, it should
propagate all of them, and choose which one to mine on uniformly at random."
So only in the case of two competing chains... The "Selfish Miner" today
has an advantage knowing which chain the other will work on, and by
simply choosing the other they get their advantage making it likely that
it is the other that will waste their effort. By using the random scheme
this advantage is gone.
Note again that it is only in the case of two competing chains, which
will happen on average every 60 blocks. So it is only roughly once every
60 block that you change from choosing one chain to doing a 50% random.
A rough calculation on earnings will be that you loose roughly 1/(2*60)
~ 1% of your blocks using this scheme. But at the same time you make it
harder for such an attack to happen. (This number might be slightly
higher, as working in parallel on both chains will make the two chains
last longer, so agree that we need a bit more analysis...)
I also agree that it is a kind of a Sybil attack, but I think we should
accept the risk of a Sybil attack but of course minimize it, rather than
introducing various social network (ip addresses) solutions, which in
one way or the other always have some central auth / oracle assumption.
On 4/11/13, 13:03 , Mike Hearn wrote:
> The suggested change is actually very simple (minutes of coding) and
> elegant and addresses precisely the identified problem.
>
>
> Disagree. Unless I'm misunderstanding what they propose, their suggested
> change would mean anyone could broadcast a newly discovered block at any
> point and have a 50% chance of being the winner. That is a fundamental
> change to the dynamics of how Bitcoin works that would require careful
> thought and study.
>
> Also, their solution doesn't really address the problem they bring up,
> it just changes the size of the threshold required.
>
> Fundamentally, their attack is a sybil attack. It doesn't work if they
> can't delay or block a pools competitors because mostly their block will
> come in second place and they'll lose the race. Thus the solution should
> be a solution to sybil attacks.
|
