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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1RTEqS-0000K3-Uy
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 15:34:44 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=etotheipi@gmail.com;
helo=mail-vw0-f47.google.com;
Received: from mail-vw0-f47.google.com ([209.85.212.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RTEqO-0007LR-W9
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Nov 2011 15:34:44 +0000
Received: by vbbfc21 with SMTP id fc21so258282vbb.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Nov 2011 07:34:35 -0800 (PST)
Received: by 10.52.36.41 with SMTP id n9mr26008791vdj.41.1322062475525;
Wed, 23 Nov 2011 07:34:35 -0800 (PST)
Received: from [192.168.1.85] (c-76-111-108-35.hsd1.md.comcast.net.
[76.111.108.35])
by mx.google.com with ESMTPS id a2sm18787231vdj.3.2011.11.23.07.34.34
(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 07:34:34 -0800 (PST)
Message-ID: <4ECD12AA.6080605@gmail.com>
Date: Wed, 23 Nov 2011 10:35:06 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <201111231035.48690.andyparkins@gmail.com> <CAGQP0AEZ9CUNd9ERyMsx741bqjLptY4pPRU6EmxQcD7kR8bdbw@mail.gmail.com> <CALxbBHVEvCqun0aX_9awGhW39h5cx0jLPx2ptoesBcmKGO-_Dw@mail.gmail.com> <201111231313.12534.andyparkins@gmail.com> <CALxbBHW2KGv=sEvYqpGGsy8jjJ3+yE02BegwPhjGapuT9z7v_Q@mail.gmail.com>
<CABsx9T0VH5i0HrEjxfxxtzO2MtmN7UEyAUXoq9puc-1nKw3G4Q@mail.gmail.com>
In-Reply-To: <CABsx9T0VH5i0HrEjxfxxtzO2MtmN7UEyAUXoq9puc-1nKw3G4Q@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------020304080106000507000405"
X-Spam-Score: -0.8 (/)
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
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
-0.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RTEqO-0007LR-W9
Subject: Re: [Bitcoin-development] Addressing rapid changes in mining power
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: Wed, 23 Nov 2011 15:34:45 -0000
This is a multi-part message in MIME format.
--------------020304080106000507000405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I can substantiate Gavin's point quite powerfully: a couple months ago I
did a search for the "hardest" block in the network and found a *very
**impressive* one:
https://bitcointalk.org/index.php?topic=29675.0
That block has a difficulty of **36 billion** when the network had a
difficulty of **1.5 million**, which is 24,000 times harder than the
target. If we were going by the /actual /hardest chain instead
target-based-hardest chain, /then this block produced in July would
might still represent the longest chain!/
Yes, that means that whichever miner produced this block, could've held
onto it for 2-4 months without doing anything else, and then broadcast
it to fork the blockchain from a block produced months ago. That's not
theoretical, that's real data in the blockchain and it would be a disaster.
-Alan
On 11/23/2011 10:09 AM, Gavin Andresen wrote:
> On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker
> <decker.christian@gmail.com> wrote:
>> At some point you might find an incredibly hard block that makes your forked
>> chain the hardest one in the network
> Seems to me that's the real problem with any "hardest block found in X
> minutes" scheme.
>
> If I get lucky and find a really extremely hard block then I have an
> incentive to keep it secret and build a couple more blocks on top of
> it, then announce them all at the same time.
>
> If the rest of the network rejects my longer chain because I didn't
> announce the extremely hard block in a timely fashion... then how
> could the network ever recover from a real network split? A network
> split/rejoin will look exactly the same.
>
> Bitcoin as-is doesn't have the "I got lucky and found an extremely
> hard block" problem because the difficulty TARGET is used to compute
> chain difficulty, not the actual hashes found.
>
>
> ---
>
> PS: I proposed a different method for dealing with large hash power
> drops for the testnet on the Forums yesterday, and am testing it
> today.
>
--------------020304080106000507000405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I can substantiate Gavin's point quite powerfully: a couple months
ago I did a search for the "hardest" block in the network and found
a <b>very </b><b>impressive</b> one:<br>
<br>
<a href="https://bitcointalk.org/index.php?topic=29675.0">https://bitcointalk.org/index.php?topic=29675.0</a><br>
<br>
That block has a difficulty of <b>*36 billion</b>* when the network
had a difficulty of *<b>1.5 million</b>*, which is 24,000 times
harder than the target. If we were going by the <i>actual </i>hardest
chain instead target-based-hardest chain, <i>then this block
produced in July would might still represent the longest chain!</i>
<br>
<br>
Yes, that means that whichever miner produced this block, could've
held onto it for 2-4 months without doing anything else, and then
broadcast it to fork the blockchain from a block produced months
ago. That's not theoretical, that's real data in the blockchain and
it would be a disaster.<br>
<br>
-Alan<br>
<br>
<br>
<br>
On 11/23/2011 10:09 AM, Gavin Andresen wrote:
<blockquote
cite="mid:CABsx9T0VH5i0HrEjxfxxtzO2MtmN7UEyAUXoq9puc-1nKw3G4Q@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker
<a class="moz-txt-link-rfc2396E" href="mailto:decker.christian@gmail.com"><decker.christian@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">At some point you might find an incredibly hard block that makes your forked
chain the hardest one in the network
</pre>
</blockquote>
<pre wrap="">
Seems to me that's the real problem with any "hardest block found in X
minutes" scheme.
If I get lucky and find a really extremely hard block then I have an
incentive to keep it secret and build a couple more blocks on top of
it, then announce them all at the same time.
If the rest of the network rejects my longer chain because I didn't
announce the extremely hard block in a timely fashion... then how
could the network ever recover from a real network split? A network
split/rejoin will look exactly the same.
Bitcoin as-is doesn't have the "I got lucky and found an extremely
hard block" problem because the difficulty TARGET is used to compute
chain difficulty, not the actual hashes found.
---
PS: I proposed a different method for dealing with large hash power
drops for the testnet on the Forums yesterday, and am testing it
today.
</pre>
</blockquote>
<br>
</body>
</html>
--------------020304080106000507000405--
|
