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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
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 1VdM4U-0004d4-Be
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 15:28:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.180 as permitted sender)
client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f180.google.com;
Received: from mail-ob0-f180.google.com ([209.85.214.180])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VdM4S-0005gH-Cz
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 15:28:06 +0000
Received: by mail-ob0-f180.google.com with SMTP id wo20so7092218obc.25
for <bitcoin-development@lists.sourceforge.net>;
Mon, 04 Nov 2013 07:27:59 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.155.145 with SMTP id vw17mr1889895oeb.50.1383578879024;
Mon, 04 Nov 2013 07:27:59 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Mon, 4 Nov 2013 07:27:58 -0800 (PST)
In-Reply-To: <20131104142621.GA2190@petertodd.org>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
<20131104142621.GA2190@petertodd.org>
Date: Mon, 4 Nov 2013 16:27:58 +0100
X-Google-Sender-Auth: blkQ34pMifkSSdbOZSEZZFrknNc
Message-ID: <CANEZrP0pUvyP62NKu2hdzFYxaMdD7iPPmkL699-gZksZa=HHzg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7bf0e94c9a673a04ea5b8f7f
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
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: petertodd.org]
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: 1VdM4S-0005gH-Cz
Cc: Ittay Eyal <ittay.eyal@cornell.edu>,
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 15:28:06 -0000
--047d7bf0e94c9a673a04ea5b8f7f
Content-Type: text/plain; charset=UTF-8
On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd <pete@petertodd.org> wrote:
> The attacker now only needs to connect to every identified miner
> with especially fast nodes. With judicious use of DoS attacks and low
> latency .....
>
So you're back to a complicated sybil attack. I don't follow your thought
process here - I didn't say anything about numerical advantage. The attack
outlined in the paper *requires* you to be able to race the rest of the
network and win some non-trivial fraction of the time. If you can't do that
then all it means is that when you try to release a private block to
compete with the other found block, you're quite likely to lose and you
sacrifice the block rewards by doing so.
> The correct, and rational, approach for a miner is to always mine to
> extend the block that the majority of hashing power is trying to extend.
>
There's no stable way to know that. The whole purpose of the block chain to
establish the majority. I think your near-miss headers solution is
circular/unstable for that reason, it's essentially a recursive solution.
> Mining strategy is now to mine to extend the first block you see, on the
> assumption that the earlier one probably propagated to a large portion
> of the total hashing power. But as you receive "near-blocks" that are
> under the PoW target, use them to estimate the hashing power on each
> fork, and if it looks like you are not on the majority side, switch.
>
But you can't reliably estimate that. You can't even reliably estimate the
speed of the overall network especially not on a short term basis like a
block interval.
--047d7bf0e94c9a673a04ea5b8f7f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd <span dir=3D"lt=
r"><<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@peterto=
dd.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(3=
4,34,34)">The attacker now only needs to connect to every identified miner<=
/span><br>
</div>
with especially fast nodes. With judicious use of DoS attacks and low<br>
latency .....<br></blockquote><div><br></div><div>So you're back to a c=
omplicated sybil attack. I don't follow your thought process here - I d=
idn't say anything about numerical advantage. The attack outlined in th=
e paper <b>requires</b>=C2=A0you to be able to race the rest of the network=
and win some non-trivial fraction of the time. If you can't do that th=
en all it means is that when you try to release a private block to compete =
with the other found block, you're quite likely to lose and you sacrifi=
ce the block rewards by doing so.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">The correct, and rational, =
approach for a miner is to always mine to<br>
extend the block that the majority of hashing power is trying to extend.<br=
></blockquote><div><br></div><div>There's no stable way to know that. T=
he whole purpose of the block chain to establish the majority. I think your=
near-miss headers solution is circular/unstable for that reason, it's =
essentially a recursive solution.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Mining strategy is now to m=
ine to extend the first block you see, on the<br>
assumption that the earlier one probably propagated to a large portion<br>
of the total hashing power. But as you receive "near-blocks" that=
are<br>
under the PoW target, use them to estimate the hashing power on each<br>
fork, and if it looks like you are not on the majority side, switch.<br></b=
lockquote><div><br></div><div>But you can't reliably estimate that. You=
can't even reliably estimate the speed of the overall network especial=
ly not on a short term basis like a block interval.</div>
</div></div></div>
--047d7bf0e94c9a673a04ea5b8f7f--
|
