Bitcoind 0.5.3 bleibt bei Block 274.011 hängen

Question

Bitcoind 0.5.3 bleibt bei Block 274.011 hängen

Finanzen
Bitcoin
Synchronisation

Sjors Provoost

Ich habe v0.5.3 des Kernclients aus der Quelle kompiliert, um die IDB-Leistung (Initial Blockchain Download) zwischen den Versionen zu vergleichen.

Ich habe eine neue Ubuntu Xenial 16.04-Maschine auf Amazon EC2 erstellt. Ich habe dann die folgenden Befehle ausgeführt:

sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get install build-essential autoconf libboost-all-dev \
                     libssl-dev libtool pkg-config libevent-dev \
                     libdb++-dev libminiupnpc-dev

Ich habe mir dann die Quelle angesehen:

git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
git checkout v0.5.3
cd src

Um das Strict DER - Problem zu lösen , habe ich die Funktion bool Verifyin src/key.hdurch this ersetzt .

Ich kompiliere dann:

make -f makefile.unix

Um das in 0.8 eingeführte Datenbankproblem zu lösen, habe ich eine Datei ~/.bitcoin/DB_CONFIGgemäß dieser Anleitung hinzugefügt :

set_lg_dir database
set_lk_max_locks 50000

Ich starte dann Bitcoin:

./bitcoind -dbcache=8000 -daemon

Es synchronisiert sich glücklich bis zu Block 274.011, wo es mindestens einen Tag lang hängen blieb. Ich habe das nur einmal ausprobiert, daher bin ich mir nicht sicher, ob es reproduzierbar ist.

Hier ist ein Beispiel der Protokolle um diesen Punkt herum; Bei Bedarf kann ich mehr liefern:

received block 00000000000000032b4e
SetBestChain: new best=00000000000000032b4e  height=274011  work=29398500860863841218972
ProcessBlock: ACCEPTED
askfor tx 2b909ba77c89c324a669   1499456128000000
sending getdata: tx b187cf6896ac46ef99b7
sending getdata: tx ecc1cef110e97830171d
sending getdata: tx f2cf74028a74602e8197
sending getdata: tx 4ed765e52248503c18a8
sending getdata: tx cf9cd92853c50e156366
sending getdata: tx 10e5e68f221e4451df73
sending getdata: tx 585900b4e015ed2ac1ef
askfor tx 221fbf80861ce7a6d584   0
sending getdata: tx 144e4167f4bef1b7ed42
sending getdata: tx 0ff657e09ac2bec18ffe
sending getdata: tx 6fdd97713fcb14c7521f
sending getdata: tx fdf5d59441c5b8a0c60d
sending getdata: tx 28d85b339859cb995328
sending getdata: tx 4df8f62f7328bca3b940
sending getdata: tx 15bf18055f55320481e5
sending getdata: tx 9a0a74186e9787b65cfe
sending getdata: tx 221fbf80861ce7a6d584
askfor tx e92fff32bc853b9aaa74   0
askfor tx 894d1cbfb82b61160bec   1499455908000000
askfor tx 48f22fcab4174c22ca0b   1499455909000000
askfor tx db4145ed6b4d366e429e   0
askfor tx 221fbf80861ce7a6d584   1499455912000000
askfor tx eb604d6581ab29aac596   0
sending getdata: tx aba92ed0b3ad91cff821
sending getdata: tx d0175f40dc118a5c8aef
sending getdata: tx 8dcc57d538a3391a40a6
sending getdata: tx 699d9a01db321519373c
sending getdata: tx 6dec27e77519e9968909
sending getdata: tx aab87f6f03f9e9a13c8c
sending getdata: tx d415b3535065b0f7f45a
sending getdata: tx 389e7c4af3b8c6eb7a23
sending getdata: tx 224f97a4e9dc09976302
sending getdata: tx da54c3bd141b537e2a32
sending getdata: tx 5c7b7bae2d3fccdc61e9
sending getdata: tx e92fff32bc853b9aaa74
...
ERROR: nonstandard txout: OP_HASH160 432a41db83cc1f7e5cc9c48a0808b00ff2992a3a OP_EQUAL
ERROR: AcceptToMemoryPool() : nonstandard transaction type
ERROR: ConnectInputs() : cf9cd92853 mapTransactions prev not found 4c77e274a8
ERROR: AcceptToMemoryPool() : ConnectInputs failed cf9cd92853
ERROR: ConnectInputs() : 10e5e68f22 mapTransactions prev not found d5d9ba282e
ERROR: AcceptToMemoryPool() : ConnectInputs failed 10e5e68f22
ERROR: ConnectInputs() : aba92ed0b3 mapTransactions prev not found b5646cc672
ERROR: AcceptToMemoryPool() : ConnectInputs failed aba92ed0b3
ERROR: nonstandard txin: 0 3044022075066e21b2d705e77bfed0d4fbdd235c8993b91cae47daeac7438881e35e83dd022059b4e62df6e4dafc1ccf01b7f8dedf82be3c5fc1e804e0885a885274905fc65801 3044022024c5b0cfdf748245a4ad8654710412ae5430b052ebb693e941131786a3fd369b02203f53c18e76676f3280e5b3198466f9348d26769166e43de27f997da4dac9299401 52210204f0cf6188b88806fa626dec13a8969d7d157fbe8963d08cf7046e07ef4900d02102a3d1066654c906f66f4778ef70aa3b97ee31518325a97b2bb571e2fc57c6fb6e52ae
ERROR: AcceptToMemoryPool() : nonstandard transaction type
ERROR: ConnectInputs() : 8dcc57d538 mapTransactions prev not found f055f633bf
...
askfor block 000000000000000000d1   0
askfor tx cb7c501051cb8a14797d   0
sending getdata: block 000000000000000000d1
sending getdata: tx cb7c501051cb8a14797d
received block 000000000000000000d1
ProcessBlock: ORPHAN BLOCK, prev=0000000000000000008f
ERROR: ConnectInputs() : cb7c501051 mapTransactions prev not found b1fd3405d1
ERROR: AcceptToMemoryPool() : ConnectInputs failed cb7c501051
sending getdata: tx eff6ce1819d75352b6a4
...

