Wie teilen Alice und Bob ihre flüchtigen privaten Schlüssel gleichzeitig? Wenn nicht, und sagen wir mal, Alice schickt Bob zuerst ihren privaten Schlüssel. An diesem Punkt kann Bob seine aktuelle Commitment-Transaktion und die vorherige Commitment-Transaktion senden (da er den privaten Schlüssel seiner vorherigen Commitment-Transaktion noch nicht an Alice gesendet hat). Aber Alice kann nur ihre aktuelle Commitment-Transaktion senden, da sie ihren privaten Widerrufsschlüssel ihrer vorherigen Commitment-Transaktion bereits an Bob gesendet hat. Diese Asymmetrie ist etwas verwirrend.
Wenn die vorherige Commitment-Transaktion Bob begünstigt hat, was hindert ihn daran, sie zu senden – in dem Wissen, dass Alice ihn nicht bestrafen kann.
Meine Vermutung einer Antwort darauf ist, dass sie ihre privaten Schlüssel teilen, je nachdem, ob der Wert von Alice zu Bob oder von Bob zu Alice fließt. Wie in, wenn die vorherige Commitment-Transaktion Bob begünstigt, dann muss er zuerst seinen privaten Schlüssel teilen. Oder so etwas.
Alice und Bob erstellen gemeinsam einen öffentlichen Schlüssel R für jede widerrufbare Ausgabe (RSMC-Ausgabeskript).
Sie erzeugen jeweils privat r-1 und r-2 und leiten daraus die öffentlichen Schlüssel R-1 und R-2 ab. R ist die Summe von R-1 und R-2. Es wurden keine Geheimnisse ausgetauscht, nur öffentliche Schlüssel. Also ist R für beide nicht entbehrlich. Es ist jedoch für r = r-1 + r-2 verbrauchbar
Wenn ein neuer Commitment-Tx erstellt wird, muss diese RSMC widerrufen werden. Wenn die neue tx-Verpflichtung Bob bevorzugt, dann muss Alice r-1 mit Bob teilen. Jetzt weiß Bob, dass er diese widerrufene Ausgabe ausgeben kann, wenn Alice sie sendet. Bob muss r-2 nicht mit Alice teilen, da er lieber den nachfolgenden tx zu seinen Gunsten senden würde.
Pre-Images werden für das Routing verwendet (HTLC-Ausgabeskripte) Siehe spätere Folien im Kapitel: https://teachbitcoin.github.io/payment_channels.html#/
Es gibt kein Timing-Problem. AFAIK ist ein vereinfachter Algorithmus im Grunde genommen, nachdem Sie eine neue Verpflichtung von der anderen Seite unterzeichnet bekommen haben, können Sie das Geheimnis Ihrer vorherigen Verpflichtung sicher preisgeben. Der Trick ist, dass der Zustand in Lightning asymmetrisch ist und Alices Verpflichtung 1 sich von Bobs Verpflichtung 1 unterscheidet.
Das Abhilfemittel gegen Verstöße ist immer "andere Seite + mein Geheimnis" (im Falle von Hash können Sie sich also vorstellen, dass Sie eine Signatur der anderen Seite + Preimage benötigen, im Falle eines kurzlebigen Schlüssels ist es ähnlich, dass derjenige, der das Geheimnis generiert hat, immer noch nicht den vollständigen Schlüssel generieren kann ).
Angenommen, Alice bekommt ihre neue Verpflichtung von Bob unterschrieben. Es gibt für Alice keinen Grund mehr, ihre alten Verpflichtungen zu nutzen (da Bob sie dafür bestrafen könnte). Natürlich könnte Bob jetzt immer noch die frühere Zusage veröffentlichen, die Alice einmal unterschrieben hat (seine neueste Version). Aber das ist ein bisschen schizophren (er hat gerade unterschrieben, dass er einem neuen Staat zustimmt und jetzt will er weglaufen). Wenn er das tut, könnte es ein Rennen geben – Alice kann ihre Version sofort veröffentlichen und effektiv wird nur eine gewinnen (da beide das 2-von-2-Multisig ausgeben). Zustandsaktualisierungen sind also nicht atomar, wenn S vorgeschlagen wird, kann die andere Seite immer noch mit S-1 aussteigen, aber sobald sich beide zu S verpflichten, gibt es keinen Weg zurück). Auch wenn du würdest
Tejaswi Nadahalli