Ist die Verformbarkeit von Transaktionen ein Problem beim Empfang von Zahlungen?

Angenommen, ich verwende den ursprünglichen Client, um Zahlungen zu erhalten. Ist folgendes Szenario möglich?

Meine Brieftasche wird über eine unbestätigte Transaktion mit der ID 12 benachrichtigt, bei der eine der Ausgaben eine Adresse ist, die mir gehört.

Jemand ändert die ID der Transaktion auf 13 und leitet sie an den Miner weiter, der den nächsten Block findet.

Meine Brieftasche wird über einen Block benachrichtigt, der eine Transaktion mit der ID 13 enthält, in der eine der Ausgaben eine Adresse ist, die mir gehört.

Die Transaktion mit der ID 13 erhält 6 Bestätigungen, aber die Transaktion mit 12 bleibt als unbestätigte Transaktion in meiner Brieftasche hängen.

Wenn ich meinen Kunden ihre unbestätigten Transaktionen zeige, sieht der Kunde eine bestätigte Transaktion mit der ID 13 und eine unbestätigte Transaktion mit der ID 12. Ist das richtig? Oder löscht QT automatisch die erste Transaktion?

Was kann ich tun, um dies zu verhindern?

Ich denke, Ihr Bitcoin-Qt würde sein Wissen über t12 verwerfen , sobald t13 bestätigt wird, da es sich um doppelte Ausgaben handelt.
Vielen Dank. Können Sie mir einen bestimmten Teil des Quellcodes zeigen, wo ich überprüfen kann, um sicherzugehen?
@AntonAnsgar Hier findet das Entfernen veralteter Transaktionen statt. überprüft hierremoveConflicts den Speicherpool auf widersprüchliche Eingaben .
@JacobTorba Kannst du eine Antwort schreiben, damit ich sie als gültig markieren kann? Vielen Dank.
@AntonAnsgar du hast es verstanden.

Antworten (2)

Wenn Sie auf eine bestätigte Transaktion warten, ist alles in Ordnung. Der häufigste Fehler, den Menschen/große Börsen machen, ist, wenn sie „Abhebungs“-Transaktionen aus unbestätigten „Einzahlungs“-Transaktionen konstruiert haben. Diese werden aufgrund von Double-Spend-Regeln schnell ungültig. Der Satoshi-Client tut dies als letzten Ausweg, wenn er nicht verbrauchte Ausgaben auswählt.

Der Code, der sich damit befasst, ist hier , wird hierremoveConflicts definiert .

Ich habe Transaktionen, die in meiner Wallet hängen bleiben. Was ich meine, ist, dass ich zwei TXes habe, die dieselben Eingänge und dieselben Ausgänge haben. Einer davon ist bestätigt. Der andere wartet unbestätigt. Ich habe mehrere TXs, die einfach so hängen bleiben. Irgendeine Idee, warum sie geschaffen worden sein könnten? Diese Transaktionen sind meistens empfangene Transaktionen. Es gibt auch eine Sendetransaktion, bei der ich die gleichen Ein- und Ausgänge, aber unterschiedliche TX-IDs für 3 Transaktionen habe. Wieder wird einer von ihnen bestätigt. Die anderen beiden stecken einfach fest. Ich brauche wirklich Hilfe dabei. Danke vielmals.
Diese Methode entfernt widersprüchliche Transaktionen aus dem Speicherpool, nicht aus der Brieftasche.
@PieterWullie Danke. Ich weiß nicht, was Memory Pool tatsächlich tut, ich werde es mir ansehen. Aber bedeutet das, dass sie für immer in der Brieftasche sind? Wie kann ich sie loswerden? Und glauben Sie, dass dies mit der Situation passiert, die ich in dieser Frage beschrieben habe: bitcoin.stackexchange.com/questions/22663/…
Ich habe gerade aus der Antwort von Pieter auf die Frage herausgefunden: bitcoin.stackexchange.com/questions/22663/… dass der vorhandene removeConflicts-Code dieses Problem nicht behandelt.

Eine unbestätigte Transaktion kann nicht ausgegeben werden. Ende der Geschichte wirklich.

Aber der Vollständigkeit halber, wenn Sie versuchen, es auszugeben, bleibt Ihre Transaktion auch bei der Person, die Sie bezahlt haben, unbestätigt. Keine dieser Transaktionen wird jemals in die Blockchain gelangen.

Die Frage ist nicht, ob es ausgegeben werden kann. Die Frage ist, ob die in der Frage beschriebene Situation möglich ist
Nein das ist nicht möglich.
Wirklich? Wie? Wissen Sie, welcher Teil des Quellcodes die erste Transaktion löschen wird?
Ich habe gerade erfahren, dass es tatsächlich möglich ist. Siehe: bitcoin.stackexchange.com/questions/22663/…
Ist die Verformbarkeit von Transaktionen ein Problem beim Empfang von Zahlungen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v