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.
Deinen Node prüfen
Führe btx-cli getblockchaininfo auf deinem Node aus und füge die ganze Antwort unten ein. Als diese Seite gebaut wurde, stand das Netz bei Block 270.224.
Nur in deinem Browser geprüft: Nichts wird gesendet oder gespeichert.
Einen eigenen Node einrichten
Jeder zusätzliche Node macht BTX stärker. So lässt sich einer einrichten:
BTX releases ↗: Die offiziellen Releases und die Dokumentation der BTX-Entwickler.
easynode ↗: Ein quelloffenes Community-Setup des easyBTX-Teams; laut seinen Autoren läuft es auch ohne GPU.
Hängende Peers, die unsere Archive gerade sehen
Gezählt pro Verbindung unserer zwei Archive-Nodes, kein Node wird genannt. Höhen, die weniger als zwei Verbindungen teilen, sind zusammengefasst.
Nodes ohne GPU im Consensus-Modus: Sie können den nächsten MatMul-Block nicht prüfen. So beheben ↓
andere Höhen
24
–
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.
Änderungen an btx.conf wirken erst nach einem sauberen Neustart: btx-cli stop, warten bis btxd beendet ist, dann wieder starten.
Kein tor installiert? listenonion=0 eintragen. Kein python3? autoupdate=0 eintragen.
Das Modellnetz wird nicht genutzt? modelnet=0 eintragen: Unter v0.34.15 lauscht sein Hilfsprogramm auf Port 29447 an allen Schnittstellen.
Ein Onion-Dienst läuft? Prüfen, ob die .onion-Adresse noch unter localaddresses in btx-cli getnetworkinfo steht; falls nicht, btxd neu starten.
Auf v0.34.15 und dem v0.35-Kandidaten nie -reindex ausführen: Ein Neuaufbau ab Genesis bleibt bei Block 126.978 stehen, bis die Korrektur (PR #272) veröffentlicht ist.