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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>)
id 1UFDb4-0006x1-Gq; Tue, 12 Mar 2013 01:01:42 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.170 as permitted sender)
client-ip=209.85.223.170; envelope-from=pieter.wuille@gmail.com;
helo=mail-ie0-f170.google.com;
Received: from mail-ie0-f170.google.com ([209.85.223.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UFDb2-0001dw-Ui; Tue, 12 Mar 2013 01:01:42 +0000
Received: by mail-ie0-f170.google.com with SMTP id c11so5758530ieb.29
for <multiple recipients>; Mon, 11 Mar 2013 18:01:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.180.197 with SMTP id dq5mr9573690igc.22.1363050095310;
Mon, 11 Mar 2013 18:01:35 -0700 (PDT)
Received: by 10.50.171.8 with HTTP; Mon, 11 Mar 2013 18:01:35 -0700 (PDT)
In-Reply-To: <CAPg+sBip_4Jtxhq+rm-na2=RSJ_PuoZt+akGgJyo0b_Bwbr1Dw@mail.gmail.com>
References: <CAPg+sBip_4Jtxhq+rm-na2=RSJ_PuoZt+akGgJyo0b_Bwbr1Dw@mail.gmail.com>
Date: Tue, 12 Mar 2013 02:01:35 +0100
Message-ID: <CAPg+sBjm+e=A+edSRHXU7JSqyfSc4hou_SRdQHF48xhKQGA4zA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
bitcoin-security@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=14dae9340b73be3fe604d7afd45e
X-Spam-Score: -0.6 (/)
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
(pieter.wuille[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
X-Headers-End: 1UFDb2-0001dw-Ui
Subject: Re: [Bitcoin-development] Warning: many 0.7 nodes break on large
number of tx/block; fork risk
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, 12 Mar 2013 01:01:42 -0000
--14dae9340b73be3fe604d7afd45e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello again,
block 000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023
(height=3D225430) seems indeed to have cause pre-0.8 and 0.8 nodes to fork
(at least mostly). Both chains are being mined on - the 0.8 one growing
faster.
After some emergency discussion on #bitcoin-dev, it seems best to try to
get the majority mining power back on the "old" chain, that is, the one
which 0.7 accepts
(with 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 at
height 225430). That is the only chain every client out there will accept.
BTC Guild is switching to 0.7, so majority should abandon the 0.8 chain
soon.
Short advice: if you're a miner, please revert to 0.7 until we at least
understand exactly what causes this. If you're a merchant, and are on 0.8,
stop processing transactions until both sides have switched to the same
chain again. We'll see how to proceed afterwards.
--=20
Pieter
On Tue, Mar 12, 2013 at 1:18 AM, Pieter Wuille <pieter.wuille@gmail.com>wro=
te:
> Hello everyone,
>
> =CD've just seen many reports of 0.7 nodes getting stuck around block
> 225430, due to running out of lock entries in the BDB database. 0.8 nodes
> do not seem to have a problem.
>
> In any case, if you do not have this block:
>
> 2013-03-12 00:00:10 SetBestChain: new
> best=3D000000000000015aab28064a4c521d6a5325ff6e251e8ca2edfdfe6cb5bf832c
> height=3D225439 work=3D853779625563004076992 tx=3D14269257 date=3D201=
3-03-11
> 23:49:08
>
> you're likely stuck. Check debug.log and db.log (look for 'Lock table is
> out of available lock entries').
>
> If this is a widespread problem, it is an emergency. We risk having
> (several) forked chains with smaller blocks, which are accepted by 0.7
> nodes. Can people contact pool operators to see which fork they are on?
> Blockexplorer and blockchain.info seem to be stuck as well.
>
> Immediate solution is upgrading to 0.8, or manually setting the number of
> lock objects higher in your database. I'll follow up with more concrete
> instructions.
>
> If you're unsure, please stop processing transactions.
>
> --
> Pieter
>
--14dae9340b73be3fe604d7afd45e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello again,<div><br></div><div style>block=A0000000000000=
015c50b165fcdd33556f8b44800c5298943ac70b112df480c023 (height=3D225430) seem=
s indeed to have cause pre-0.8 and 0.8 nodes to fork (at least mostly). Bot=
h chains are being mined on - the 0.8 one growing faster.</div>
<div style><br></div><div>After some emergency discussion on #bitcoin-dev, =
it seems best to try to get the majority mining power back on the "old=
" chain, that is, the one which 0.7 accepts (with=A000000000000001c108=
384350f74090433e7fcf79a606b8e797f065b130575932 at height 225430). That is t=
he only chain every client out there will accept. BTC Guild is switching to=
0.7, so majority should abandon the 0.8 chain soon.</div>
<div><br></div><div style>Short advice: if you're a miner, please rever=
t to 0.7 until we at least understand exactly what causes this. If you'=
re a merchant, and are on 0.8, stop processing transactions until both side=
s have switched to the same chain again. We'll see how to proceed after=
wards.</div>
<div style><br></div><div style>--=A0</div><div style>Pieter</div><div styl=
e><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_qu=
ote">On Tue, Mar 12, 2013 at 1:18 AM, Pieter Wuille <span dir=3D"ltr"><<=
a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@g=
mail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello everyone,<div><br></d=
iv><div>=CD've just seen many reports of 0.7 nodes getting stuck around=
block 225430, due to running out of lock entries in the BDB database. 0.8 =
nodes do not seem to have a problem.</div>
<div><br></div><div>In any case, if you do not have this block:</div><div><=
br></div><div><div>=A0 2013-03-12 00:00:10 SetBestChain: new best=3D0000000=
00000015aab28064a4c521d6a5325ff6e251e8ca2edfdfe6cb5bf832c =A0height=3D22543=
9 =A0work=3D853779625563004076992 =A0tx=3D14269257 =A0date=3D2013-03-11 23:=
49:08</div>
<div><br></div><div>you're likely stuck. Check debug.log and db.log (lo=
ok for 'Lock table is out of available lock entries').</div><div><b=
r></div><div>If this is a widespread problem, it is an emergency. We risk h=
aving (several) forked chains with smaller blocks, which are accepted by 0.=
7 nodes. Can people contact pool operators to see which fork they are on? B=
lockexplorer and <a href=3D"http://blockchain.info" target=3D"_blank">block=
chain.info</a> seem to be stuck as well.</div>
<div><br></div><div>Immediate solution is upgrading to 0.8, or manually set=
ting the number of lock objects higher in your database. I'll follow up=
with more concrete instructions.</div><div><br></div>
<div>If you're unsure, please stop processing transactions.</div><span =
class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>--=A0</div><di=
v>Pieter</div></font></span></div></div>
</blockquote></div><br></div>
--14dae9340b73be3fe604d7afd45e--
|
