Zeichnet der Bitcoin-Client keine Original-Signaturdaten pro Verbindung auf?

Ich habe gerade die Formbarkeitsseite gelesen .

Kann das jemand bestätigen

Während Transaktionen signiert werden, deckt die Signatur derzeit nicht alle Daten in einer Transaktion ab, die gehasht wird, um den Transaktions-Hash zu erstellen. Obwohl es ungewöhnlich ist, ist es für einen Knoten im Netzwerk möglich, eine von Ihnen gesendete Transaktion so zu ändern, dass der Hash ungültig wird.

bedeutet, dass das Protokoll den Adressen in der Datenbank eigentlich keine Signaturdaten zuordnet?

Bitte sag mir, dass das nicht stimmt.

Ich verstehe nicht, "das Protokoll ordnet Adressen in der Datenbank eigentlich keine Signaturdaten zu". Welche Signaturdaten? Welche Datenbank?
Ich verstehe Bitcoin gut, aber die Frage ist immer noch chaotisch, weil es keine klare Bedeutung für "das Protokoll weist Adressen in der Datenbank tatsächlich keine Signaturdaten zu" gibt. Das Protokoll verwaltet keine Datenbank. „Signaturdaten“ werden nicht durch das Protokoll oder die Software „Adressen“ „zugewiesen“, Signaturen werden an Transaktionen angehängt. In Bezug auf Ihren zusätzlichen Kommentar gibt es keine „schlechten Daten“, die gelöscht werden müssen – die mutierten Transaktionen sind immer noch gültig, und wenn sie ihren Weg in die Blockchain finden, leben sie für immer als gültige Transaktionen. Sie verwirren nur einige andere Software.

Antworten (1)

Die Signatur umfasst alles außer der Signatur selbst. Da die Signatur und der öffentliche Schlüssel das Eingabeskript für die gängigste Zahlungsart (Pay-to-Pubkey-Hash) bilden, ist das Eingabeskript nicht Teil der signierten Daten. Dies bedeutet, dass das Eingabeskript geändert werden kann und die signierte Transaktion nicht beschädigt wird, solange das neue Eingabeskript dem ursprünglichen Eingabeskript entspricht. Der jüngste Angriff tat dies, indem er einen der Skript-Opcodes in einen äquivalenten Opcode änderte. Das neue Skript war also gültig und führte die gleiche Funktion aus. Aber da der Opcode geändert wurde, war der Transaktions-Hash anders.

Sobald eine Transaktion Teil eines Blocks ist, kann der Transaktions-Hash nicht mehr geändert werden, da er jetzt im Merkle-Baum für den Block enthalten ist. Das Angriffsfenster besteht also nur ab dem Zeitpunkt, an dem die Transaktion erstellt wird, bis ein Miner sie in einen Block aufnimmt. Während dieses Fensters kann eine modifizierte Transaktion gesendet werden, und es ist ein Rennen, um zu sehen, welche es in den Block schafft. Derjenige, der verliert, wird niemals bestätigt, da er Eingaben ausgibt, die bereits ausgegeben wurden. Egal welcher gewinnt, die Coins werden an den richtigen Bestimmungsort geschickt.

Das Problem für Mt Gox (und andere) ist, dass sie eine Transaktion anhand ihrer Transaktions-ID verfolgen. Wenn die geänderte Transaktion gewinnt und in einen Block aufgenommen wird, wird die ursprüngliche Transaktion verworfen. Dies veranlasste Mt Gox dann zu der Annahme, dass das Geld nicht bezahlt wurde (da die Transaktions-ID nicht in der Blockchain war) und sie würden eine neue Transaktion erstellen, um das Geld erneut zu bezahlen.

@Gracchus Ich würde es nicht genau Inkompetenz nennen. Sie gingen von einer ziemlich natürlichen Annahme aus, dass etwas, das als „Transaktions-ID“ bezeichnet wird, verwendet werden könnte, um eine Transaktion zu identifizieren. Ich bin selbst schuldig und musste meinen Code ändern, um stattdessen eine „normalisierte Transaktions-ID“ zu verwenden, um Duplikate leicht zu erkennen.
@Gracchus Ich wurde nicht beleidigt, sorry, wenn ich diesen Eindruck erweckt habe. Was ich meinte war, wenn Sie einem Programmierer sagen, dass etwas ein Bezeichner ist, wird der Programmierer davon ausgehen, dass es unveränderlich ist. Das Problem ist, dass die Transaktions-ID ein Hash der gesamten Transaktion ist und nicht Teil der Transaktion selbst. Jede Änderung in der serialisierten Form der Transaktion führt also zu einer Änderung der ID. Da die Signatur selbst nicht signiert werden kann (Henne-Ei-Problem), bleibt sie offen für Änderungen.
@Gracchus Es wäre kein Problem, wenn von Anfang an eine kanonische Codierung erzwungen würde. Dann hätte es nur einen akzeptablen Bytestrom für eine Transaktion gegeben und die Transaktions-ID wäre eindeutig. Sie können nicht nur Schlüssel, Signaturen und Daten ohne einen Rahmen zum Codieren der Daten haben, es sei denn, alles hat eine feste Länge. Andernfalls haben Sie keine Ahnung, welche Teile des Bytestroms zu welchem ​​Objekt gehören.
@Gracchus Nein, ich meinte, dass Sie ein Codierungsschema benötigen, wenn sie keine feste Länge haben. Ein Beispiel wäre ASN.1, dessen kanonische Teilmenge DER (Distinguished Encoding Rules) ist. Tatsächlich wird die Signatur mit DER verschlüsselt. Ein Problem tritt auf, da der Decoder (OpenSSL im Fall des Referenzclients) Nicht-DER-Codierungen zulässt. Jetzt müssen Sie also entweder die Signatur selbst scannen, um die DER-Regeln durchzusetzen, oder Sie müssen OpenSSL ändern, um ein Flag hinzuzufügen, das besagt, dass nur DER-codierte Daten beim Decodieren der Signatur akzeptabel sind. Das Eingabeskript ist also nicht die einzige Schwachstelle.
Zeichnet der Bitcoin-Client keine Original-Signaturdaten pro Verbindung auf?
AntwortenHierDatenschutz-Bestimmungen1y, 0v