📅 Original date posted:2013-03-11
📝 Original message:Hello again,
block 000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023
(height=225430) 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.
--
Pieter
On Tue, Mar 12, 2013 at 1:18 AM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> Hello everyone,
>
> Í'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=000000000000015aab28064a4c521d6a5325ff6e251e8ca2edfdfe6cb5bf832c
> height=225439 work=853779625563004076992 tx=14269257 date=2013-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130312/9a987241/attachment.html>;
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 11:36:37
in reply to nevent1q…smvd
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 11:36:37Event JSON
{
"id": "b6f677c084262b1c45433bf3493514f0f4e8a9712d9c0ace22c269e8343d75a2",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686137797,
"kind": 1,
"tags": [
[
"e",
"bf6db92ac74ed2040908c22a007eaccc4dacca3e534709bcb8876ea849933631",
"",
"root"
],
[
"e",
"3d75f19cf94f17bcae24a25a0dbbdfe22a1ea65e125a005bc8ba30e209c4f046",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2013-03-11\n📝 Original message:Hello again,\n\nblock 000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023\n(height=225430) seems indeed to have cause pre-0.8 and 0.8 nodes to fork\n(at least mostly). Both chains are being mined on - the 0.8 one growing\nfaster.\n\nAfter some emergency discussion on #bitcoin-dev, it seems best to try to\nget the majority mining power back on the \"old\" chain, that is, the one\nwhich 0.7 accepts\n(with 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 at\nheight 225430). That is the only chain every client out there will accept.\nBTC Guild is switching to 0.7, so majority should abandon the 0.8 chain\nsoon.\n\nShort advice: if you're a miner, please revert to 0.7 until we at least\nunderstand exactly what causes this. If you're a merchant, and are on 0.8,\nstop processing transactions until both sides have switched to the same\nchain again. We'll see how to proceed afterwards.\n\n-- \nPieter\n\n\n\nOn Tue, Mar 12, 2013 at 1:18 AM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003ewrote:\n\n\u003e Hello everyone,\n\u003e\n\u003e Í've just seen many reports of 0.7 nodes getting stuck around block\n\u003e 225430, due to running out of lock entries in the BDB database. 0.8 nodes\n\u003e do not seem to have a problem.\n\u003e\n\u003e In any case, if you do not have this block:\n\u003e\n\u003e 2013-03-12 00:00:10 SetBestChain: new\n\u003e best=000000000000015aab28064a4c521d6a5325ff6e251e8ca2edfdfe6cb5bf832c\n\u003e height=225439 work=853779625563004076992 tx=14269257 date=2013-03-11\n\u003e 23:49:08\n\u003e\n\u003e you're likely stuck. Check debug.log and db.log (look for 'Lock table is\n\u003e out of available lock entries').\n\u003e\n\u003e If this is a widespread problem, it is an emergency. We risk having\n\u003e (several) forked chains with smaller blocks, which are accepted by 0.7\n\u003e nodes. Can people contact pool operators to see which fork they are on?\n\u003e Blockexplorer and blockchain.info seem to be stuck as well.\n\u003e\n\u003e Immediate solution is upgrading to 0.8, or manually setting the number of\n\u003e lock objects higher in your database. I'll follow up with more concrete\n\u003e instructions.\n\u003e\n\u003e If you're unsure, please stop processing transactions.\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130312/9a987241/attachment.html\u003e",
"sig": "008a710389f045e30cf5e4807ca0d8ff5bb94b20bbda83b078c21bfbbbe5eb68a07129a086c6b439ce649893b41fd8662984ff4ace79e081793208befe72fb6b"
}