Hängt dein Node?
Prüfe hier deinen eigenen Node, sieh die bekannten Gründe, warum ein BTX-Node hängen bleibt, und wie er wieder läuft. Diese Seite zeigt nie fremde Nodes oder Adressen.
Bekannte Gründe und Lösungen
Hängt bei Block 126.978
Ein Neuaufbau ab Genesis (zum Beispiel nach -reindex) bleibt wegen der Unshield-Velocity-Grenze bei diesem Block stehen. Das betrifft v0.34.15 und auch den aktuellen v0.35-Kandidaten, weil die Korrektur (PR
- Den Node sauber stoppen (btx-cli stop, dann warten, bis er beendet ist). Nie gewaltsam beenden.
- Kein -reindex mehr ausführen, bis ein Release die Korrektur enthält.
- Mit dem neuesten signierten Datadir-Snapshot neu starten (siehe unten); der Node holt dann nur noch den letzten Tag nach.
Hängt bei Block 184.999 oder 228.000
Ein Node im Consensus-Modus ohne geeignete GPU kann den nächsten MatMul-Block nicht prüfen. Bei 184.999 ist das Block 185.000, bei 228.000 (Checkpoint und Schnellstart-Snapshot seit v0.34.12) Block 228.001. Der Node versucht es etwa alle 60 Sekunden, endlos.
- Prüfen: Das Feld "warnings" von btx-cli getblockchaininfo meldet, dass der nächste MatMul-Block nicht geprüft werden kann.
- Entweder eine geeignete GPU nutzen oder als Trusted Mirror betreiben: matmulvalidation=trusted mit mindestens zwei festgelegten Signierern und Schwellwert 2, wie in doc/btx-matmul-trusted-rpc-mirrors.md in github.com/btxchain/btx beschrieben.
- Falle: Festgelegte Signierer wirken nicht, solange der Node im Consensus-Modus bleibt. Der Modus muss trusted sein.
- Nur die Signierer festlegen, die heute aktiv sind (siehe die Signierer auf unserer Statusseite, aus dem btxscan-Witness). Ein festgelegter Signierer, der nicht mehr signiert, lässt einen Mirror einfrieren.
- Danach sauber neu starten; der Node macht dort weiter, wo er stehen geblieben ist.
Hängt bei Block 185.109
Alte Clients (v0.32, frühe v0.33) kennen den Wechsel bei Block 185.000 nicht und folgen einem alten Zweig, der hier endet.
- Auf das aktuelle Release v0.34.15 aktualisieren.
- Danach mit dem neuesten signierten Datadir-Snapshot starten (siehe unten).
Weit zurück und keine Bewegung
Der Node bekommt keine neuen Blöcke. Häufige Gründe sind ein alter Client, zu wenige synchrone Peers oder ein Block, den er ablehnt.
- Die Version prüfen (btx-cli getnetworkinfo, "subversion") und auf v0.34.15 aktualisieren, falls sie älter ist.
- Mit v0.32.11 bleibt ein Node um Block 140.000 stehen: Seine Unshield-Velocity-Grenze endet nie (v0.34.15 beendet sie bei Block 135.000), deshalb lehnt er spätere Blöcke ab. Ein Update behebt das.
- Die Peers prüfen (btx-cli getpeerinfo); viele weit zurückliegende Peers bremsen den Sync.
- Den Hash deines neuesten Blocks (btx-cli getblockhash <Höhe>) mit einem Explorer auf derselben Höhe vergleichen. Weicht er ab, in der Community fragen, bevor du etwas änderst.
- Der schnellste Ausweg ist oft der neueste signierte Datadir-Snapshot (siehe unten).
Neu starten mit einem Snapshot
Statt ab Genesis zu synchronisieren, starte mit unserem täglichen Datadir-Snapshot: in einem Offline-Node geprüft, von einem zweiten Archiv-Node erneut geprüft und signiert. Zuerst die Wallets sichern, bevor du irgendetwas änderst. Node sauber stoppen, den Snapshot in ein leeres Datadir entpacken, dann btx.conf und die Wallets zurückkopieren. Ein übrig gebliebener Ordner chainstate_snapshot/ hält den Node beim Start an. prune= genauso setzen wie bei der Quelle des Snapshots (prune=20000), dann neu starten. Nicht für Signierer: Sie spielen die Historie selbst nach.
Neuester signierter Snapshot (Block 269.684) ↗