Vertrauenslose Inter-Chain-Transaktion mit Bitcoin – gibt es irgendwelche Mängel?

Nehmen wir an, Alice möchte Bob 1 BTC senden, und im Gegenzug sendet Bob Alice 1 ETH.

Die Bitcoin-Adresse von Alice ist BTC_A und die Ethereum-Adresse von Alice ist ETH_A. Ebenso besitzt Bob die Adressen BTC_B und ETH_B.

BTC_B ist eine „frische“ Adresse, ohne jeglichen Transaktionsverlauf.

Alice erstellt eine einzelne Transaktion an ETH_A, die etwas mehr als den Betrag enthält, den sie an Bob senden wird, und sendet sie. Der Transaktions-Hash davon wird tx1 genannt.

Bob wartet auf die Bestätigung dieser Transaktion und erstellt dann einen Smart Contract mit den folgenden (unveränderlichen) Parametern:

inputaddr, auf BTC_A gesetzt

inputtx, von oben auf tx1_txhash setzen

outputaddr, auf BTC_B gesetzt

minfee, eingestellt auf eine "angemessene" Bitcoin-Gebühr/Byte, basierend auf den aktuellen Netzwerkbedingungen

Wartezeit, eingestellt auf die Anzahl der Sekunden, nach denen eine Transaktion mit Minfee auf der BTC-Blockchain bestätigt wird, zuzüglich einer erheblichen Sicherheitsmarge

val wird auf einen Betrag gesetzt, der 1 BTC darstellt, oder wie viel Alice an Bob sendet

Bob zahlt auch 1 ETH in den Smart Contract ein und darf es nicht abheben

Alice sendet eine Transaktion, tx2, an die Bitcoin-Blockchain mit den folgenden Eigenschaften:

  • inputtx ist die einzige Eingabe
  • outputaddr ist die einzige Ausgabeadresse
  • Gebühr > Minfee
  • signiert von BTC_A

Sie unterbreitet diese gesamte Transaktion auch dem Smart Contract, der diese vier Eigenschaften verifiziert. Wenn sie alle erfüllt sind, notieren Sie die Zeit als txtime.

Bob wird die Bitcoin-Blockchain kontinuierlich überwachen, und wenn Alice versucht, die Eingabetransaktion doppelt auszugeben, wird er die doppelte Ausgabentransaktion an den Smart Contract senden. Der Smart Contract wird überprüfen, ob diese Transaktion legitim ist, und wenn sie nicht mit der ersten Transaktion identisch ist, die Alice zuvor eingereicht hat, wird die ETH an ETH_B zurückerstattet.

Bob kann die gesperrte ETH auch zurückziehen, wenn Alice die BTC-Transaktion nicht innerhalb einer angemessenen Frist dem Vertrag unterwirft.

Wenn die Wartezeit seit txtime abgelaufen ist und Bob keinen Nachweis für eine doppelte Ausgabe eingereicht hat, kann Alice die gesperrte ETH nach Belieben an ETH_A abheben.


Das scheint so etwas zu sein, auf das jemand schon gekommen wäre, aber ich konnte keine anderen vertrauenslosen Beispiele für einen BTC-ETH-Austausch finden. Gibt es einen grundlegenden Fehler in diesem System?

Das Problem bei Ihrem Ansatz ist, dass Sie gefälschte Transaktionen an den Vertrag übermitteln können und der Vertrag nicht überprüfen kann, ob sie in der Bitcoin-Blockchain geschürft wurden oder nicht. Möglicherweise müssen Sie BTCRelay verwenden, aber es ist sehr veraltet.
@Ismael kann Bob diese Transaktionen dann nicht einreichen, da sie von Alice signiert wurden und jetzt öffentlich sind?
Bitcoin-Transaktionen haben immer noch einige Formbarkeitsprobleme, es könnte für B möglich sein, tx2 von A zu manipulieren und eine gültige Transaktion zu erhalten, die dieselben Eigenschaften wie tx2 hat, aber nicht dieselben sind, sodass sie so aussehen, als würde A doppelte Ausgaben verursachen.
@Ismael Basierend auf dem, was ich im Bitcoin-Wiki lese, können Sie Formbarkeit vermeiden, indem Sie nur Transaktionen akzeptieren, die genau der Spezifikation entsprechen, und es scheint, dass das Blitznetzwerk auch auf nicht formbaren Transaktionen angewiesen ist

Antworten (1)

Es wurde von Komodo implementiert .

Ich habe auch einen Beispiel-Cross-Chain-Atomic-Swap-Vertrag entwickelt (für BIP-199-kompatible Ketten). Sie können sich das Repo hier ansehen

Ok, diese Terminologie "Atomic Swap" ist das, wonach ich gesucht habe. Sieht so aus, als ob der Prozess etwas ähnlich ist.
Sie sollten Ihrer Antwort weitere Details hinzufügen, da es sich sonst nur um eine Link-Antwort handelt, die nicht viel Wert bietet, wenn sich der Link in Zukunft ändert oder der Host verschwindet.