Wie kann ich die Folgen der Transaktionsformbarkeit vermeiden?

Bitte beachten Sie, dass diese Frage KEIN Duplikat anderer Fragen zur Transaktionsformbarkeit ist .

Meine Frage bezieht sich auf ein folgendes Szenario, das an einer Börse passieren könnte, die On-Chain-Wallet-Management verwendet:

  • Der Benutzer zahlt Geld auf die Adresse A ein, die zu seinem Konto an einer Börse gehört. Exchange wartet n Bestätigungen, bevor es dem Benutzerkonto gutgeschrieben wird.
  • Der Benutzer verschiebt dann Geld von Adresse A zu Adresse B, die auch zu seinem Konto an derselben Börse gehört. Exchange wartet hier nicht auf Bestätigungen, weil es weiß, dass es sich nicht doppelt ausgeben wird. Exchange merkt sich somit die TXID dieser Transaktion für die zukünftige Verwendung.
  • Während die Transaktion unbestätigt ist, nutzt jemand das Problem der Verformbarkeit der Transaktion aus und schiebt seine optimierte Version, die stattdessen von Minern abgeholt wird.
  • In der Zwischenzeit möchte der Benutzer Geld an die Adresse C abheben, bei der es sich um eine andere Börse oder eine externe Brieftasche handelt. Exchange erstellt diese Transaktion mit der zuvor gespeicherten TXID. Leider kennt Blockchain diese TXID nicht, da sie von der Mehrheit der Miner abgelehnt wurde. Die Börse erhält jedoch kein sofortiges Feedback darüber, da sie nicht weiß, dass eine optimierte Version dieser Transaktion existiert (da beide noch unbestätigt sind).
  • Tatsächlich werden Gelder nicht abgehoben, und die Börsenbetreiber fragen sich, warum dies passiert ist.

Nun ist mir folgende Situation (noch) NICHT passiert, aber ich frage mich:

  • Ist es realistisch genug, dass es passieren könnte, oder habe ich etwas übersehen?
  • wie kann ich mich davor schützen? Für mich scheint die beste Lösung dafür die Verwendung der neuen NTXID anstelle von TXID in Transaktionseingaben zu sein. Aber das wird wahrscheinlich in naher Zukunft nicht möglich sein, weil eine ziemlich große Änderung im Protokoll erforderlich war.
Soweit ich weiß, können Sie die normalisierte Transaktions-ID (NTXID) als "Helpdesk-ID" für Transaktionen verwenden, die Sie selbst erstellt haben. In Ihrem Beispiel sollten Sie auch die geänderte TXID von B erkennen, um seine Ausgaben in der C-Transaktion verwenden zu können. Die Antwort darauf, wie das geht: bitcoin.stackexchange.com/questions/24048/…

Antworten (2)

Das ist das neue Problem, das den ganzen Ärger verursacht. Sie haben grundsätzlich zwei Möglichkeiten:

  1. Geben Sie keine Ihrer eigenen Ausgaben aus, bis Sie ziemlich sicher sind, dass sie vollständig bestätigt sind. Sie könnten beispielsweise auf drei Bestätigungen warten.

  2. Bereiten Sie sich auf dieses Problem vor, indem Sie Ihre ausstehenden Transaktionsketten überwachen und alle verwaisten Transaktionen mit neuen Eingabetransaktions-IDs erneut ausgeben.

Beide Lösungen haben ihre Schwächen. Nummer eins impliziert, dass der Benutzer zwischen den Aktionen mit seiner Brieftasche warten muss, was nicht das Ende der Welt, aber alles andere als ideal ist. Nummer zwei ist in meinem Fall nicht zu automatisieren, da ich Multi-Signatur-Wallets verwende, was bedeutet, dass der Benutzer jede Transaktion von seinen Wallets bestätigen muss, sodass ich die tx nicht automatisch erneut senden kann, wenn ein Waisenkind erkannt wird. Wie gesagt, der beste Weg, damit umzugehen, wäre die Verwendung von NTXID als Eingabe. Irgendeine Idee, ob das in naher Zukunft auch nur annähernd möglich ist?
@mav Ja, es ist ein echtes Problem. Die Verwendung von NTXID als Eingabe wäre ein schmerzhafter Hard Fork, der von jedem verlangen würde, alle nicht ausgegebenen Ausgaben neu zu indizieren. Ich denke, eine andere Möglichkeit wäre, in einer Transaktion anzugeben, dass auf diese bestimmte Transaktion von NTXID verwiesen wird, und weiterhin zuzulassen, dass "alte" Transaktionen von TXID referenziert werden. Dann könnten Sie diese Option in allen Ihren Transaktionen einstellen. Ich weiß nicht, ob die Community das berücksichtigt hat.
@Gracchus Die Komplexität des Übergangs hängt von der Art der Implementierung ab. Aber im Grunde ist das Verfahren, das Sie skizzieren, wie Sie es tun würden.
@Gracchus, was meinst du mit "abrupt"?
@David, würde dann nicht die ganze Idee von "grünen Adressen" (als bestätigt akzeptieren, wenn sie von einer angesehenen Adresse stammen) unbrauchbar gemacht werden?

Hier ist eine Problemumgehung, die das Kernproblem nicht löst, aber Ihr Problem löst.

Bevor Sie die Transaktion durchführen, überprüfen Sie, ob die Zieladresse auch eine Adresse ist, die demselben Benutzer gehört. Wenn dies der Fall ist, erstellen Sie die Transaktion nicht. Weisen Sie den Benutzer darauf hin, dass die Zieladresse ihm gehört und er diese Übertragung nicht durchführen kann.

Dies kann auch passieren, wenn Adresse B einem anderen Benutzer Ihrer Website gehört. Führen Sie die gleiche Überprüfung durch und führen Sie die Transaktion außerhalb der Kette durch. Aktualisieren Sie einfach die Guthaben der Benutzer, erstellen Sie jedoch keine Bitcoin-Transaktion.

Unter der Annahme, dass dieses Szenario tatsächlich in einem Austausch stattfindet, denke ich, dass Sie die Grenze so bequem ziehen können.

Das Verschieben von Guthaben zwischen zwei Adressen, die demselben Benutzer gehören, klingt nach einer Brieftaschenfunktion. Aber Sie betreiben einen Austausch.

Einige Benutzer könnten sich beschweren, aber hey, besser auf Nummer sicher gehen als goxed. Sie werden verstehen.

Ich betreibe ein Multi-Signatur-Wallet-Schema, ich kann hier nicht einfach "Kontostände der Benutzer aktualisieren". Es ist eine On-Chain-Lösung mit voller Reserve und viel besserer Sicherheit, hat aber den Nachteil, dass ich zwischen jeder Aktion auf die Bestätigung warten muss, um vor Formbarkeit sicher zu sein.
Aha. Hört sich interessant an. Darf ich fragen welche Seite?
Es heißt Bitalo . Wir haben letzten Monat gestartet.
Wie kann ich die Folgen der Transaktionsformbarkeit vermeiden?
AntwortenHierDatenschutz-Bestimmungen1y, 0v