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
|
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 <tier.nolan@gmail.com>) id 1YtaEC-0005dj-FQ
for bitcoin-development@lists.sourceforge.net;
Sat, 16 May 2015 11:26:00 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.173 as permitted sender)
client-ip=209.85.220.173; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f173.google.com;
Received: from mail-qk0-f173.google.com ([209.85.220.173])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YtaEA-0002bq-Fs
for bitcoin-development@lists.sourceforge.net;
Sat, 16 May 2015 11:26:00 +0000
Received: by qkai132 with SMTP id i132so19058967qka.2
for <bitcoin-development@lists.sourceforge.net>;
Sat, 16 May 2015 04:25:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.33.227 with SMTP id j90mr17752917qgj.6.1431775553118;
Sat, 16 May 2015 04:25:53 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Sat, 16 May 2015 04:25:53 -0700 (PDT)
In-Reply-To: <20150509030833.GA28871@savin.petertodd.org>
References: <554BE0E1.5030001@bluematt.me>
<CANEZrP3uKLvzKi-wXBJWL=pwqB+eAe3FbPjyESD52y5TGkg+Rg@mail.gmail.com>
<20150508163701.GA27417@savin.petertodd.org>
<CAE-z3OV8zyUyYiGNRZZbTkUZz70KK7P-ENyhsKe+yhZmNnqRuQ@mail.gmail.com>
<20150509030833.GA28871@savin.petertodd.org>
Date: Sat, 16 May 2015 12:25:53 +0100
Message-ID: <CAE-z3OWzPSkxr3y0u7F8SQBQoWL7DASjZ1BHbYvhTBiWdJXWBA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a113a7d023de54105163139c1
X-Spam-Score: 2.4 (++)
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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-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
1.9 MALFORMED_FREEMAIL Bad headers on message from free email service
-0.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YtaEA-0002bq-Fs
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
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: Sat, 16 May 2015 11:26:00 -0000
--001a113a7d023de54105163139c1
Content-Type: text/plain; charset=UTF-8
On Sat, May 9, 2015 at 4:08 AM, Peter Todd <pete@petertodd.org> wrote:
> > I wonder if having a "miner" flag would be good for the network.
>
> Makes it trivial to find miners and DoS attack them - a huge risk to the
> network as a whole, as well as the miners.
>
To mitigate against this, two chaintips could be tracked. The miner tip
and the client tip.
Miners would build on the miner tip. When performing client services, like
wallets, they would use the client tip.
The client would act exactly the same as any node, the only change would be
that it gives miner work based on the mining tip.
If the two tips end up significantly forking, there would be a warning to
the miner and perhaps eventually refuse to give out new work.
That would happen when there was a miner level hard-fork.
> That'd be an excellent way to double-spend merchants, significantly
> increasing the chance that the double-spend would succeed as you only
> have to get sufficient hashing power to get the lucky blocks; you don't
> need enough hashing power to *also* ensure those blocks don't become the
> longest chain, removing the need to sybil attack your target.
>
To launch that attack, you need to produce fake blocks. That is
expensive.
Stephen Cale's suggestion to wait more than one block before counting a
transaction as confirmed would also help mitigate.
--001a113a7d023de54105163139c1
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">On S=
at, May 9, 2015 at 4:08 AM, Peter Todd <span dir=3D"ltr"><<a href=3D"mai=
lto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D=
"">
> I wonder if having a "miner" flag would be good for the netw=
ork.<br>
<br>
</span>Makes it trivial to find miners and DoS attack them - a huge risk to=
the<br>
network as a whole, as well as the miners.<br></blockquote><div><br><div>To=
mitigate against this, two chaintips could be tracked.=C2=A0 The miner tip=
and the client tip.<br><br></div>Miners would build on the miner tip.=C2=
=A0 When performing client services, like wallets, they would use the clien=
t tip.<br><br><div>The client would act exactly the same as any node, the o=
nly change would be that it gives miner work based on the mining tip.<br></=
div><br></div><div>If the two tips end up significantly forking, there woul=
d be a warning to the miner and perhaps eventually refuse to give out new w=
ork.<br><br></div><div>That would happen when there was a miner level hard-=
fork.<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><span class=3D"">
</span>That'd be an excellent way to double-spend merchants, significan=
tly<br>
increasing the chance that the double-spend would succeed as you only<br>
have to get sufficient hashing power to get the lucky blocks; you don't=
<br>
need enough hashing power to *also* ensure those blocks don't become th=
e<br>
longest chain, removing the need to sybil attack your target.<br></blockquo=
te><div><br></div><div>To launch that attack, you need to produce fake bloc=
ks.=C2=A0 That is expensive.=C2=A0 <br><br>Stephen Cale's suggestion to=
wait more than one block before counting a transaction as confirmed would =
also help mitigate.<br></div></div></div></div>
--001a113a7d023de54105163139c1--
|
