Payment-Hash

Jeder Hop auf einer Lightning-Route sieht denselben Payment-Hash, und dieser identifiziert die Zahlung gegenüber jedem von ihnen. BOLT 11 verlangt genau einen davon pro Rechnung, geschrieben als 52 bech32-Zeichen, die 256 Bits tragen. Das passende Geheimnis zu zeigen ist der einzige Weg, das Geld zu beanspruchen, und dieses Geheimnis danach aufzubewahren ist Ihr Beleg.

So funktioniert es

Ein Payment-Hash beginnt sein Leben als sein Gegenteil: Der Empfänger wählt 32 zufällige Bytes, Payment Preimage genannt, und veröffentlicht nur deren SHA-256.

Dieser Wert kommt in die Rechnung unter dem Tag p, den BOLT 11 auf einen data_length von 52 festlegt und genau einmal verlangt. Von dort wandert er die Route entlang innerhalb von update_add_htlc, Nachrichtentyp 128, dessen Felder die Kanal-ID, ein 64-Bit-Zähler, der Betrag in Millisatoshi, der payment_hash selbst, ein CLTV-Ablauf und eine 1366-Byte-Zwiebel sind. In dieser Nachricht hat er eine Doppelfunktion: Er wird auch der Zwiebelkonstruktion als assoziierte Daten zugeführt, sodass die HMACs auf jedem Hop ihn einbeziehen. Ein altes Zwiebelpaket gegen einen anderen Payment-Hash erneut zu senden scheitert daher am ersten Node, der prüft.

Die Abwicklung läuft den Hash rückwärts. Der Empfänger gibt das Preimage in update_fulfill_htlc zurück, Nachrichtentyp 130, als reinen Wert von 32 Bytes, und jeder Node stromaufwärts reicht es über dieselben Kanäle zurück. Ein Node, dem ein Preimage übergeben wird, das nicht per SHA-256 den Hash ergibt, den er hält, ignoriert es nicht einfach: BOLT 2 sagt, dass er entweder eine Warnung senden und die Verbindung schließen oder einen Fehler senden und den Kanal scheitern lassen muss, weil es keine harmlose Erklärung gibt.

On-Chain wird der Hash gekürzt. Das Skript des HTLC-Outputs enthält den Wert von 32 Bytes überhaupt nicht; es führt einen OP_HASH160-Vergleich gegen RIPEMD160(payment_hash) aus, ein Commitment von 20 Bytes, und der Ausgebende liefert das Preimage im Witness. Zwei angebotene HTLCs mit demselben gerundeten Betrag und demselben Payment-Hash erzeugen byte-identische Outputs, selbst wenn ihre Ablaufzeiten abweichen, weshalb BOLT 3 eine Ordnungsregel für sie festlegen muss.

Eine Anforderung wirkt seltsam, bis man den Angriff dahinter sieht. Ein Node muss mehrere HTLCs mit demselben Payment-Hash annehmen, und BOLT 2 nennt den Grund: Würden Duplikate abgelehnt, könnte ein Angreifer mit einem bekannten Hash sondieren und erfahren, ob dieser Node diese Zahlung bereits hielt. Die separate 64-Bit-ID existiert, um die Duplikate auseinanderzuhalten.

Warum das beim Bitcoin-Kauf zählt

Zwei der 63 hier bewerteten Kryptobörsen dokumentieren eine Lightning-Auszahlung in ihren Gebührenhinweisen: Strike, dessen Auszahlungshinweis besagt, dass Wallet-Auszahlungen über Lightning und On-Chain unterstützt werden, und Coinbase, dessen Gebührentabelle eine Lightning-Sendung mit 0,2 % des gesendeten Betrags bepreist.

Wenn eine dieser Auszahlungen hängt, gibt es keine Transaktions-ID zum Nachschlagen, weil nichts die Blockchain erreicht hat. Der Payment-Hash ist die einzige Zeichenfolge, die Ihr Wallet-Protokoll und das Backoffice der Börse beide haben, also kopieren Sie ihn vom Bildschirm mit den Zahlungsdetails, bevor Sie ihn schließen. Ein Support, der nach der "Transaktions-ID" einer Lightning-Auszahlung fragt, fragt nach diesem Wert.

Der Fehler, den Sie zurückbekommen, wird Ihnen nicht viel sagen, und das ist Absicht. BOLT 4 fasst fünf verschiedene Probleme in einen Fehlercode zusammen, incorrect_or_unknown_payment_details, nummeriert PERM|15: Der Hash ist dem letzten Node unbekannt, das Payment Secret passt nicht dazu, der Betrag für diesen Hash ist zu niedrig, der Ablauf liegt zu nah an der aktuellen Blockhöhe, oder erforderliche Zahlungsmetadaten fehlen. Die Spezifikation erklärt die Zusammenlegung. Die älteren getrennten Codes ließen einen weiterleitenden Node erraten, wohin eine Zahlung ging, indem er denselben Hash mit einem viel niedrigeren Wert weitersandte und die Antwort las. Ihre Wallet verbirgt Ihnen den Grund nicht, ihr wurde er nie mitgeteilt, also ist das erneute Erzeugen der Rechnung und erneutes Bezahlen die praktische Antwort.

