Ist es möglich, dass ein gültiger Block zu einem ungültigen hinzugefügt wird und von einem anderen Client akzeptiert wird?

Diese Wiki-Seite besagt, dass ungültige Blöcke nicht zur Bestimmung der Kettenlänge gezählt werden und dass ich verstehen möchte, wie ungültige Blöcke behandelt werden.

  • Kann ein gültiger Block zu einem ungültigen hinzugefügt werden und von einem oder mehreren Clients akzeptiert werden?

Wenn ja...

  • Erhalten Miner von ungültigen Blöcken eine Belohnung für den Block? Sind die Tx gültig? Gibt es Beispiele?

Angenommen, ein ungültiger Block wird erstellt und ein gültiger Block wird zu diesem ungültigen Block hinzugefügt. Beide Blöcke werden der Primärkette hinzugefügt. (Angenommen, der Angreifer hat 25 % Rechenleistung und einen benutzerdefinierten Client, der beide Transaktionen an alle Peers weiterleitet)

  • Da jeder Block eine Belohnung hat, wird die Belohnung im ungültigen Block gezählt?

  • Werden die Transaktionen innerhalb eines ungültigen Blocks noch als gültig betrachtet?

Ich bin daran interessiert, die Transaktionen zu verfolgen, die von diesen "kaputten" Blöcken ausgehen, und zu sehen, ob mein handcodierter Client die Transaktionen korrekt verarbeitet.

Per Definition ist ein Block nur dann gültig, wenn er zu einem gültigen Block hinzugefügt wird. Daher ist es unmöglich, eine gültige zu einer ungültigen hinzuzufügen. Tut mir leid, ich kann da nicht einfach mitgehen...
@HighlyIrregular Ich habe das Szenario mit Details aktualisiert. Laut Wiki akzeptieren Clients ungültige Blöcke, leiten sie aber nicht weiter. Wenn ein Angreifer beide Blöcke herstellt und weiterleitet ... was passiert? Dafür werden weniger als 51 % der CPU benötigt.
@makerofthings7 Clients akzeptieren keine ungültigen Blöcke.
Fürs Protokoll, ich denke immer noch, dass dies eine gute Frage ist, auch wenn die zugrunde liegenden Annahmen falsch sind, also habe ich sie positiv bewertet. Eine bessere Frage könnte jedoch lauten: "Ist es möglich, dass ein gültiger Block zu einem ungültigen hinzugefügt und von einem anderen Client akzeptiert wird?"
@HighlyIrregular Revised ... Da war ich mir selbst voraus.

Antworten (2)

Da jeder Kunde jeden empfangenen Block überprüft und jeden ungültigen Block ablehnt, ist es eher unwahrscheinlich, dass diese Situation eintritt. Wenn sich jedoch zufällig ein ungültiger Block ausbreiten würde (z. B. im Falle eines Wertüberlauffehlers oder vielleicht durch die Verbreitung durch einige alternative Clients, die das Protokoll nicht genau befolgen), würde er schließlich aus dem Block gelöscht werden Geschichte und verwaiste alle Blöcke, die ihm zugeordnet sind. Alternativ könnte das Protokoll geändert werden, um den Block aufzunehmen, aber das ist viel unwahrscheinlicher.

Wenn ein Teil der Blockchain ungültig würde, würden alle darin enthaltenen Transaktionen neu bewertet – Transaktionen zur Münzgenerierung würden verworfen, alle Transaktionen, die ihre Ausgaben ausgeben, würden ebenfalls ungültig gemacht und alle anderen Transaktionen, die noch gültig sind, würden hinzugefügt zurück zum Pool von Transaktionen, die zu zukünftigen Blöcken hinzugefügt werden. Dasselbe würde passieren, wenn einige Blöcke mit einer längeren Kette von Blöcken überschrieben werden.

Alles in allem wird ein ungültiger Block als gültig akzeptiert und es werden gültige Blöcke an die Kette angehängt, nachdem es sich um einen Fehler handelt. Solche Fälle sind in der Vergangenheit mindestens einmal vorgekommen, und das Ergebnis war, den Fehler zu beheben und den ungültigen Block zusammen mit allen anderen daran angehängten Blöcken zu löschen. Alle normalen Transaktionen aus diesen Blöcken müssten erneut zu neu erstellten Blöcken hinzugefügt werden, und alle Transaktionen zur Münzgenerierung würden ungültig.

Beim Bitcoin.org-Client akzeptiert der Knoten einen Block erst, wenn keiner der Überprüfungsschritte fehlschlägt.

Jeder Block in der Block* -Kette * ist mit einem vorherigen Block mit einem Verweis auf den Hash dieses vorherigen Blocks verknüpft.

Nehmen Sie also den Fall, in dem ein Knoten die längste Kette sieht, die auf Höhe 1.000 endet. Dann empfängt es einen Block 1.001. Der Client überprüft dann, ob der Hash, den der Block für Block 1.000 liefert, wirklich mit dem Hash übereinstimmt, den der Client bereits kennt (aus der längsten Kette) für Block 1.000. Es wird nicht übereinstimmen, also erstreckt sich diese 1.001 nicht über den Block 1.000 hinaus, den der Client bereits kennt.

Und da der Client keinen anderen Block 1.000 mit diesem Hash kennt, von dem sich 1.0001 angeblich erstreckt, akzeptiert der Client Block 1.001 nicht – es gibt keinen Link, der ihn mit zuvor empfangenen Blöcken verbindet.