Wie ist es möglich, eine systemweite Segmentierung zu erkennen?

In diesem Beitrag sagt MoonShadow, dass es einfach ist, eine systemweite Segmentierung zu erkennen.

Eine systemweite Segmentierung ist jedoch ziemlich einfach zu erkennen, der aktuelle Client tut dies einfach nicht. Wenn Code enthalten wäre, der meine „Watchdog“-Idee implementiert, könnte der Client so eingestellt werden, dass er den automatischen Handel auf Websites aussetzt oder den Benutzer vor einem Fehler auf interaktiven Clients warnt.

Wie wäre das technisch zu bewerkstelligen?

Insbesondere eine Reorganisation von sechs oder mehr Blöcken?
Erstaunlich das Timing dieser Frage ... ein paar Stunden, nachdem ich sie gestellt hatte, gab es einen Chain-Split mit Version 0.8 ... wie haben die Leute das erkannt?
Es wurde erwartet, dass einige Entwickler automatisierte Methoden zum Lernen hatten, aber es wurde tatsächlich zuerst von Benutzern entdeckt, die sich fragten, warum die „Sperren“ in ihren Protokollen keine Blöcke zuließen, die andere Knoten (v0.8-Clients, wie später entdeckt wurde) nicht zuließen ein Problem mit haben. Es wurde also über einen manuellen Prozess entdeckt.

Antworten (1)

Was beim Fork im März 2013 passierte, war, dass zwei verschiedene Versionen des Bitcoin-Clients sich nicht darüber einig waren, was ein gültiger Block ist. Sie könnten nach einem Block-Reorg suchen, aber das wird nur angezeigt, wenn der Fork behoben ist. Wie können Sie einen Hard Fork erkennen, sobald er passiert?

Nun, Sie könnten 5 verschiedene Versionen des Bitcoin-Clients gleichzeitig ausführen und dann herausfinden, wann sie für ein paar Minuten nicht mehr synchron sind. Dann wissen Sie, dass es einen versionsspezifischen Fork gibt. Ich sollte beachten, dass dies hauptsächlich darauf abzielt, den Kunden schneller zu reparieren, und nicht einen Händler zu schützen.

Erkennen, dass es nicht synchron ist

Sie könnten ein Programm schreiben, das alle Clients abfragt, die nach ihrem neuesten Block suchen.

Pseudocode:

run on each node
  block number = node.getblockcount()
  latest block = node.getblockbycount(block number)
  latest block hash = latest block['hash']

Oh, das erfordert übrigens den getblock-Patch .

Wenn sich diese nun länger als etwa eine Minute unterscheiden (und Sie sich noch nicht in der anfänglichen Synchronisierungsphase befinden), haben Sie möglicherweise einen Hard Fork.

Stellen Sie sicher, dass Sie eine gute Verbindung zum Netzwerk haben

Angenommen, Sie hatten einen 0.8-Client, der nur mit 0.7-Clients verbunden war. Obwohl es die Blöcke in der March-Fork akzeptiert hätte, hört es nicht einmal davon, was bedeutet, dass wir die Fork nicht erkennen werden.

Ich bin mir nicht sicher, wie ich das lösen soll. Vielleicht aufstocken MAX_OUTBOUND_CONNECTIONS?

Vermeidung von Fehlalarmen

Bei wirklich schlechten Netzwerkbedingungen ist es möglich, dass ein Client einen neuen Block erhält, die anderen jedoch nicht. Sie sollten verwenden addnode, um sie alle miteinander reden zu lassen.

Ist es möglich, einen Pool für das anstehende Tx abzufragen? Lassen die meisten Pools dies zu?