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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VdIsu-0002XF-CZ
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 12:03:56 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.178 as permitted sender)
client-ip=209.85.214.178; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f178.google.com;
Received: from mail-ob0-f178.google.com ([209.85.214.178])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VdIst-0006NB-MW
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 12:03:56 +0000
Received: by mail-ob0-f178.google.com with SMTP id wm4so6885507obc.23
for <bitcoin-development@lists.sourceforge.net>;
Mon, 04 Nov 2013 04:03:50 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.42.203 with SMTP id q11mr861603oel.54.1383566630305; Mon,
04 Nov 2013 04:03:50 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Mon, 4 Nov 2013 04:03:50 -0800 (PST)
In-Reply-To: <52778BCE.8030904@ceptacle.com>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
<52778BCE.8030904@ceptacle.com>
Date: Mon, 4 Nov 2013 13:03:50 +0100
X-Google-Sender-Auth: LwesrqqpQuoV6vUh2yZiLPJZsV0
Message-ID: <CANEZrP3cfZ_SvyPmfinkGqERKrOJ8NR5ZvC4VfjRv=GsiabbdQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Michael Gronager <gronager@ceptacle.com>
Content-Type: multipart/alternative; boundary=001a11c207f085c5eb04ea58b573
X-Spam-Score: -0.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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1VdIst-0006NB-MW
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:03:56 -0000
--001a11c207f085c5eb04ea58b573
Content-Type: text/plain; charset=UTF-8
>
> 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.
--001a11c207f085c5eb04ea58b573
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(34,34=
,34)">The suggested change is actually very simple (minutes of coding) and<=
/span><br>
</div>
elegant and addresses precisely the identified problem. <br></blockquote><d=
iv><br></div><div>Disagree. Unless I'm misunderstanding what they propo=
se, their suggested change would mean anyone could broadcast a newly discov=
ered 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 requir=
e careful thought and study.</div>
<div><br></div><div>Also, their solution doesn't really address the pro=
blem they bring up, it just changes the size of the threshold required.=C2=
=A0</div><div><br></div><div>Fundamentally, their attack is a sybil attack.=
It doesn't work if they can't delay or block a pools competitors b=
ecause mostly their block will come in second place and they'll lose th=
e race. Thus the solution should be a solution to sybil attacks.</div>
</div></div></div>
--001a11c207f085c5eb04ea58b573--
|
