Stellen wir uns vor, ein Angreifer hat es geschafft, Ihre lokale Liste nicht ausgegebener Transaktionsausgaben (oder einen von Ihnen verwendeten Blockhain-Explorer) so zu korrumpieren, dass bestimmte nicht ausgegebene Transaktionsausgaben scheinbar weniger Münzen enthalten als tatsächlich. Wenn Sie eine neue Transaktion durchführen, um 1 BTC zu senden und Ihre Liste der nicht ausgegebenen Ausgaben zu laden, nehmen Sie gerne eine Ausgabe als Eingabe, die scheinbar 2 BTC enthält, aber tatsächlich 100 BTC enthält, aber Sie wissen es nicht, da Sie eine Fälschung haben Information. Daher setzen Sie Ihre Transaktionsausgaben auf 1 BTC für den Empfänger und 0,99 BTC als Wechselgeld, in dem Glauben, eine Gebühr von 0,01 BTC zu zahlen, und Sie unterzeichnen und reichen diese Transaktion glücklich ein. Aber zu Ihrer großen Enttäuschung stellen Sie am nächsten Tag fest, dass Sie tatsächlich 98 BTC als Gebühr bezahlt/verloren haben! Der Angreifer hat nichts gewonnen, aber er hat Sie dazu gebracht, eine erhebliche Menge an BTC zu verlieren.
Mein Punkt ist, dass die Transaktionseingaben in der serialisierten Transaktion nur den Ausgabeindex und den Hash der Transaktion enthalten, aus der die Ausgabe stammt. Da Sie jedoch nicht an das Netzwerk senden, welche Größe die Eingabe Ihrer Meinung nach hat, können Sie eine gültige Transaktion unterzeichnen und übermitteln, obwohl Sie ihr nicht zustimmen, wenn Sie die tatsächliche Größe der beteiligten Eingaben kennen.
Ich weiß - Sie können die Hashes der Transaktionen überprüfen, aus denen die Eingaben stammen, und wenn etwas nicht zu funktionieren scheint, die Transaktion ablehnen, oder die Transaktion wird vom Netzwerk abgelehnt, da es praktisch nicht möglich ist, die Transaktions-Hashes zu "knacken". Ich bin mir aber nicht sicher, ob Lightweight-Clients/Hardware-Wallets tatsächlich die Herkunft von nicht ausgegebenen Ausgaben verifizieren und ich habe den Verdacht, dass beispielsweise TREZOR dies nicht tut, da Sie im Protokoll nur die Transaktionseingaben und -ausgaben senden.
Können Sie mir also sagen, wie und ob aktuelle Lightweight-Clients und Hardware-Wallets vor dem oben beschriebenen Angriff geschützt sind?
Eine einfache Lösung für das obige Problem wäre, die Beträge explizit in die Transaktionseingaben aufzunehmen. Wenn Sie also die Transaktion unterzeichnen, sagen Sie „Ich glaube, dass Eingabe x y Münzen hat und lehnen die Transaktion ab, wenn Sie der Meinung sind, dass dies nicht stimmt“, aber derzeit Es gibt keine Möglichkeit, dies AFAIK zu tun.
Daher stellen Sie Ihre Transaktionsausgaben auf 1 BTC für den Empfänger und 0,99 BTC als Wechselgeld ein, in dem Glauben, eine Gebühr von 0,01 BTC zu zahlen, und Sie unterzeichnen und reichen diese Transaktion glücklich ein. Aber zu Ihrer großen Enttäuschung stellen Sie am nächsten Tag fest, dass Sie tatsächlich 98 BTC als Gebühr bezahlt/verloren haben! Der Angreifer hat nichts gewonnen, aber er hat Sie dazu gebracht, eine erhebliche Menge an BTC zu verlieren.
In der Tat würde dies funktionieren, und es ist ein bekanntes Problem.
Ich weiß - Sie können die Hashes der Transaktionen überprüfen, aus denen die Eingaben stammen, und wenn etwas nicht zu funktionieren scheint, die Transaktion ablehnen, oder die Transaktion wird vom Netzwerk abgelehnt, da es praktisch nicht möglich ist, die Transaktions-Hashes zu "knacken". Ich bin mir aber nicht sicher, ob Lightweight-Clients/Hardware-Wallets tatsächlich die Herkunft von nicht ausgegebenen Ausgaben verifizieren und ich habe den Verdacht, dass beispielsweise TREZOR dies nicht tut, da Sie im Protokoll nur die Transaktionseingaben und -ausgaben senden.
Tatsächlich bestätigen sie dies. Für Legacy-Transaktionen müssen Sie dem TREZOR alle Transaktionen senden, von deren Ausgaben Sie ausgeben, um die beteiligten Beträge nachzuweisen.
Eine einfache Lösung für das obige Problem wäre, die Beträge explizit in die Transaktionseingaben aufzunehmen. Wenn Sie also die Transaktion unterzeichnen, sagen Sie „Ich glaube, dass Eingabe x y Münzen hat und lehnen die Transaktion ab, wenn Sie der Meinung sind, dass dies nicht stimmt“, aber derzeit Es gibt keine Möglichkeit, dies AFAIK zu tun.
Das ist in der Tat eine Lösung, und das ist eine der Änderungen, die in der Änderung des SegWit-Protokolls enthalten waren. Beim Ausgeben einer SegWit-Ausgabe wird eine neue Methode zum Berechnen von Signatur-Hashes verwendet, die explizit den Betrag enthält, den Sie ausgeben.
Das bedeutet, dass die resultierende Signatur ungültig wäre, wenn Sie das Hardwaregerät irgendwie über den ausgegebenen Betrag belügen würden.
Weitere Informationen zu dieser Änderung finden Sie in BIP 143.