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
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 27FC41168
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Dec 2015 19:00:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com
[209.85.214.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10348164
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Dec 2015 18:59:59 +0000 (UTC)
Received: by mail-ob0-f177.google.com with SMTP id ba1so164649941obb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Dec 2015 10:59:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=yiK1AP+MI97CEAfSA27BoL2LTl3/b2yTsGWuI1rrra4=;
b=1CKPyh/JwCvtHbt9Rp8qoa0yZpkEhP9wCJ1K4F0U3mETmZKRgnNaeEkMKPsMEAKI/v
EAJYV5kn0Ew+OOxxALu1wGVYyhDp+iffVLFfS6ufxiwz2GnNsQEScW4y09nuRXcDCQ+7
9O0TJD632N9qaKfDuVb94riCXFGGsP3fHZINdwF4rfH19bFmQZ9zEq04aOVi4b68orsf
vWrwAjK7qmXwLcDdOn0cdqhkmPyaHlG3CBKxTN81KwbVTfYcVvvUnU5hCADhk8ai9uiB
iWwEziHvqpV4W2MaWhOB0zm0yGiLf8WdoCCKZstRN7ZtIrNzJX5ogEaBRyTqygP1uwqE
NGPA==
MIME-Version: 1.0
X-Received: by 10.182.66.137 with SMTP id f9mr10473277obt.42.1451415598373;
Tue, 29 Dec 2015 10:59:58 -0800 (PST)
Sender: dscotese@gmail.com
Received: by 10.60.125.35 with HTTP; Tue, 29 Dec 2015 10:59:58 -0800 (PST)
In-Reply-To: <CAAre=ySPjm+cyLdBY_CZkLdfXE3OFYgECEUq05AyWfY0q1KuTQ@mail.gmail.com>
References: <20151219184240.GB12893@muck>
<CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com>
<4882BD35-D890-4860-9222-5C23AEB6AE89@mattcorallo.com>
<CAAcC9yspsPs3gbumS4rTOg-P-=V=tycn2Z1nVPGGHwJ-nP+PBg@mail.gmail.com>
<20151220044450.GA23942@muck>
<CAP3QyGJD3SaM6Bvvw66jAvVFkQhrfJfRQTxbbe8a=O1zK_P6tw@mail.gmail.com>
<20151228191228.GC12298@muck>
<CAAre=ySPjm+cyLdBY_CZkLdfXE3OFYgECEUq05AyWfY0q1KuTQ@mail.gmail.com>
Date: Tue, 29 Dec 2015 10:59:58 -0800
X-Google-Sender-Auth: s2Ue-HSFiEZ2wGEQShcDY-vjNdM
Message-ID: <CAGLBAhdqKLgK09s5Mp6C4nv0k4hHBYM5c8NpgP5G7J110NseqQ@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Ivan Brightly <ibrightly@gmail.com>
Content-Type: multipart/alternative; boundary=089e0160c35a29a32405280e07fd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Dec 2015 19:00:00 -0000
--089e0160c35a29a32405280e07fd
Content-Type: text/plain; charset=UTF-8
There have been no decent objections to altering the block-selection
mechanism (when two block solutions appear at nearly the same time) as
described at
http://bitcoin.stackexchange.com/questions/39226
Key components are:
- Compute BitcoinDaysDestroyed using only transactions that have been in
your mempool for some time as oBTCDD ("old BTCDD").
- Use "nearly the same time" to mean separated in time by your guess of
the average duration of block propagation times.
- When two block solutions come in at nearly the same time, build on the
one that has the most oBTCDD, rather than the one that came in first.
The goal of this change is to reduce the profitability of withholding block
solutions by severely reducing the chances that a block solved a while ago
can orphan one solved recently. "Came in first" seems more easily gamed
than "most oBTCDD". As I wrote there, "*old coins* is always a dwindling
resource and *global nodes willing to help cheat* is probably a growing
one."
I will write a BIP if anyone agrees it's a good idea.
On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Far more concerning is network propagation effects between large and
>> small miners. For that class of issues, if you are in an environemnt
>> where selfish mining is possible - a fairly flat, easily DoS/sybil
>> attacked network topology - the profitability difference between small
>> and large miners even *without* attacks going on is a hugely worrying
>> problem. OTOH, if you're blocksize is small enough that propagation time
>> is negligable to profitability, then selfish mining attacks with <30%
>> hashing power aren't much of a concern - they'll be naturally defeated
>> by anti-DoS/anti-sybil measures.
>>
>
> Let's agree that one factor in mining profitability is bandwidth/network
> reliability/stability. Why focus on that vs electricity contracts or
> vertically integrated chip manufacturers? Surely, sufficient network
> bandwidth is a more broadly available commodity than <$0.02/kwh
> electricity, for example. I'm not sure that your stranded hydroelectric
> miner is any more desirable than thousands of dorm room miners with access
> to 10gbit university connections and free electricity.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
--089e0160c35a29a32405280e07fd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>There have been no decent objections to altering the =
block-selection mechanism (when two block solutions appear at nearly the sa=
me time) as described at <br><br><a href=3D"http://bitcoin.stackexchange.co=
m/questions/39226">http://bitcoin.stackexchange.com/questions/39226</a><br>=
<br></div>Key components are:<br><ul><li>Compute BitcoinDaysDestroyed using=
only transactions that have been in your mempool for some time as oBTCDD (=
"old BTCDD").</li><li>Use "nearly the same time" to mea=
n separated in time by your guess of the average duration of block propagat=
ion times.<br></li><li>When two block solutions come in at nearly the same =
time, build on the one that has the most oBTCDD, rather than the one that c=
ame in first.</li></ul><p>The goal of this change is to reduce the profitab=
ility of withholding block solutions by severely reducing the chances that =
a block solved a while ago can orphan one solved recently.=C2=A0 "Came=
in first" seems more easily gamed than "most oBTCDD".=C2=A0=
As I wrote there, "<em>old coins</em> is always a dwindling resource =
and <em>global nodes willing to help cheat</em> is probably a growing one.&=
quot;<br></p><p>I will write a BIP if anyone agrees it's a good idea.<b=
r></p></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mo=
n, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev <span dir=3D"ltr=
"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" sty=
le=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">On Mon, Dec 28, 2015=
at 2:12 PM, Peter Todd via bitcoin-dev=C2=A0<span dir=3D"ltr"><<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>></span>=C2=A0wrote:<br>
Far more concerning is network propagation effects between large and<br>
small miners. For that class of issues, if you are in an environemnt<br>
where selfish mining is possible - a fairly flat, easily DoS/sybil<br>
attacked network topology - the profitability difference between small<br>
and large miners even *without* attacks going on is a hugely worrying<br>
problem. OTOH, if you're blocksize is small enough that propagation tim=
e<br>
is negligable to profitability, then selfish mining attacks with <30%<br=
>
hashing power aren't much of a concern - they'll be naturally defea=
ted<br>
by anti-DoS/anti-sybil measures.<br></blockquote><div><br></div></span><div=
>Let's agree that one factor in mining profitability is bandwidth/netwo=
rk reliability/stability. Why focus on that vs electricity contracts or ver=
tically integrated chip manufacturers? Surely, sufficient network bandwidth=
is a more broadly available commodity than <$0.02/kwh electricity, for =
example. I'm not sure that your stranded hydroelectric miner is any mor=
e desirable than thousands of dorm room miners with access to 10gbit univer=
sity connections and free electricity.</div></div></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature"><div dir=3D"ltr">I like to provide some work at no charge to pr=
ove my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"http://www.l=
itmocracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"http://www.m=
emeracing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I'm th=
e webmaster for <a href=3D"http://www.voluntaryist.com" target=3D"_blank">T=
he Voluntaryist</a> which now accepts Bitcoin.<br>I also code for <a href=
=3D"http://dollarvigilante.com/" target=3D"_blank">The Dollar Vigilante</a>=
.<br>"He ought to find it more profitable to play by the rules" -=
Satoshi Nakamoto</div></div>
</div>
--089e0160c35a29a32405280e07fd--
|