Derselbe Wert bleibt von Ihrem Node bis zum Empfänger identisch, auch über jeden Teil einer mehrteiligen Zahlung hinweg, die nach BOLT 4 einen einzigen Payment-Hash teilen muss. Wer ihn zweimal sieht, weiß, dass er eine einzige Zahlung vor sich hat. Unsere Bewertung von Phoenix zitiert die eigene FAQ von ACINQ, die einräumt, dass sie das endgültige Ziel und den Betrag von Zahlungen kennt, die über die Wallet abgewickelt werden, was die unverblümte Version derselben Exposition ist, vom Anbieter genannt und nicht von dieser Website abgeleitet.

Eine Rechnung wiederzuverwenden ist aus einem verwandten Grund schlimmer als nutzlos. BOLT 4 lässt einem letzten Node, dem ein bereits bezahlter Hash übergeben wird, die Freiheit, ihn entweder als unbekannt zu behandeln oder das Geld anzunehmen, sodass das Ergebnis eines erneut veröffentlichten QR-Codes davon abhängt, welche Implementierung der Empfänger zufällig betreibt.

Den Payment-Hash im BOLT 11-Spenden-Testvektor dekodieren

Die BOLT 11-Spezifikation enthält eine ausgearbeitete Spendenrechnung, und der darin enthaltene Payment-Hash ist ein fester Testwert, den keine Wallet jemals erzeugen sollte.

Das Beispiel trägt die Überschrift "Please make a donation of any amount using payment_hash 0001020304050607080900010203040506070809000102030405060708090102", und die Zeichenfolge beginnt mit lnbc1pvjluez. Nach dem Präfix lnbc und dem bech32-Trenner ist pvjluez der Zeitstempel, 1496314658 Sekunden seit dem Beginn von 1970. Als Nächstes kommt das Feld für das Payment Secret, danach das Tag p und dann p5, die Länge: In bech32 ist p gleich 1 und 5 gleich 20, also umfasst das Feld 1 * 32 + 20 = 52 Zeichen. Diese Zeichen, qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypq, dekodieren zu dem in dieser Überschrift genannten Hash.

Daran ist nichts privat. Die Spezifikation veröffentlicht den privaten Schlüssel, mit dem ihre Beispiele signiert sind, e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734, und sagt, dass jede Rechnung in jenem Abschnitt das Payment Secret 1111111111111111111111111111111111111111111111111111111111111111 trägt, sofern nichts anderes vermerkt ist, sodass diese Zeichenfolgen Parser-Fixtures und keine Zahlungsanforderungen sind. Wenn eine Wallet oder ein Diagnosewerkzeug Ihnen jemals diesen Hash außerhalb einer Testsuite zeigt, gibt etwas die Spezifikation wieder, statt Ihre Zahlung zu melden.

Payment-Hash vs. Transaktions-ID

Ein Payment-Hash benennt eine Lightning-Zahlung; eine Transaktions-ID benennt eine Transaktion, die auf der Bitcoin-Blockchain existiert. Beide sind 32 Bytes, und beide werden als 64 hexadezimale Zeichen ausgegeben, weshalb sie in den Support-Formularen des jeweils anderen landen. Eine Transaktions-ID wird im Nachhinein aus den Bytes der Transaktion selbst berechnet und kann in jeden Block-Explorer eingefügt werden. Ein Payment-Hash wird vom Empfänger gewählt, bevor die Zahlung existiert, erscheint nie in einem Block, wenn die Zahlung normal abgewickelt wird, und liefert in einem Explorer nichts zurück. Ein leeres Suchergebnis bedeutet meist, dass Sie den richtigen Wert und das falsche Werkzeug haben.

Payment-Hash vs. Payment Secret

Ein Payment-Hash und ein Payment Secret sind zwei verschiedene Werte von 256 Bits in derselben Rechnung, transportiert in den Tags p und s und jeweils als 52 bech32-Zeichen kodiert. Der Hash ist notwendigerweise öffentlich: Jeder Hop muss ihn sehen, um sein HTLC zu bauen. Das Secret wird nur an den letzten Node geliefert, innerhalb der Zwiebel, und BOLT 11 beschreibt seine Aufgabe in einer Zeile, dass es "prevents forwarding nodes from probing the payment recipient" (verhindert, dass weiterleitende Nodes den Zahlungsempfänger sondieren). Ein Leser, der kein s-Feld findet, muss die Zahlung gänzlich scheitern lassen. Der Hash ist das Schloss; das Secret ist der Nachweis, dass der Zahlende die Rechnung von der Person erhalten hat, die sie ausgestellt hat.