In Rusty Russells Artikel über die vereinfachte Version des Lightning-Netzwerks werden einige Probleme bei der praktischen Umsetzung der Öffnungskanalmethode aus dem ursprünglichen LN-Artikel erwähnt:
- Die für die Commitment-Eingabe erforderliche Anker-Transaktions-ID ist erst bekannt, wenn der Anker signiert ist.
- Die Ankertransaktion kann von beiden Parteien vor dem Eintritt in die Blockchain manipuliert werden, wodurch die Commitment-Eingabe unbrauchbar wird.
Das Papier erwähnt, dass Problem 2 nicht durch BIP62 gelöst wird, spricht aber nicht über getrennte Zeugen. Werden diese beiden Probleme mit getrennten Zeugen effektiv gelöst?
Werden diese beiden Probleme mit getrennten Zeugen wirksam gelöst?
Einer ist; man ist es nicht. Speziell:
(1) Die für die Commitment-Eingabe erforderliche Anchor-Transaktions-ID ist erst bekannt, wenn der Anchor signiert ist.
Segwit behebt dies. Wenn die Ankertransaktion nur Segwit-Eingaben enthält, ändert sich ihre Transaktionskennung (txid) nicht, wenn Signaturen hinzugefügt werden. Dadurch können andere Transaktionen (z. B. die Lightning Commitment-Transaktion) auf ihre Ausgaben verweisen, unabhängig davon, ob sie signiert wurden oder nicht.
(2) Die Ankertransaktion kann von beiden Parteien vor dem Eintritt in die Blockchain manipuliert werden, wodurch die Commitment-Eingabe unbrauchbar wird.
Segwit behebt dieses spezifische Problem nicht, aber es behebt ein wichtiges verwandtes Problem. Wie das von Ihnen zitierte Papier sagt: "Das letzte davon ist besonders schädlich, da BIP62 es nicht löst: Unterzeichner können eine Transaktion immer erneut signieren und somit ihre Transaktions-ID ändern."
Die Ankertransaktion wird mit Eingaben erstellt, die jeder Benutzer einseitig kontrolliert (oder die Kontrolle mit einem Drittanbieter über den gerade geöffneten Lightning-Kanal teilt, ein irrelevantes Detail für diese Diskussion). Aus diesem Grund hat jeder Benutzer die Möglichkeit, seinen Teil der Ankertransaktion vollständig zu verdoppeln. Wenn diese doppelten Ausgaben in der Blockchain enthalten sind, sind alle Kinder früherer Versionen der Transaktion (z. B. die Commitment-Transaktionen) ungültig.
Das wichtige verwandte Problem, das Segwit löst, ist nützlich für Lightning und wird von anderen intelligenten Vertragsprotokollen benötigt. Eine Zahlung in einem Zahlungskanal (einschließlich Lightning) verwendet Multisig, um von beiden Parteien die Unterzeichnung der Zahlung unter normalen Umständen zu verlangen, was als 2-von-2-Multisig bezeichnet wird. Da Signaturen alle Nicht-Signaturdaten in einer Transaktion (normales SIGHASH_ALL) signieren, aber derzeit beim Generieren der txid enthalten sind, kann jede Partei eine Transaktion einseitig manipulieren, indem sie ihre Signatur ändert.
Aber mit segwit werden alle Nicht-Signaturdaten in einer Transaktion immer noch signiert, aber die Signaturen werden nicht von der txid abgedeckt, sodass keine Partei die txid einseitig ändern kann, ohne die Signatur oder Signaturen der anderen Partei (oder Parteien) ungültig zu machen. Mit anderen Worten, es erfordert sowohl 2-von-2, um eine txid zu ändern, oder allgemeiner für m-von-n, Segwit erfordert mindestens m Teilnehmer, um die txid zu ändern.
Dies vereinfacht das Design von Hashed TimeLock Contracts (HTLCs) im Lightning-Stil und verbessert auch den Datenschutz bei der Durchsetzung von Outsourcing-Kanälen, ist aber für Lightning nicht erforderlich. Es ist jedoch für einige andere intelligente Vertragsprotokolle erforderlich, die Transaktionssequenzen verwenden. Beispielsweise wäre ein Zahlungskanal im Spillman-Stil mit Segwit sicher, aber heute ist er anfällig für Formbarkeit.