Das Video (um 28:25) von der offiziellen Lightning-Website beschreibt eine Multi-Hop-Zahlung. Ich verstehe, was ein Hash-Locked Contract ist, aber ich verstehe immer noch nicht, warum wir hier einen Timelock-Aspekt brauchen. Wie Sie auf der Folie sehen, hat bei einer Multi-Hop-Zahlung A -> B -> C -> D (A -> B) eine 3-tägige nLockTime, (B -> C) eine 2-tägige nLockTime, und (C -> D) hat eine 1-tägige nLockTime. nLockTime der Zeit t bedeutet, dass die Transaktion nicht vor t in einen Block aufgenommen werden kann. Mit der Zeit wird also zuerst (C -> D) gültig, dann wird (B -> C) gültig, dann wird (A -> B) gültig.
Joseph Poon sagt bei 28:35 (Hervorhebung von mir):
„Der Kanal von Dave und Carol […] wird zuerst geschlossen .
Ist es nicht umgekehrt: Dave zieht zuerst Geld von Carol ab (zwischen Tag 1 und Tag 2), und dann zieht Carol Geld von Bob ab?
Wie auch immer, was würde schief gehen, wenn wir Zeitschlösser ganz abschaffen würden? Angenommen, Dave generiert ein zufälliges R, sendet H(R) an Alice, Alice erstellt eine hashgesperrte Transaktion und sendet sie über Bob und Carol an Dave. Wenn Dave R aufdeckt, kann jeder sein Geld abheben, wenn er es nicht tut, kann es niemand. Warum brauchen wir zusätzlich Zeitschlösser?
Ich verwende für beide Fragen folgendes Szenario: Alice möchte 1 BTC an Dave zahlen über die Route: Alice -> Bob -> Carol -> Dave
Nehmen wir an, der Zahlungsweg wurde gerade eingerichtet. Bedeutung: Jeder Hop in der Route (A, B, C, D) hat einen HTLC mit seinen Nachbar-Hop(s). Die HTLCs hätten jedoch keine Zeitsperren. Jetzt schickt Dave das geheime R an Carol, die wiederum R an Bob schickt. Bob antwortet jedoch nicht (z. B. weil sein Knoten abgestürzt ist). Leider hat Alice keine Ahnung, warum Bob ihr R nicht schickt. Also muss sie warten, bis Bob wieder reagiert. Nun, das könnte eine Stunde dauern, ein paar Tage, ein paar Wochen, oder vielleicht wird er nie wieder antworten. Das Problem für Alice ist, dass der HTLC zwischen ihr und Bob auf unbestimmte Zeit gültig ist. Ohne eine Zeitsperre kann das Geld, das diesem HTLC zugeteilt wurde, für einen sehr langen Posten festsitzen, und Alice kann nichts dagegen tun.
Das Dekrementieren von Zeitsperren ist nützlich für Zwischensprünge (alle Sprünge außer dem ersten und letzten). In unserem Beispiel lautet die Route:
A -> B -> C -> D
B und C sind also die Zwischensprünge. Laut den HTLCs kann ein Zwischensprung Geld vom vorherigen Sprung verlangen und muss Geld an den nächsten Sprung zahlen. Zum Beispiel: Carol kann Geld von Bob verlangen und muss Geld an Dave zahlen.
Generell bedeutet das: Ein Hop „HOP“ muss sicherstellen, dass nach dem nächsten Hop „NEXT“ das Geld von HOP abgeholt wird, HOP das Geld vom vorherigen Hop „PREV“ vor dem HTLC zwischen PREV und HOP abholen kann ist ungültig (Zeitüberschreitung). Und eine einfache Möglichkeit, dies zu tun, besteht darin, sicherzustellen, dass die HTLC-Zeitsperre zwischen HOP und NEXT (deutlich) niedriger ist als die zwischen HOP und PREV.
Hier ist ein Beispiel dafür, was passieren könnte, wenn alle HTLCs dieselbe Zeitsperre hätten. Für dieses Beispiel nehmen wir an, dass das Timelock „T+10 Blöcke“ ist (T = eine feste Blocknummer). Wenn also die Blockhöhe bei T+10 Blöcken oder später ist, haben alle HTLCs „timed out“ und:
Nachdem nun der Zahlungsweg eingerichtet wurde, passiert Folgendes:
Nach einer Verzögerung (bei T+8 Blöcken) sendet Dave das geheime R an Carol. Dadurch bewies er Carol, dass er (legitimerweise) das Geld von ihrem HTLC einfordern kann. Da beide Parteien ihren Kanal noch nicht schließen möchten, aktualisieren sie stattdessen den Kanalstatus entsprechend. Dadurch hat Carol Dave unwiderruflich Geld gezahlt.
Carol hat jedoch noch kein Geld von Bob erhalten. Also schickt sie R zu Bob. Aber Bob antwortet nicht! Das ist unglücklich für Alice, denn in 2 Blöcken (~ 20 Minuten) kann Bob sein Geld zurückfordern! Um dies zu verhindern, muss Carol sofort den Kanal mit Bob schließen, indem sie die Commitment-Transaktion sendet, die den HTLC enthält. Gleichzeitig muss sie auch noch eine „Liefertransaktion“ schicken, die das Geld vom HTLC (zwischen ihr und Bob) tatsächlich an sich selbst überweist (beabsichtigt). Leider gibt es jedoch keine Garantie dafür, dass beide Transaktionen tatsächlich in den nächsten Block (T+9) aufgenommen werden. Aber wenn nur der HTLC in Block T+9 enthalten ist, kann Bob seine eigene „Liefertransaktion“ senden, die Geld von dem jetzt bestätigten HTLC (über den „Timeout-Pfad“ des Ausgangs) zu sich selbst transferieren (beabsichtigt). Nun gibt es also zwei „Delivery Transactions“ im Mempool, die die gleiche HTLC-Ausgabe verwenden. Wie wir wissen, ist eine doppelte Ausgabe nicht erlaubt. Daher wird nur eine dieser Transaktionen in einen nachfolgenden Block aufgenommen. Und wenn Bobs Transaktion einbezogen wird, verliert Alice ihr Geld.
Abgesehen davon denke ich, dass es technisch auch möglich wäre, vertrauenswürdige Multi-Hop-Zahlungen durchzuführen, ohne Zeitsperren zu verringern. Aber dieses Konzept ist wahrscheinlich viel einfacher zu implementieren und zu warten.
Sergei Tichomirow