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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <stanga@gmail.com>) id 1VdpRb-0003UZ-Np
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Nov 2013 22:49:55 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.179 as permitted sender)
client-ip=209.85.217.179; envelope-from=stanga@gmail.com;
helo=mail-lb0-f179.google.com;
Received: from mail-lb0-f179.google.com ([209.85.217.179])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VdpRZ-0007AO-Gi
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Nov 2013 22:49:55 +0000
Received: by mail-lb0-f179.google.com with SMTP id w6so7201678lbh.10
for <bitcoin-development@lists.sourceforge.net>;
Tue, 05 Nov 2013 14:49:46 -0800 (PST)
X-Received: by 10.152.28.105 with SMTP id a9mr3098145lah.41.1383691786760;
Tue, 05 Nov 2013 14:49:46 -0800 (PST)
MIME-Version: 1.0
Sender: stanga@gmail.com
Received: by 10.112.105.35 with HTTP; Tue, 5 Nov 2013 14:49:26 -0800 (PST)
In-Reply-To: <op.w53ax8dtyldrnw@laptop-air>
References: <CABT1wWkOukEzxK5fLbnA4ZgJGN1hb_DMteCJOfA13FE_QZCi=Q@mail.gmail.com>
<20131105170541.GA13660@petertodd.org>
<CABT1wWnPJOKKT5v2hGePkUT8jNau=TEK5s-n2so2kQKnv-HfqQ@mail.gmail.com>
<op.w53ax8dtyldrnw@laptop-air>
From: Ittay <ittay.eyal@cornell.edu>
Date: Tue, 5 Nov 2013 17:49:26 -0500
X-Google-Sender-Auth: LBKqMua00DxtH_gXI5Rau4lwxo0
Message-ID: <CABT1wW=cKEA+TU5+n1n0cqvqwx8oWgpUXRmGJQCNLfQehxs6bQ@mail.gmail.com>
To: Jeremy Spilman <jeremy@taplink.co>
Content-Type: multipart/alternative; boundary=089e0160a2406db69204ea75d96c
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
(stanga[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: ethz.ch]
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: 1VdpRZ-0007AO-Gi
Cc: Ittay <ittay.eyal@cornell.edu>,
Gavin Andresen <gavin@bitcoinfoundation.org>,
=?ISO-8859-1?Q?Emin_G=FCn_Sirer?= <egs@systems.cs.cornell.edu>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP proposal - patch to raise selfish
mining threshold.
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: Tue, 05 Nov 2013 22:49:55 -0000
--089e0160a2406db69204ea75d96c
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
> I think it's a stretch to say 'y' is 0 with good connectivity. Even the
> best connected mining pools today are concerned with this 'y' factor.
>
Check out the following paper for the effect a single node can have on
propagation, and on the relation between block size and propagation speed.
This strongly supports our assumption.
http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
>
> Here's a probably very dumb idea... to throw out one possible "solution"...
>
> You want a way to fake-out the 'selfish miner' into disclosing their
> blocks -- how can your force their hand to prevent them from accumulating
> longer private chains?
>
> What if you propagate (and relay) an encrypted block header which honest
> miners will timestamp when they receive it, then 10 seconds later propagate
> the decryption key to unblind it. But here's the catch - maybe the
> decryption results in junk, maybe it results a new longer block. If it's a
> real block then it gets priority based on when the ciphertext was received
> instead of when the decryption key was received. Now 'selfish miner' can't
> race the network anymore, because they are always in state 0' and can't
> tell if they are up against a ghost, or a real competing block. If they
> wait for the decryption key to check, it's too late, and they are
> guaranteed to lose unless they can out-race the network, e.g. back at
> t=50%. Of course there would need to be some way to anti-DDoS this which
> allows for some amount of these fake-outs without letting them get out of
> hand.
>
That's a dangerous way to go, opening the door to DoS attacks, as you
mention. Besides, it makes a simple algorithm complicated, and doing such
changes may lead to different vulnerabilities that are difficult to cover.
Best,
Ittay
--089e0160a2406db69204ea75d96c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jeremy@taplink.co" target=3D"_blank">jeremy@taplink.co<=
/a>></span> wrote:<br>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div><div></div><div>I think it's a stre=
tch to say 'y' is 0 with good connectivity. Even the best connected=
mining pools today are concerned with this 'y' factor.=A0</div>
</div></blockquote><div><br></div><div>Check out the following paper for th=
e effect a single node can have on propagation, and on the relation between=
block size and propagation speed. This strongly supports our assumption.=
=A0</div>
<div><a href=3D"http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b2=
3fc0/P2P2013_041.pdf">http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7f=
da78b23fc0/P2P2013_041.pdf</a><br></div><div>=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div><br></div><div>Here's a probably very dumb idea... to throw o=
ut one possible "solution"...</div><div><br></div><div>You want a=
way to fake-out the 'selfish miner' into disclosing their blocks -=
- how can your force their hand to prevent them from accumulating longer pr=
ivate chains?</div>
<div><br></div><div>What if you propagate (and relay) an encrypted block he=
ader which honest miners will timestamp when they receive it, then 10 secon=
ds later propagate the decryption key to unblind it. But here's the cat=
ch - maybe the decryption results in junk, maybe it results a new longer bl=
ock. If it's a real block then it gets priority based on when the ciphe=
rtext was received instead of when the decryption key was received. Now =
9;selfish miner' can't race the network anymore, because they are a=
lways in state 0' and can't tell if they are up against a ghost, or=
a real competing block. If they wait for the decryption key to check, it&#=
39;s too late, and they are guaranteed to lose unless they can out-race the=
network, e.g. back at t=3D50%. Of course there would need to be some way t=
o anti-DDoS this which allows for some amount of these fake-outs without le=
tting them get out of hand.</div>
</div></blockquote><div><br></div><div>That's a dangerous way to go, op=
ening the door to DoS attacks, as you mention. Besides, it makes a simple a=
lgorithm complicated, and doing such changes may lead to different vulnerab=
ilities that are difficult to cover.=A0</div>
<div></div></div><br></div><div class=3D"gmail_extra">Best,=A0</div><div cl=
ass=3D"gmail_extra">Ittay=A0</div><div class=3D"gmail_extra"><br></div></di=
v>
--089e0160a2406db69204ea75d96c--
|