Pieter Wuille

Können Sie es noch einmal versuchen, vielleicht mit einem noch größeren Sperrlimit?

Pieter Wuille

Die hier vorgeschlagene Zahl ist viel größer: bitcoin.org/en/alert/2013-03-15-upgrade-deadline

Sjors Provoost

Das hat funktioniert!

Sjors Provoost

In ähnlicher Weise blieb 0,6 bei 299.927 und 0,7 bei 319.884 hängen. Beide wurden wieder aufgenommen, sobald ich diese Einstellung angestoßen hatte. Ich frage mich, warum sie nicht alle genau am selben Block anhalten. Ich habe diese Knoten neu gestartet; Basierend auf der Leistung modernerer Versionen sollte die Synchronisierung mindestens eine Woche dauern, vielleicht sogar zwei Wochen.

Pieter Wuille

Beachten Sie, dass der vor 0.10 verwendete Synchronisierungsmechanismus (der Header-First-Sync hinzufügte) dazu neigte, zufällig zu stoppen und Blöcke mehrmals herunterzuladen (insbesondere 0.9 war schlecht). Sie können die meisten dieser Probleme vermeiden, indem Sie -connect=IP zu einem bekanntermaßen guten Peer verwenden.

Sjors Provoost

Ich habe meine IP connectauf der Whitelist meines eigenen v0.14.2Knotens eingestellt. 0.14Log sagt

2017-09-05 18:04:12 receive version message: : version 50300, blocks=273076, us=X.X.X.X:8333, peer=15, peeraddr=35.158.4.220:54134

immer und immer wieder. Das v0.5Protokoll sagt

trying connection X.X.XX:8333 lastseen=-390175.9hrs lasttry=-417953.7hrs connected X.X.XX:8333 Added time data, samples 2, offset +0 (+0 minutes) version message: version 70015, blocks=483687 accepted alert 2147483647, AppliesToMe()=1 getheaders 221534 to 00000000000000000000 limit 264153 socket recv error 104 disconnecting node X.X.XX:8333

Sjors Provoost

Wie auch immer, das Anhalten und Neustarten des 0.5-Knotens scheint auszureichen, um ihn in Bewegung zu halten. Diesmal versuche ich nur, es mit dem 1.1.2014 zu synchronisieren. Es lief ziemlich gut, bis ungefähr im letzten Monat, wo es nur Stunden am Stück aufhörte. Es gibt auch peers.datnoch keine Datei, ist das richtig?

Sjors Provoost

Korrektur, es lief v0.14.1, nicht v0.14.2.

G. Maxwell

"Warum halten sie nicht alle am selben Block an?" denn vor 0.8 war das Konsensverhalten effektiv nicht deterministisch – es hängt davon ab, wie Datensätze in der Datenbank in Seiten ausgerichtet wurden.

