Ich versuche, den formbaren Transaktionsangriff zu verstehen, da es mir scheint, dass nur ein ziemlich unachtsamer Bediener überhaupt anfällig wäre, wie unten beschrieben.
Lassen Sie mich, hauptsächlich um meine eigenen Gedanken zu verdeutlichen, den Angriff so beschreiben, wie ich ihn verstehe. Dramatis personae: Alice ist die Angreiferin, und Bob ist ein "Bankier" (Börsenbetreiber, Web-Wallet; jemand, der für Alice Coins auf seinem Konto hält.)
Alice : Hallo Bob, ich habe 1 BTC auf meinem Konto und möchte es abheben. Bitte senden Sie es an die Adresse 1Alice1.
Bob : Okay, ich habe eine Transaktion generiert, ihr Hash ist 123abc. Ich habe es gerade im P2P-Netzwerk gepostet. Es gibt Ausgabe 3 der vorherigen Transaktion 987def aus und sendet 1 BTC an 1Alice1. Ihr Konto wurde mit 1 BTC belastet und Ihr neues Guthaben beträgt 0.
Alice : Danke, ich sehe die Transaktion. Ich warte auf die Bestätigung.
Jetzt konstruiert Alice eine "mutierte" Transaktion mit der gleichen Wirkung wie 123abc; Es gibt immer noch Ausgabe 3 von 987def aus und sendet 1 BTC an 1Alice1, und die Signatur wird immer noch überprüft, aber die Mutante hat einen anderen Hash 456bca. Irgendwie bekommt Alice 456bca statt 123abc in die Blockchain. Vielleicht ist sie einfach besser mit dem P2P-Netzwerk verbunden als Bob, oder vielleicht besticht sie Polly, einen Mining-Pool-Betreiber, um 456bca den Vorrang zu geben. Da 123abc mit 456bca in Konflikt steht, wird 123abc niemals bestätigt.
Einige Zeit vergeht.
Alice : Hey Bob, erinnerst du dich, dass ich 1 BTC bekommen sollte? Die Transaktion wurde nie bestätigt.
Bob : Lass mich nachsehen. Ja, ich verstehe, es gibt keine Transaktion wie 123abc in der Blockchain. Nun, ich schätze, Sie haben Ihre Münzen nie bekommen; Das tut mir leid. Ich werde Ihr Konto wieder gutschreiben; Ihr neues Guthaben beträgt 1 BTC.
Alice : Danke. Jetzt, da ich wieder 1 BTC auf meinem Konto habe, möchte ich erneut versuchen, es abzuheben. Senden Sie es an 1Alice2.
Bob : Okay, ich habe eine Transaktion generiert, ihr Hash ist 246fed. Ich habe es gerade im P2P-Netzwerk gepostet. Es gibt Ausgabe 7 der vorherigen Transaktion 369dbc aus. Ihr Konto wurde belastet und hat wieder Saldo 0.
Transaktion 246fed wird normal bestätigt.
Alice : Erwischt, Bob! Ihre ursprüngliche Transaktion ist immerhin nur in mutierter Form als 456bca durchgegangen. Jetzt habe ich es und die neue Transaktion, und ich habe Ihnen gerade 1 BTC gestohlen. Mwa ha ha!
Bob : Oh, wehe mir!
Es scheint jedoch so zu sein, dass dieser Angriff eine ziemlich sorglose Buchhaltung von Bobs Seite erfordert. Selbst wenn Bob keine Ahnung hat, dass es so etwas wie eine formbare Transaktion gibt, weiß er, dass er 123abc generiert und ins Netzwerk gestellt hat, und soweit er weiß, schwimmt es immer noch da draußen herum. Ich würde also denken, dass vor der Neukreditierung von Alices Konto der gesunde Menschenverstand vorschreiben sollte, dass Bob sicherstellt, dass 123abc zu einem späteren Zeitpunkt nicht bestätigt werden kann, vielleicht indem er eine neue Transaktion (963dad) durchführt, die dieselbe Eingabe (trans 987def Ausgabe 3) für eine von ausgibt seine eigenen Adressen (1Bob1) und wartet auf die Bestätigung von 963dad. Natürlich wird 963dad im aktuellen Szenario niemals bestätigen (weil 456bca es ersetzt), und Bob wird es irgendwann leid zu warten und weiter nachzuforschen.
Oder alternativ, wenn Alice zum zweiten Mal darum bittet, 1 BTC abzuheben, sollte Bobs neue Transaktion (678bbb) an Alice erneut dieselbe Eingabe (987def:3) ausgeben, um sicherzustellen, dass Alice später nicht irgendwie 123abc bestätigt bekommen kann. Auch dies vereitelt den Angriff, da 678bbb durch 456bca ungültig gemacht wurde.
Da Alices mutierte Transaktion 456bca tatsächlich Bobs Eingaben (987def:3) ausgegeben hat, sollte Bobs Client-Software ihn nicht darüber informieren, dass diese Eingaben ihm nicht mehr zur Verfügung stehen, und sein Guthaben entsprechend anpassen? Bob glaubt anscheinend, dass 123abc fehlgeschlagen ist, und kontrolliert daher immer noch diese Eingabe, und daher sollte dies seine Bücher aus dem Gleichgewicht bringen und ihn warnen, dass etwas nicht stimmt.
Meines Wissens haben die Bobs der Welt auf das Problem reagiert, indem sie sich darüber beschwert haben, dass "formbare Transaktionen" ein obskurer Protokollfehler sind, von dem nicht erwartet werden konnte, dass sie ihn vorhersehen. Ob das stimmt oder nicht, es scheint mir, dass Bobs Buchhaltungspraktiken bereits fahrlässig sein mussten, um angreifbar zu sein, also hat er wirklich keine Verteidigung, so oder so.
Oder wenn Bob die roten Fahnen gesehen hat, aber die Situation nicht verstanden hat und Alices Konto trotzdem im Interesse des Kundendienstes gutgeschrieben hat, ist es immer noch schwer, viel Sympathie für ihn zu empfinden.
Ist dieser Bericht im Wesentlichen korrekt, oder habe ich einige entscheidende Details übersehen?
Danke und Entschuldigung für die Länge.
Während der größte Teil des von Ihnen beschriebenen Prozesses korrekt ist, gibt es einige Details, bei denen Ihre Annahmen meiner Meinung nach nicht mit der Realität übereinstimmen und Sie daher möglicherweise (etwas) kritischer gegenüber Bob sind, als es tatsächlich verdient ist:
Die Tatsache, dass tx 123abc dem Netzwerk bekannt ist, bedeutet nicht unbedingt, dass Bob, selbst wenn er 456bca nicht kennt, befürchten müsste, dass 123abc reuig werden könnte. Irgendwie sind seine Transaktionen doch weitergegangen, was bei einem hohen Transaktionsvolumen wie einer zentralisierten Brieftasche typischerweise bedeutet, dass die nicht ausgegebene Transaktion 987def, die in 123abc eingeht, inzwischen anderweitig ausgegeben (und bestätigt) wurde. Bob kann dies feststellen, auch ohne zu untersuchen, welche Transaktion den Platz von 123abc eingenommen hat, indem er einfach sieht, dass alle späteren Transaktionen bestätigt werden. Aber natürlich hätte die Aktion, von der Bob erhofft hätte, zu untersuchen, was tx 123abc ersetzt hat (anstatt natürlich auch anzunehmen, dass nur andere gültige tx von seiner Hot-Wallet-Software generiert worden sein könnten), den Betrug verhindert.
Was mit anderen Gründen, die möglicherweise verhindern, dass eine Transaktion durchgeführt wird – vielleicht haben Sie nicht genügend Gebühren aufgenommen oder eine Transaktion gebildet, die Kollegen ansonsten nicht genug gefielen, um sie zu verbreiten, oder Bergleute, um sie einzubeziehen – ist nicht unvernünftig um eine Hot-Wallet automatisch auf die Neusynchronisierung auf das zurückgreifen zu lassen, was in die Blockchain aufgenommen wurde, wodurch die vorherige tx 987def im Wesentlichen doppelt ausgegeben wird, sodass zumindest andere Kunden behandelt werden können. Natürlich würde eine ordnungsgemäße Handhabung dieses Vorkommnis dann intern markieren, um die fehlgeschlagene Transaktion manuell zu handhaben, die in diesem Exploit von Alice fehlen würde und in einem idealen Prozess Bob warnen würde, dass etwas nicht stimmt.
In verteilten Systemen existiert nicht immer ein gemeinsamer globaler Zustand. Was selbstverständlich erscheinen muss, wenn z. B. eine einstündige Unterbrechung des Hot-Wallet-Betriebs ein Abgleich des tatsächlichen Bitcoin-Guthabens und der eigenen Abrechnung vornimmt, ist nicht ganz so trivial, wie wenn das System ständig im Zustand vieler noch unbestätigter Transaktionen ist . Das sollte keine Entschuldigung sein, denn ein gut konzipierter Prüfungs- und Kontenabstimmungsprozess sollte damit umgehen können, aber auch hier ist es denkbar, dass ein zuvor funktionierender, weniger aufwändiger Prozess das Problem der vielen Nichtbestätigungen nicht bewältigen kann Transaktionen.
Ich stimme zu, dass Bob die Situation im Nachhinein ziemlich schlecht gehandhabt hat und nicht mit der Art von Sorgfalt, die Sie von jemandem erwarten würden, dem die Bitcoins anderer anvertraut sind. Aber es ist wirklich schwierig, Prozesse zu entwerfen, insbesondere in einem 24/7-Betrieb mit mehreren Personen, um mit dem fertig zu werden, was Sie aufgrund eines Missverständnisses für völlig unmöglich halten. Bob hat möglicherweise tatsächlich mit einer Art Workaround-Prozess gearbeitet, um mit seiner Hot-Wallet-Implementierung fertig zu werden, die keine angemessene Protokollierung von normalerweise nicht propagierenden Transaktionen ermöglicht.
Im Wesentlichen haben Sie das Argument wiederholt, dass sich niemand um dieses Problem kümmern muss, von dem wir jetzt wissen, dass es falsch ist. Es ist genau wegen dieses Glaubens, dass wir das Chaos haben, das wir jetzt haben.
Ein wichtiges Detail, das Sie übersehen haben, ist, dass Sie beim Ausgeben der Ausgaben einer vorherigen Transaktion deren Transaktions-ID in Ihrer neuen Transaktion angeben müssen. Es gibt also viele andere mögliche Ausfallszenarien.
Angenommen, Sie bilden nur Transaktionen, die Ihre eigenen Ausgaben ausgeben, sodass Sie davon ausgehen können, dass Ihre Transaktionen letztendlich definitiv erfolgreich sein werden, und Sie daher Transaktionen verketten können, ohne auf Bestätigungen zu warten. Bis vor kurzem galt dies als der richtige Weg, um hohe Transaktionsvolumina zu generieren.
Aber wir verstehen jetzt, dass dies nicht möglich ist, da die Kette vollständig unterbrochen werden kann, wenn die ID einer Transaktion in der Kette geändert wird. Die nächste Transaktion, die sich auf eine dieser Ausgaben bezieht, wird niemals bestätigt, da in einer ihrer Eingaben die falsche Transaktions-ID angegeben ist. Spätere Transaktionen, die von dieser Transaktion ausgegeben werden, werden ebenfalls fehlschlagen und Sie werden ein unheiliges Durcheinander haben.
Ich wollte dies ursprünglich als Kommentar formulieren, aber ich bin zuversichtlich genug, um die Ablehnungen mit einer Antwort zu riskieren:
Was Bob hätte tun sollen, war, die ursprünglichen Eingaben erneut auszugeben (möglicherweise durch einfaches erneutes Senden seines ursprünglichen txn). Wenn sich die alternative txn bereits in der Blockchain befände, würde die neue txn korrekterweise als Double-Spend zurückgewiesen, was Bob darauf aufmerksam macht, dass die Coins tatsächlich den Besitzer gewechselt haben.
Ich freue mich darauf zu erfahren, warum meine einfache Erklärung falsch ist :)
Schauen Sie sich dieses Video an, das angeblich einen Formbarkeits-Hack auf mtgox demonstriert:
https://www.youtube.com/watch?v=WfKy3DEiOwY
Sieht so aus, als hätte gox sein Konto nach der fehlgeschlagenen Transaktion automatisch wieder gutgeschrieben - was sowohl die Fiat-Diskrepanz (verkaufen Sie Ihre gehackten Coins für Fiat) als auch die Coin-Diskrepanz erklären würde.
Jetzt ist die eigentliche Frage:
Wieso haben diese Idioten bei Gox das nicht bemerkt?