Ich lese das Lightning Network-Papier und habe festgestellt, dass die Autoren bei der Beschreibung bidirektionaler Zahlungskanäle „Breach Remedy-Transaktionen“ und den Austausch der privaten Schlüssel der beiden Parteien verwendet haben, um eine der Parteien davon abzuhalten, eine alte Commitment-Transaktion zu übertragen. Dies ist in der Tat eine effektive Lösung, aber ich habe an mehr als einer Stelle gelesen (z. B. hier , hier), dass dies tatsächlich durch Hashlocks erreicht wird (dh die beiden Parteien erstellen Hashlock-Transaktionen aus ihren Commitment-Transaktionen und teilen das Hashlock-Geheimnis, anstatt ihre privaten Schlüssel auszutauschen, um die Übertragung früherer Commitment-Transaktionen zu verhindern, wenn sie den Kanal aktualisieren). In dem Papier werden Hashlocks verwendet, wenn die bidirektionalen Zahlungskanäle verwendet werden, um Zahlungen zwischen mehr als zwei Knoten weiterzuleiten, sie werden jedoch nicht für Zahlungskanäle zwischen zwei Knoten verwendet.
Die Frage ist also: Werden Commitment-Transaktionen zwischen zwei Knoten durch Hashlocks oder durch den Austausch privater Schlüssel widerrufen?
Die Frage ist also: Werden Commitment-Transaktionen zwischen zwei Knoten durch Hashlocks oder durch den Austausch privater Schlüssel widerrufen?
Beide Wege funktionieren, aber Hashlocks sind einfacher. Sie werden in Abschnitt 4 des von Ihnen verlinkten Dokuments beschrieben. In einem auf dem Austausch privater Schlüssel basierenden System müssen Sie jede Transaktion zur Behebung von Sicherheitsverletzungen speichern (etwa 250 Bytes), aber in einem Hashlock-System benötigen Sie nur 20 Bytes für jedes Preimage.
Sie müssen auch nicht jedes Preimage speichern. Murch erklärt und verlinkt hier ein System, um jeden Hash in einem Kanal mit maximal 64*20 Byte Speicher zu speichern: Was ist ein Hash-Pre-Image, wie es zur Abhilfe bei Sicherheitsverletzungen verwendet wird?
Simon Bronzini
Nick Odell