Ich lese das Lightning Network WP und stieß auf SIGHASH_NOINPUT, dann bin ich auf Folgendes gestoßen: Lightning Network: Wie wurde die Formbarkeit tatsächlich behoben?
Gibt es weitere Designüberlegungen im White Paper, die sich in der tatsächlichen Implementierung geändert haben?
Bisher habe ich zwei weitere Unterschiede zwischen dem Whitepaper und den BOLT-Spezifikationen gefunden :
Whitepaper : Ein oder beide Teilnehmer müssen den Kanal finanzieren (Seite 7)
BOLT : Nur ein Teilnehmer kann den Channel finanzieren ( BOLT #2 - Channel Establishment )
Für einen bestimmten Kanalzustand hat jeder Teilnehmer seine eigene Commitment-Transaktionsversion, die zwei Ausgänge hat: einen für Alice und einen für Bob. Die für sich selbst bestimmte Leistung kann nur zeitverzögert ausgegeben werden. Aber die Ausgabe für die andere Partei kann sofort ausgegeben werden. Der Einfachheit halber betrachtet die folgende Beschreibung nur die Ansicht einer Partei, die Alice ist.
Alice hat ihre Versionen der Commitment Transaction und der Revocable Delivery Transaction. Die Ausgabe in der Commitment-Transaktion, die für Alice bestimmt ist, erfordert Unterschriften von beiden Parteien und wird in der Eingabe der Revocable Delivery-Transaktion referenziert. Diese Eingabe kann nur nach einer Verzögerung ausgegeben werden, die durch die Sequenznummer angegeben wird (relative Zeitsperre über BIP 68 )
Commitment TX 1 {Alices Version)
Out 0: 2-of-2 multisig (Pubkey_Alice_1, Pubkey_Bob_1)
Out 1: Pubkey_Bob_2
Widerrufbare Lieferung TX 1 (Alices Version)
In: sig_Alice_1, sig_Bob_1 // timelocked via BIP 68 (nSequence < MAX_INT)
Out: <Pubkey_Alice_2>
Alice kann den Kanal also jederzeit (einseitig) schließen, indem sie beide oben genannten Transaktionen rundsendet. Wenn sie das tun würde, müsste sie jedoch einige Zeit warten, bis sie das Geld aus der widerruflichen Lieferungstransaktion tatsächlich ausgeben kann.
Wenn nun beide Parteien den Kanalstatus aktualisieren möchten, müssen sie ihre aktuellen Commitment-Transaktionen widerrufen. Alice widerruft ihre Commitment-Transaktion, indem sie Bob ihren privaten Schlüssel ihrer Commitment-Transaktionsausgabe sendet. Wenn Alice nun versucht zu betrügen, indem sie ihre alte Verpflichtungstransaktion und widerrufliche Liefertransaktion sendet, muss sie warten, weil sie ihr Geld nur über ihre widerrufbare Liefertransaktion ausgeben kann, die zeitlich gesperrt ist. Da Bob jetzt jedoch beide privaten Schlüssel für Alices Ausgabe von Commitment Transaction 1 hat, kann er diese Ausgabe sofort mit der folgenden Transaktion ausgeben (und dadurch Alices Revocable Delivery Transaction ungültig machen):
Breach Remedy TX
In: sig_Alice_1, sig_Bob_1
Out: Pubkey_Bob_3
Kurz gesagt: Alice widerruft ihre Commitment-Transaktion, indem sie Bob ihren privaten Schlüssel gibt. Auch die Zeitverzögerung für Alice wird in einer separaten Transaktion über eine Zeitsperre des BIP 68 implementiert.
Alice hat nur eine Commitment-Transaktion. Die Ausgabe, die für Alice bestimmt ist, hat zwei mögliche Erlösungspfade. Der erste Pfad erfordert den privaten Widerrufsschlüssel und der zweite Pfad erfordert den privaten Schlüssel von Alice und wird mit einer relativen Zeitsperre unter Verwendung von OP_CHECKSEQUENCEVERIFY ( BIP 112 ) verzögert.
Commitment TX 1 (Alices Version)
Out 0: IF
<Revocation_Pubkey> // first path
ELSE
<time_delay> // second path
<Pubkey_Alice>
Out 1: <Pubkey_Bob>
Wenn beide Parteien zum nächsten Kanalzustand übergehen, widerrufen sie ihre Commitment-Transaktionen. Alice widerruft ihre Commitment-Transaktion, indem sie ihre Hälfte des privaten Widerrufsschlüssels an Bob sendet. Wenn Alice also versucht zu betrügen, indem sie die alte Commitment-Transaktion sendet, kann Bob eine Transaktion senden, die Alices Geld über den ersten Weg ausgibt, da er jetzt den vollständigen privaten Widerrufsschlüssel hat:
Verletzung Abhilfe TX 1
In: <Revocation_Privkey>
Out: <Pubkey_Bob>
René Pickhardt