Sjors Provoost

@PieterWuille Ich habe tatsächlich verwendet connect=, aber es verbindet sich immer noch gerne mit anderen Peers (wie addnode=es tun würde). Hat sich die Semantik geändert?

Antworten (1)

Bitcoind 0.5.3 bleibt bei Block 274.011 hängen

Können Sie es noch einmal versuchen, vielleicht mit einem noch größeren Sperrlimit?
Die hier vorgeschlagene Zahl ist viel größer: bitcoin.org/en/alert/2013-03-15-upgrade-deadline
In ähnlicher Weise blieb 0,6 bei 299.927 und 0,7 bei 319.884 hängen. Beide wurden wieder aufgenommen, sobald ich diese Einstellung angestoßen hatte. Ich frage mich, warum sie nicht alle genau am selben Block anhalten. Ich habe diese Knoten neu gestartet; Basierend auf der Leistung modernerer Versionen sollte die Synchronisierung mindestens eine Woche dauern, vielleicht sogar zwei Wochen.
Beachten Sie, dass der vor 0.10 verwendete Synchronisierungsmechanismus (der Header-First-Sync hinzufügte) dazu neigte, zufällig zu stoppen und Blöcke mehrmals herunterzuladen (insbesondere 0.9 war schlecht). Sie können die meisten dieser Probleme vermeiden, indem Sie -connect=IP zu einem bekanntermaßen guten Peer verwenden.
Ich habe meine IP connectauf der Whitelist meines eigenen v0.14.2Knotens eingestellt. 0.14Log sagt 2017-09-05 18:04:12 receive version message: : version 50300, blocks=273076, us=X.X.X.X:8333, peer=15, peeraddr=35.158.4.220:54134immer und immer wieder. Das v0.5Protokoll sagttrying connection X.X.XX:8333 lastseen=-390175.9hrs lasttry=-417953.7hrs connected X.X.XX:8333 Added time data, samples 2, offset +0 (+0 minutes) version message: version 70015, blocks=483687 accepted alert 2147483647, AppliesToMe()=1 getheaders 221534 to 00000000000000000000 limit 264153 socket recv error 104 disconnecting node X.X.XX:8333
Wie auch immer, das Anhalten und Neustarten des 0.5-Knotens scheint auszureichen, um ihn in Bewegung zu halten. Diesmal versuche ich nur, es mit dem 1.1.2014 zu synchronisieren. Es lief ziemlich gut, bis ungefähr im letzten Monat, wo es nur Stunden am Stück aufhörte. Es gibt auch peers.datnoch keine Datei, ist das richtig?
"Warum halten sie nicht alle am selben Block an?" denn vor 0.8 war das Konsensverhalten effektiv nicht deterministisch – es hängt davon ab, wie Datensätze in der Datenbank in Seiten ausgerichtet wurden.
@PieterWuille Ich habe tatsächlich verwendet connect=, aber es verbindet sich immer noch gerne mit anderen Peers (wie addnode=es tun würde). Hat sich die Semantik geändert?

Sjors Provoost · Answer 1

Erhöhen Sie gemäß dieser Anleitungset_lk_max_locks von 50000bis . Danke Pieter Wuille für den Hinweis.537000

Follow-up: Bei einem neueren Versuch hat mich die obige Änderung dazu gebracht, 364670 zu blockieren, und das Anstoßen set_lk_max_locksscheint nicht mehr zu helfen.

Bitcoind 0.5.3 bleibt bei Block 274.011 hängen

Sjors Provoost

Pieter Wuille

Pieter Wuille

Sjors Provoost

Sjors Provoost

Pieter Wuille

Sjors Provoost

Sjors Provoost

Sjors Provoost

G. Maxwell

Sjors Provoost

Antworten (1)

Sjors Provoost

Sjors Provoost

Status des Dämons prüfen?

Feinabstimmung eines Rapsberri Pi 2 B+ voller 0,12-Knoten

Woher weiß ich, ob Bitcoin synchronisiert ist?

Gibt es irgendwo gebrauchsfertige indizierte Bitcoin-Datendateien?

Warum ist die Synchronisierung der letzten 5000 Blöcke so viel CPU-intensiver?

Was bedeutet UpdateTipp?

bitcoin rückwärts synchronisieren

Importieren aller blkXXXXXX.dat

Bitcoin-Synchronisierungszeit unglaublich langsam

Wie kann man Bitcoins von einer beschädigten Festplatte retten?