Gültiger Fork im Regtest - Blockchain über RPC ändern?

Ich habe ein Regtest-Netzwerk erstellt, das aus 2 Knoten besteht - Knoten0 und Knoten1.
Ich hätte gerne einen Fork auf der gemeinsamen Blockchain und habe es scheinbar so erreicht:

  1. Knoten beginnen
  2. node0 fügt node1 via hinzuaddnode
  3. node0 generiert 1 Block mit Hash 4dac ...
  4. node1 generiert 1 Block mit Hash 5d8b...
  5. node0 macht den Block von node0 mit dem Hash 5d8b... via ungültiginvalidate <hash>
  6. Knoten1 stoppt
  7. node0 generiert 1 Block mit Hash 64f2...
  8. node1 startet neu
  9. node1 generiert 1 Block mit Hash 5sfg ...
  10. node0: getchaintipsgibt ein Array mit dem Hash 5d8b des ungültig gemachten Blocks zurück ... mit Status

Nun meine Fragen:
a) Wie kann ich einen " valid-fork" Status in der Ausgabe von getchaintips für den zuvor invalidierten Fork erreichen? [GELÖST]

b) Ist es möglich, dass ein Knoten „bewusst“/per RPC seine eigene Kette aufgibt und auf die konkurrierende Kette umschaltet?

@JonasSchnelli: Ja, ich habe mir diesen Code angesehen, aber nicht viel verstanden, da ich mit Python nicht vertraut bin beschreibt Zweige unterschiedlicher Länge. Ist das der springende Punkt?

Antworten (3)

Es wird immer automatisch die längste gültige Kette gewählt. Daher ist der Weg, um es zwangsweise umzuschalten, die Verwendung des invalidateblockversteckten RPC.

Ich habe den Bitcoin-Entwicklerleitfaden erneut gelesen und den Abschnitt help getchaintips erneut gelesen:

Jeder vollständige Knoten im Bitcoin-Netzwerk speichert unabhängig eine Blockkette, die nur Blöcke enthält, die von diesem Knoten validiert wurden . Wenn mehrere Nodes alle dieselben Blöcke in ihrer Blockchain haben, gelten sie als im Konsens. Die Validierungsregeln, denen diese Knoten folgen, um den Konsens aufrechtzuerhalten, werden als Konsensregeln bezeichnet.

und

Mögliche Werte für status:
[..]
"valid-fork": Dieser Zweig ist nicht Teil der aktiven Kette, aber vollständig validiert
[..]

Für a) Um also einen Valid-Fork-Status für einen zuvor ungültig gemachten Block-Hash zu erreichen, muss node0 genau diesen Block-Hash überdenken, um ihn auf seiner Kopie der Blockchain vollständig validieren zu lassen. Dies kann erreicht werden durch reconsiderblock <block hash>.

Hinweis: reconsiderblock Anscheinend "schließt" die Verzweigung, da getchaintips für beide Knoten der gleiche Block-Hash für die aktive Kettenspitze zurückgegeben wird.

Zu b) Noch nichts herausgefunden.

Für b: invalidateblock RPC markiert einen Block als unbedingt ungültig. Der reconsiderblock-RPC löscht diesen ungültigen Zustand.

In Bezug auf a) bin ich nicht wirklich vertraut, wie es den Block validiert, aber meine Vermutung ist nein.

wie bei b) ist es möglich die eigene Kette aufzugeben, die andere Kette ist die längste gültige Kette.

Blöcke in kürzeren Ketten (oder ungültigen Ketten) werden für nichts verwendet. Wenn der Bitcoin-Client zu einer anderen, längeren Kette wechselt, werden alle gültigen Transaktionen der Blöcke innerhalb der kürzeren Kette erneut zum Pool der Transaktionen in der Warteschlange hinzugefügt und in einen anderen Block aufgenommen. Die Belohnung für die Blöcke auf der kürzeren Kette wird in der längsten Kette nicht vorhanden sein, so dass sie praktisch verloren gehen, weshalb eine netzwerkerzwungene 100-Block-Reifezeit für Generationen existiert.

Zu b) Sie zitieren "Wenn der Bitcoin-Client zu einer anderen, längeren Kette wechselt, alle [...]" - Aber meine Frage ist , wie man bewusst, zB gemäß einem RPC, die Kette wechseln kann!?
Die längste Kette wird immer von der Wallet-Software ausgewählt, es gibt keine RPC-Option, um einen Kettenwechsel zu erzwingen.
Gültiger Fork im Regtest - Blockchain über RPC ändern?
AntwortenHierDatenschutz-Bestimmungen1y, 0v