BOLT12-Angebot

Ein Angebot ist eine Zahlungsaufforderung, die den Zahlungsvorgang übersteht, sodass ein einziger gedruckter Code für jeden Kunden dient. Angebote tragen keine Signatur und keine Prüfsumme, und ihre Felder belegen die TLV-Typen 2 bis 22, die absichtlich so kurz sind, dass die Kamera eines einfachen Smartphones sie erfassen kann. Wenn Sie Bitcoin empfangen, ist das der Unterschied zwischen einem Code, den Sie einmal drucken, und der Rechnung, die er ausstellt, die 7200 Sekunden später abläuft.

So funktioniert es

Ein BOLT12-Angebot ist eine Folge von Type-Length-Value-Datensätzen, geschrieben mit dem für Menschen lesbaren Präfix lno, einem Trennzeichen 1 und danach Zeichen im bech32-Stil, die diese Datensätze in der Reihenfolge transportieren.

Am Ende steht keine sechsstellige Prüfsumme. Die Spezifikation lässt sie weg mit der Begründung, dass QR-Codes ihre eigenen Prüfsummen tragen und dass ein beschädigtes Angebot eine nicht interpretierbare Zeichenkette erzeugt statt einer verlorenen Zahlung. Lange Angebote dürfen mit einem Pluszeichen, optional gefolgt von Leerraum, aufgeteilt werden, damit sie das Einfügen in ein Textfeld mit Zeichenbegrenzung überstehen, und ein Leser muss das Pluszeichen und den Leerraum entfernen, bevor er dekodiert. Ein Schreiber muss durchgehend Kleinbuchstaben oder durchgehend Großbuchstaben verwenden und sollte für QR-Codes Großbuchstaben wählen.

Die Felder selbst sind nummeriert. offer_chains ist 2, offer_metadata 4, offer_currency 6, offer_amount 8, offer_description 10, offer_features 12, offer_absolute_expiry 14, offer_paths 16, offer_issuer 18, offer_quantity_max 20 und offer_issuer_id 22. Ein Schreiber muss innerhalb der Typen 1 bis 79 bleiben, wobei ein zweiter Bereich von 1000000000 bis 1999999999 für Experimente reserviert ist. Nichts in dieser Liste ist eine Signatur, und das ist beabsichtigt: Signieren würde die Zeichenkette ohne Nutzen verlängern, weil jedes Feld, das keine Signatur ist, in die nachfolgende Anfrage kopiert wird, sodass ein manipuliertes Angebot schlicht keine Rechnung erzeugt.

Das Bezahlen erfordert dann zwei weitere Nachrichten. Ihre Wallet sendet eine invoice_request, Präfix lnr, über eine Zwiebelnachricht, kopiert jedes Angebotsfeld einschließlich der Felder, die sie nicht versteht, und signiert das Ergebnis mit einer BIP340-Signatur über eine Merkle-Wurzel. Der Aussteller antwortet mit einer signierten Rechnung. Die Merkle-Konstruktion paart das Blatt jedes Feldes mit einem Nonce-Blatt, und dadurch kann ein Zahler später ein Feld einer strittigen Rechnung offenlegen, ohne dessen Nachbarn preiszugeben, was eine BOLT11-Signatur über die gesamte Zeichenkette nicht leisten kann.

Zwei dieser drei Nachrichten laufen für Rückerstattungen und Geldautomaten in umgekehrter Richtung. Ein Händler veröffentlicht eine invoice_request, die einen Betrag nennt, den er senden möchte, Sie antworten mit einer Rechnung, und der Händler bestätigt die invoice_node_id, bevor er zahlt.

Warum das beim Bitcoin-Kauf zählt

Ein Angebot ändert, wie Sie eine Möglichkeit veröffentlichen, bezahlt zu werden, und ändert gar nichts daran, was es Sie kostet, bezahlt zu werden.

Nehmen Sie die Bewertung von Phoenix auf dieser Website. ACINQ veröffentlicht eine Gebührentabelle, statt Sie sie entdecken zu lassen: Senden über das Lightning-Netzwerk kostet 0,4 % plus 4 Satoshis, Empfangen ist kostenlos, wenn Sie bereits eingehende Liquidität haben, und Empfangen, wenn die Wallet on-chain gehen muss, um Platz zu schaffen, kostet 1 % plus Mining-Gebühren, mit einem neuen Kanal bei 1.000 Satoshis. Ein Angebot auszugeben statt einer Rechnung berührt keine dieser Zahlen. Es beseitigt den Schritt, in dem Sie pro Zahler einen neuen Code ausstellen, nicht den Schritt, in dem jemand für die Liquidität zahlt.

Der Privatsphäregewinn ist real, aber begrenzt. Eine Lightning-Adresse leitet jede Anfrage nach einer Rechnung über einen Webserver in jemandes Domain, und dieser Betreiber sieht die Beträge und den Zeitpunkt. Ein Angebot leitet die Anfrage über das Lightning-Netzwerk als Zwiebelnachricht, und offer_paths lässt einen Node, dessen Kanäle alle privat sind, erreichbar bleiben, ohne überhaupt eine Node-ID zu veröffentlichen. Was das Ihnen nicht verschafft, ist Privatsphäre gegenüber Ihrem eigenen Anbieter: unsere Bewertung von Phoenix zitiert die FAQ von ACINQ, die mit klaren Worten sagt, dass der Dienst das endgültige Ziel und den Betrag von Zahlungen kennt.

