Ich fand mich unfähig zu beantworten, was in diesem Fall passieren würde, also hier ist es:
Ein Hacker ( Mr Hacker) gibt UTXO_1und UTXO_2in aus TX_1und hinterlegt den Geldwert aller TX_1Ausgaben von in a Service(z. B. einen Zahlungsabwickler).
Ein legitimer Benutzer ( Mr Legit) gibt UTXO_3in aus TX_2. Auch hier TX_2zielen die Ausgaben von auf dasselbe abService
Beide TX_1und TX_2schaffen es in den gleichen Block und erhalten eine Bestätigung durch das Netzwerk.
Die Servicesofort ausgeben UTXO_1und UTXO_3einzahlen und einzahlen . TX_3_Mr LegitUTXO_2TX_4Mr Smith
Mr Hackerbeschließt dann, doppelt auszugeben TX_1, und erstellt aus diesem Grund, TX_5was alle Ausgaben an sich selbst "umleitet". Mr Hackerist ein Bergmann, damit er die gesamte Hashing-Arbeit ausführen kann, um die doppelte Ausgabe erfolgreich zu machen. Er hat auch Glück und der Double-Spend gelingt.
Die Frage ist also:
Wurden alle vorherigen TXs TX_5(TXs: 1,2,3,4) ungültig gemacht oder nur TX_1, TX_3und TX_4( TX_3und TX_4eine Ausgabe ausgegeben, die zuvor kontrolliert wurde, TX_1die doppelt ausgegeben wurde)?
Mr Legitkonnte 1 Bestätigung für TX_2vor der doppelten Ausgabe sehen. Was sieht er jetzt? Was Mr Smithsieht er in seinem Portemonnaie vor und nach der Doppelausgabe?
Der Service erkennt, dass eine doppelte Ausgabe stattgefunden hat und muss sich von diesem kaputten Zustand erholen. Was muss es tun, um wieder in den Normalbetrieb zu kommen? Muss es alle TXs erneut senden? Verfügt es noch über die Einzahlungen, die TX_2nach der doppelten Ausgabe getätigt wurden, oder muss es etwas unternehmen, um diese Ausgaben zurückzufordern?
Wie kann der , der auch viel Geld zum Ausgeben hat, daran gehindert werden, den gleichen Vorgang für immer zu wiederholen, nur um den Servicereibungslosen Betrieb des zu ruinieren, anstatt auf weitere Bestätigungen zu warten, bevor er die Zahlungen sendet?Mr HackerServiceService
Ich musste dies grafisch darstellen, da die Transaktionen und die Blockchain tatsächlich erscheinen könnten:
Inputs/Prev Outpoints Outpoints
TX1 A:0 TX1:0, TX1:1
TX2 B:0 TX2:0
TX3 TX1:0, TX2:0 ?
TX4 TX1:1 ?
TX5 A:0 TX5:0
(TX5)
Block A ------> Block C ----> Block D
\
----> Block B
(TX1, TX2)
Um Ihre Fragen zu beantworten:
TX3 und TX4 sind in keiner Blockchain gültig, die zuvor nicht TX1 enthält. TX1 kann nicht eingeschlossen werden, wenn TX5 bereits Teil dieser Kette ist, da TX1 und TX5 beide Outpoint A:0 ausgeben.
TX2 ist niemals ungültig, also würde es 1 Bestätigung anzeigen, wenn die Brieftasche, die TX2 sendet, den jetzt veralteten Block heruntergeladen hätte. Nachdem das Wallet auf die neue beste Blockchain umgestellt hat, würde es wieder 0 Bestätigungen anzeigen, da weder Block C noch Block D sie enthalten. Nachdem ein anderer Block in der besten Blockchain ihn enthält, kehrt er zu 1 Bestätigung zurück und erhöht sich von dort aus.
Möchte der Dienst dennoch dieselben Zahlungen leisten, muss er mit noch gültigen Eingaben (z. B. TX2:0) neue Transaktionen (TX6, TX7) erstellen. Wenn er versucht, TX3 oder TX4 erneut zu senden, können andere Knoten ihn für den Versuch verbieten, ungültige Transaktionen weiterzuleiten.
Um zukünftige Fork-basierte Doppelausgaben-Angriffe zu verhindern, muss der Dienst entweder auf weitere Bestätigungen warten oder einen Nicht-Bitcoin-Weg finden, um Geld von Doppelspendern zu sammeln, wie z. B. die Registrierung mit einem staatlich ausgestellten Ausweis. Ich weiß, dass die Anforderung von mehr Bestätigungen mehr Zeit erfordert, was unpraktisch ist, aber es ist die einzige dezentrale Methode, die wir haben, um das Betrugsrisiko zu reduzieren.
TX_1 ist ungültig, weil es im Konflikt mit dem neu bestätigten TX_5 steht. TX_3 und TX_4 sind ebenfalls ungültig, da sie von TX_1 abhängen.
TX_2 bleibt eine gültige Transaktion. Wenn jedoch der Double-Spend-Angriff von Mr. Hacker das Verwaisen des einzelnen Blocks beinhaltete, in dem TX_1 und TX_2 beide enthalten waren, erscheint TX_2 nicht mehr in der Blockkette und hat jetzt 0 Bestätigungen. Aber nichts hindert ihn daran, in einen zukünftigen Block aufgenommen zu werden, und vorausgesetzt, er ist mit einer Gebühr verbunden, hat jeder Miner im Netzwerk einen Anreiz, ihn in seine Blöcke aufzunehmen. Es würde sich also wahrscheinlich schnell bestätigen. (Im Prinzip könnte Mr. Legit hier die Möglichkeit haben, TX_2 doppelt auszugeben und ungültig zu machen, wenn er dies wünscht, aber dies würde wahrscheinlich die Zustimmung eines oder mehrerer mächtiger Miner erfordern.)
Was Mr. Smiths Brieftasche ihm über den jetzt ungültigen TX_4 zeigt, hängt von dieser Software ab. Einige zeigen möglicherweise nur, dass es bei 0 Bestätigungen hängen bleibt. Andere zeigen möglicherweise eine spezifischere Methode an, die ungültig gemacht wurde. In beiden Fällen würden sie hoffentlich deutlich machen, dass er diese Münzen derzeit nicht ausgeben kann.
Angenommen, Service schuldet Mr. Legit und Mr. Smith noch Geld, müssen sie neue Transaktionen erstellen, um sie zu bezahlen. Offensichtlich können sie die Ausgaben von TX_1 nicht länger ausgeben, noch können sie TX_2 ausgeben, bis es erneut bestätigt wird. Möglicherweise müssen sie stattdessen andere UTXOs ausgeben, die sie kontrollieren, oder wenn sie keine haben, müssen sie irgendwo mehr Münzen erwerben.
Ich glaube nicht, dass der Dienst einen wiederholten Angriff vermeiden kann, außer einfach auf weitere Bestätigungen zu warten. Wenn sie Herrn Hacker irgendwie von ihren anderen Kunden unterscheiden könnten, könnten sie ihm allein eine höhere Bestätigungsanforderung auferlegen. Eingehende Transaktionen von anderen Kunden könnten weiterhin sofort ausgegeben werden, während die von Herrn Hacker vor der Ausgabe für zusätzliche Bestätigungen zurückgehalten werden. Das würde die Wahrscheinlichkeit verringern, dass die Angriffe von Mr. Hacker die anderen ausgehenden Transaktionen von Service beeinträchtigen.
Murch