Glossar / Lightning und Layer 2
Payment Secret
- Was ist ein Payment Secret?
- Ein Payment Secret ist ein Wert von 32 Bytes, den der Empfänger pro Rechnung erzeugt und im letzten Onion-Payload zurückverlangt, sodass die alleinige Kenntnis des Payment Hash Sie nicht zum Zahler macht.
Das Payment Secret von Lightning wirkt wie ein Passwort pro Rechnung, das der Zahler zurücksendet, bevor der empfangende Node das Geld annimmt. BOLT 11 gibt ihm den Tag-Buchstaben s, legt seine Länge auf 52 Bech32-Zeichen fest und weist den Leser an, jede Rechnung ohne ein solches Feld fehlschlagen zu lassen. Für Sie ist es der Grund, warum ein Routing-Node, der Ihren Payment Hash gesehen hat, nicht erkennen kann, dass die Zahlung bei Ihrer Wallet endete.
Wie es funktioniert
Ein Payment Secret wird von der empfangenden Wallet erzeugt, niemals vom Zahler, und es bleibt im Onion versiegelt, bis die Zahlung ihren letzten Hop erreicht.
BOLT 11 definiert es als getaggtes Feld vom Typ 16, geschrieben mit dem Buchstaben s und einem festen data_length von 52. Diese 52 Bech32-Zeichen tragen 260 Bits, einen Wert von 32 Bytes plus Auffüllung, und wer eine Rechnung schreibt, muss genau eines aufnehmen. Ein Leser muss die Zahlung fehlschlagen lassen, wenn ein Feld fester Länge die falsche Länge hat, und ebenso, wenn kein gültiges s-Feld vorhanden ist.
Der Zahler kopiert den Wert in den Onion-Payload, den BOLT 4 als TLV-Datensatz vom Typ 8, payment_data, bezeichnet und der das 32-Byte-Secret und einen total_msat-Wert enthält, für den letzten Node. Nur das Ziel kann diese Schicht abziehen, sodass Zwischen-Hops ihn nie sehen, anders als den Payment Hash, an den alle ihre HTLCs binden.
Die Prüfung am fernen Ende ist bewusst nichtssagend. Ein Secret, das nicht zu dem für diesen Payment Hash erwarteten passt, oder das erforderlich und nicht vorhanden ist, lässt das HTLC mit incorrect_or_unknown_payment_details fehlschlagen, Fehler PERM|15, dieselbe Antwort, die ein unbekannter Payment Hash erhält. BOLT 4 erklärt die Zusammenlegung: Das ältere Paar, PERM|16 incorrect_payment_amount und 17 final_expiry_too_soon, ließ einen weiterleitenden Node Zahlungen mit demselben Hash zu viel niedrigeren Werten erneut senden und die Antwort lesen, um zu bestätigen, dass er das Ziel gefunden hatte.
Die Unterstützung wird nicht mehr ausgehandelt. BOLT 9 führt die Feature-Bits 14 und 15, payment_secret, als ASSUMED auf, und die Bits 16 und 17, basic_mpp, hängen davon ab.
Wo Sie es sehen
Ein Payment Secret erkennen Sie in einem modernen lnbc-String als den Abschnitt, der mit sp5 beginnt und 52 Bech32-Zeichen lang weiterläuft.
In den Testvektoren von BOLT 11 ist dieser Abschnitt zyg3, zwölfmal wiederholt, gefolgt von zygs, und kodiert ein Secret, dessen 32 Bytes alle 0x11 sind. Sie tippen ein Payment Secret nie selbst ein: Nur der Verfasser der Rechnung und die zahlende Wallet handhaben den Wert überhaupt.
Seinen Nutzen zeigt das Feld bei Multipart-Zahlungen. Wenn keine einzelne Route genug Liquidität hat und die Rechnung basic_mpp anbietet, lässt BOLT 4 eine Wallet den Betrag auf mehrere HTLCs aufteilen, die sich einen Payment Hash teilen, und jeder Teil muss das Secret tragen und sollte sich auf total_msat einigen. Der Empfänger löst nichts ein, bis der Gesamtbetrag eingeht, und sollte mindestens 60 Sekunden nach dem ersten HTLC warten, bevor er die Gruppe mit einem mpp_timeout fehlschlagen lässt. Eine größere Lightning-Auszahlung aus einer Lightning-First-App wie Strike, die eine Minute lang ausstehend bleibt und dann zurückprallt, kann also eine ablaufende, unvollständige HTLC-Gruppe sein und nicht verlorenes Geld. Ob Ihre eigene Wallet diese Teile zusammenfügt, wie Phoenix es tut, indem sie einen echten Lightning-Node auf dem Gerät betreibt, oder ob ein Verwahrer dies auf einem Server tut, den Sie nicht steuern, das Secret kennzeichnet sie als eine Zahlung.
Payment Secret vs. Payment Hash
Der Payment Hash und das Payment Secret sind beide 256-Bit-Felder in einer BOLT-11-Rechnung, und der Unterschied liegt darin, wer sie sehen darf. Jeder Hop erfährt den Hash, weil jeder sein weitergeleitetes HTLC daran bindet, während niemand außer dem letzten Node das Secret erfährt, das in der innersten Onion-Schicht reist. Der Hash beantwortet, ob die Zahlung abgewickelt wurde, und das Preimage, das ihn öffnet, ist der Beleg. Das Secret beantwortet, ob der Zahler von der Rechnung ausgeht, die Sie geschrieben haben, was ein Hash nicht kann, da er für alle auf der Route sichtbar ist. In der Kodierung sehen sie wie Zwillinge aus: Tag p und Tag s, beide 52 Zeichen, beide bei jeder anderen Länge zurückgewiesen.