Lightning - warum sollen Commitment-Transaktionen unterschiedliche Schlüssel verwenden?

In der Arbeit werden BIP32 und deterministische Schlüsselableitung erwähnt. Aber warum, da zwei Peers Nachrichten direkt austauschen (dh es besteht keine Notwendigkeit, etwas zu verschleiern)? Alice tauscht immer Status mit Bob aus und diese Commitment-Transaktionen landen normalerweise nicht auf der Blockchain.

Bestrafungen für die Übertragung eines alten Zustands können durch Anhängen an die vorherige „Breach-Remedy“-Transaktion unter Verwendung eines gültigen Preimages (das ausgetauscht wurde, während das neue „Commitment“ erhalten wurde) erfolgen. Das bedeutet, dass das Skript die Signatur prüfen und die Hash-Funktion aufrufen muss. Eine Optimierung besteht darin, Tricks mit elliptischen Kurven zu verwenden und so etwas Ähnliches wie das Pay2Contract-Schema zu konstruieren. Ich glaube, auf diese Weise müssen Sie immer noch alle alten Werte speichern, oder irre ich mich? Ich habe von ELKREM und Optimierungen in diesem Teil gehört. Aber meine Frage hier ist grundlegender, warum haben Poon und Dryja überhaupt BIP32 in Betracht gezogen? Ich verstehe die Notwendigkeit verschiedener Abrechnungsschlüssel in Eltoo oder die zusätzliche Privatsphäre für On-Chain-Transaktionen, aber was ist mit Lightning?

Mir fällt nur ein hypothetischer Fall ein. Angenommen, Bob betrügt und veröffentlicht eine alte "Verpflichtung". Dann bestraft Alice ihn, aber auf eine Weise, dass die Leute, die die Blockchain überwachen, nicht sehen können, dass Alice, die sofort Geld bekommt, und die Alice, die die „Strafbelohnung“ erhält, dieselbe Entität ist. In gewisser Weise verbergen Sie also vor der Öffentlichkeit, dass Bob betrogen hat.

Antworten (2)

Eine Optimierung besteht darin, Tricks mit elliptischen Kurven zu verwenden und so etwas Ähnliches wie das Pay2Contract-Schema zu konstruieren. Ich glaube, auf diese Weise müssen Sie immer noch alle alten Werte speichern, oder irre ich mich?

Der Trick mit der elliptischen Kurve, den Sie erwähnt haben, ist die Multiplikation elliptischer Kurven. Und ja, Sie müssen alle alten Werte speichern.

In BOLT-03 werden unter Key Derivation drei Gründe angegeben, warum die Schlüssel geändert werden ( localpubkey, remotepubkey, local_delayedpubkeyund revocationpubkey), und einer davon hängt mit Ihrer Frage zusammen.

Das Ändern von localpubkeyevery time stellt sicher, dass die Commitment-Transaktions-ID nicht erraten werden kann, außer in dem trivialen Fall, in dem es keine to_localAusgabe gibt, da jede Commitment-Transaktion eine ID in ihrem Ausgabeskript verwendet.

Ich denke, der Grund ist, dass die Autoren Wachtturm-Dienste im Sinn hatten. Ich denke, die Leute sind sich einig, dass sie beim Bau des Poon Dryja-Kanals benötigt werden. Wenn Sie dieselben Schlüssel für Commitment-Transaktionen verwenden, können Wachtturm-Dienste grundsätzlich erfahren, welche Zahlungen in welcher Höhe durch die Kanäle gehen. Und starten Sie einen Angriff auf die Privatsphäre von Personen, die Zahlungen tätigen und erhalten. Wenn sich jedoch die Schlüssel ändern, werden die Kanäle für den Wachturm verschleiert, da der Staat dekoriert wird.

Aber sind Wachtürme in dieser Hinsicht nicht völlig blind? Ja, sie müssen sofort verstehen, dass es eine neue Verpflichtung gab. Aber sie sehen das Zeug selbst nicht wirklich. Sie geben ihnen einfach die erste Hälfte der Txid und sagen ihnen, wenn Sie so etwas sehen, verwenden Sie die andere Hälfte, um meine vorbereitete Bestrafung freizuschalten und zu versenden. Und sie werden dann sehen, ob etwas für sie dabei ist und es tun. Oder müssen Sie ihnen irgendwie beweisen, dass es sich lohnt, die Daten vorher zu speichern?
Ich glaube nicht, dass das der Fall ist. Wie @fiction kommentierte, sind die Türme in dieser Hinsicht blind, außer wenn es einen Kanalbruch gibt. Nach meinem Verständnis besteht der Hauptgrund für die Verwendung verschiedener Schlüssel darin, den Zustand im Falle eines Verstoßes zu verschleiern, unabhängig davon, ob es einen Turm gibt oder nicht.