Der Bitcoin -Entwickler Gregory Maxwell schreibt Folgendes auf Reddit:
Es gibt einen Designfehler im Bitcoin -Protokoll, in dem ein Dritter möglich ist, eine gültige Transaktion von Ihnen durchzuführen und es auf eine Weise zu mutieren, die ihn gültig und funktionell identisch lässt, aber mit einer anderen Transaktions -ID. Dies kompliziert stark das Schreiben der korrekten Brieftaschensoftware und kann missbräuchlich verwendet werden, um lange Ketten unbestätigter Transaktionen ungültig zu machen, die von der nicht-mutanten Transaktion abhängen (da sich Transaktionen von TXID aufeinander beziehen).
Dieses Problem ergibt sich aus mehreren Quellen, von denen eine von ihnen OpenSSLs Bereitschaft ist, Signaturen mit ungültigen Kodierungen zu akzeptieren und zu verstehen. Eine normale ECDSA -Signatur codiert zwei große Ganzzahlen, die Codierung nicht konstante Länge – wenn es führende Nullen gibt, die Sie fallen sollen.
Es ist einfach, Software zu schreiben, die davon ausgeht, dass die Signatur eine konstante Länge hat und dann zusätzliche führende Nullen in sich hinterlassen.
Dies ist eine sehr interessante Vorsichtsgeschichte und besonders wichtig, da solche Situationen Teil des Grundes sind, warum wir bestimmte Designentscheidungen in unserer Entwicklungsphilosophie getroffen haben. Insbesondere ist das Problem: Viele Menschen geben weiterhin den Punkt, dass wir uns an vielen Stellen unnötig neu erfinden und unser eigenes Serialisierungsformat erstellen. RLPanstatt die vorhandenen zu verwenden Protobuf Und wir erstellen eine anwendungsspezifische Skriptsprache anstatt „nur Lua zu verwenden“. Dies ist ein sehr gültiges Anliegen; Nicht erfundenes Syndrom ist a häufig verwendete abwertendeEine solche interne Entwicklung erfordert eine Rechtfertigung.
Und die Vorsichtsgeschichte, die ich oben zitiert habe, liefert genau das perfekte Beispiel für die Rechtfertigung, die ich zur Verfügung stellen werde. Externe Technologien, ob Protobuf, Lua oder OpenSSL, sind sehr gut und haben jahrelange Entwicklung dahinter. In vielen Fällen wurden sie jedoch nie mit dem perfekten Konsens, Determinismus und kryptografischen Integrität entworfen, die Kryptowährungen benötigen. Die OpenSSL -Situation oben ist das perfekte Beispiel. Abgesehen von Kryptowährungen gibt es wirklich keine anderen Situationen, in denen die Tatsache, dass Sie eine gültige Signatur aufnehmen und sie in eine andere gültige Signatur mit einem anderen Hash verwandeln können, ein erhebliches Problem, und hier ist es doch tödlich. Eines unserer Grundprinzipien in Ethereum ist Einfachheit. Das Protokoll sollte so einfach wie möglich sein, und das Protokoll sollte keine schwarzen Kisten enthalten. Jedes einzelne Merkmal jedes einzelnen Subprotokolls sollte genau 100% auf dem Whitepaper oder Wiki dokumentiert und mit dieser als Spezifikation implementiert werden (dh Testentwicklung). Dies für ein vorhandenes Softwarepaket ist wohl fast so schwierig wie das Erstellen eines völlig neuen Pakets von Grund auf neu. In der Tat kann es noch schwieriger sein, da vorhandene Softwarepakete häufig mehr Komplexität haben als nötig, um eine Funktion zu vervollständigen, während unsere Alternativen nicht-lesen Sie die Protobuf -Spezifikation und vergleichen Sie es mit dem RPP -Spezifikationen zu verstehen, was ich meine.
Beachten Sie, dass das obige Prinzip seine Grenzen hat. Zum Beispiel sind wir sicherlich nicht dumm genug, mit der Erfindung unserer eigenen Hash-Algorithmen zu beginnen, stattdessen die allgemein anerkannten und gut vettierten SHA3 zu verwenden, und für Unterschriften verwenden wir denselben alten SecP256K1 als Bitcoin, obwohl wir RLP verwenden, um das V, R-Triple zu speichern, und das V-Protokoll (das V-Protokoll) anstelle des öffentlichen Schlüssels für die öffentliche Schlüsse). Diese Art von Situationen sind diejenigen, in denen „nur X-Verwendung“ genau das Richtige ist, da X eine saubere und gut verstandene Schnittstelle hat und keine subtilen Unterschiede zwischen verschiedenen Implementierungen gibt. Der SHA3 der leeren Saite ist C5D2460186 … A470 in C ++, in Python und in JavaScript; Es gibt keine Debatte darüber. Zwischen diesen beiden Extremen geht es im Grunde genommen darum, das richtige Gleichgewicht zu finden.