Die praktische Warnung betrifft das Einfügen. Das Auszahlungsfeld bei einer Börse verlangt eine Lightning-Rechnung, und eine lno1-Zeichenkette ist keine. Strike, einer der 63 Börseneinträge hier, ist Lightning-native und erhebt bei Überweisungen in mehr als 100 Ländern keine eigene Gebühr, und genau bei solchen Vorgängen werden zwei Formate verwechselt. Weder die 41 Wallet-Bewertungen noch die 63 Börseneinträge auf dieser Website dokumentieren derzeit die Unterstützung von Angeboten als Funktion, sodass Sie dies in den Versionshinweisen Ihrer eigenen Wallet bestätigen sollten, statt es anzunehmen.

Das Angebot eines Hutstands und die Rechnung, die daraus wird

Ein Stand, der Hüte für 25 Dollar verkauft, schreibt ein Angebot mit offer_currency auf USD und offer_amount auf 2500.

Das ist die Regel der Spezifikation für eine andere Währung als Bitcoin: ein dreistelliger ISO-4217-Code und ein Betrag in der Währungseinheit, angepasst an den ISO-4217-Exponenten, was bei Dollar Cent bedeutet. Sobald offer_amount überhaupt gesetzt wird, wird offer_description obligatorisch, weil ein Zahler, dem für etwas Bestimmtes etwas berechnet wird, wissen muss, was es war. Wenn drei Hüte übrig sind, ist offer_quantity_max 3, und wenn der Stand keine feste Grenze hat, ist es 0. Der Wert 1 ist ausdrücklich erlaubt, so unbeholfen er aussieht, damit ein Bestandssystem nie einen Sonderfall für den letzten Artikel braucht. offer_issuer könnte hats@example.com Hat Stall lauten, da die Spezifikation zuerst eine Domain und nach einem Leerzeichen beliebigen freundlichen Text verlangt.

Ihre Wallet liest das, nennt Ihnen einen Preis von 25 Dollar und sendet eine invoice_request mit invreq_quantity gleich 2 für zwei Hüte, eine invreq_payer_id und optional eine invreq_payer_note. Zurück kommt eine Rechnung mit einem Zahlungs-Hash, einem Erstellungszeitstempel, mindestens einem geblendeten Pfad und einer Gebührenangabe je Pfad, die Grundgebühr, anteilige Gebühr, CLTV-Delta sowie den kleinsten und größten HTLC abdeckt, den sie transportiert. Zwei Regeln schützen Sie hier. Ihre Wallet muss die Rechnung ablehnen, wenn ein Feld in den Bereichen 0 bis 159 nicht mit dem übereinstimmt, was sie gesendet hat, und sie muss Sie warnen, wenn der Betrag in Millisatoshis deutlich von der Dollarschätzung abweicht, die das Angebot genannt hat. Sofern der Aussteller nicht invoice_relative_expiry setzt, muss die Rechnung 7200 Sekunden nach ihrer Erstellung abgelehnt werden.

BOLT12-Angebot vs. BOLT11-Rechnung

Ein BOLT12-Angebot ist eine Aufforderung zu einer Zahlungsaufforderung; eine BOLT11-Rechnung ist die Zahlungsaufforderung.

Der BOLT12-Text beginnt mit acht Beschwerden über seinen Vorgänger, und die, die ein Zahler spürt, sind diese. Eine BOLT11-Rechnung wird als Ganzes signiert, sodass der Nachweis eines Feldes bedeutet, alle offenzulegen. Ihre für Menschen lesbaren Beträge erwiesen sich nach dem Urteil der Spezifikation als problematisch: Der Multiplikator p wurde oft falsch behandelt, und in Pico-Bitcoin lässt sich schwerer rechnen als in Satoshis. Ihr payment_secret verhinderte Sondierungen nur, solange die Rechnung zwischen Zahler und Zahlungsempfänger privat blieb, was eine veröffentlichte Rechnung nicht ist. Und nach den eigenen Worten der Spezifikation müssen Rechnungen pro Nutzer ausgegeben werden und sind aktiv gefährlich, wenn zwei Zahlungsversuche für denselben Nutzer unternommen werden. Ein Angebot beantwortet alle vier, indem es überhaupt keine Rechnung ist.

BOLT12-Angebot vs. Lightning-Adresse

Ein BOLT12-Angebot ist eine in sich geschlossene Zeichenkette; eine Lightning-Adresse ist ein Name, den jemandes Server für Sie auflöst.

Beide sind wiederverwendbar, weshalb sie verwechselt werden. Die Adresse hängt von einer Domain, einem Zertifikat und einem Betreiber ab, der den Dienst am Laufen hält, und sie funktioniert an dem Tag nicht mehr, an dem eines der drei ausfällt. Das Angebot hängt davon ab, dass beide Nodes Zwiebelnachrichten sprechen, und von nichts sonst, was eine kleinere Fehlerfläche ist, obwohl Sie bestätigen müssen, dass Ihre eigene Wallet es unterstützt, statt es anzunehmen. Die Adresse gewinnt darin, dass man sie laut aussprechen kann. Eine lange lno1-Zeichenkette ist ein QR-Code, nichts, das man in ein Mikrofon liest.