Nostr Wallet Connect

Anna hört einen Podcast und möchte dessen Autor einen kleinen Betrag über das Lightning Network schicken. Mit NWC kann der Player ihre Wallet direkt um die Zahlung bitten. Der Wallet-Dienst prüft zunächst die Berechtigungen der Verbindung und führt dann erlaubte Anfragen aus. NWC bestimmt nicht, wer die Bitcoin-Schlüssel hält: Auf der anderen Seite kann Annas eigener Knoten stehen oder ein Dienst, der ihr Guthaben verwahrt. Hinter derselben Schaltfläche „Wallet verbinden“ kann deshalb sehr unterschiedliche Kontrolle über das Geld stecken. Je nach erteilten Rechten kann die App auch ohne erneute Bestätigung jeder einzelnen Zahlung handeln. [1] [2]

Die Wallet liefert meist einen QR-Code oder eine Verbindungszeichenfolge, technisch eine URI. Darin stehen der öffentliche Schlüssel des Dienstes, eine Relay-Adresse und secret, der private Schlüssel dieser Client-Verbindung. Das ist weder der Seed, der geheime Ausgangswert der Wallet, noch ihre Seed Phrase, also die Wiederherstellungswörter. Trotzdem ist es kein harmloser öffentlicher Link: Wer eine nutzbare Kopie besitzt, kann dieselben Berechtigungen ausüben. Der mögliche Schaden hängt von erlaubten Funktionen und Limits ab. Getrennte Verbindungen für verschiedene Apps lassen sich unterscheiden und einzeln widerrufen; zugleich werden Verknüpfungen zwischen ihnen erschwert. [1]

Eine App braucht vielleicht nur den Kontostand, eine andere soll auch Geld senden. Das sind verschiedene Berechtigungen. Das öffentliche info-Event zeigt, was der Dienst unterstützt; get_info nennt die für eine konkrete Verbindung verfügbaren Methoden. Eine Methode ist ein benannter Befehl: pay_invoice fordert eine Zahlung an, make_invoice erstellt eine Zahlungsanforderung, lookup_invoice fragt deren Zustand ab, und get_balance liest den Kontostand. Auch get_info gehört zum Grundumfang. Verlauf, keysend als Zahlung ohne zuvor erstellte Rechnung sowie Benachrichtigungen sind optionale Erweiterungen. Ein unterstützter Serverbefehl ist also keine Erlaubnis für jede verbundene App. [1] [3] [5]

Anna möchte dem Player vielleicht nur ein begrenztes Budget geben. Bietet der Dienst Betrags-, Methoden- oder Laufzeitlimits an, muss er sie selbst prüfen. Eine Zahl, die lediglich im Player angezeigt wird, schützt nicht vor einer App, die eine andere Anfrage sendet. Prüfen Sie auch, ob das Budget einmalig gilt oder erneuert wird und wie Gebühren zählen. Nutzt Anna die App nicht mehr, sollte sie deren Berechtigung beim Wallet-Dienst widerrufen. Die App zu löschen oder ihre lokale Verbindung zu entfernen, belegt noch keinen Widerruf. Dieser verhindert künftige Anfragen, macht aber eine abgeschlossene Zahlung nicht rückgängig. [1]

Eine Lightning-Invoice ist eine Zahlungsanforderung, etwa im Format BOLT11, und kein Zahlungsnachweis. NIP-47 gibt Beträge und Gebühren in msat an, Tausendsteln eines Satoshi: 1000 msat = 1 sat. Eine Verwechslung verändert den Betrag um das Tausendfache. make_invoice erstellt lediglich eine Anforderung. Ein erfolgreiches pay_invoice liefert ein preimage. Daraus wird ein Hash, ein kurzer Prüfwert, berechnet. Er muss mit dem Zahlungs-Hash der Rechnung übereinstimmen; das zurückgegebene preimage dient somit als Nachweis des Zahlungsabschlusses. Eine Fehlerantwort verwendet error. Mit lookup_invoice lässt sich der Zustand abfragen. Die App muss das tatsächliche Ergebnis auswerten und darf nicht schon das Absenden einer Nachricht als Erfolg anzeigen. [1]

Anna tippt auf Bezahlen, doch die App erhält keine Antwort. Ein Timeout, das Ende der Wartezeit, sagt noch nichts über das Geld aus. NWC verwendet für Anfragen und Antworten flüchtige Events; ein getrenntes Relay oder ein unerreichbarer Dienst kann eine Nachricht verlieren. Verloren gegangen sein könnte aber nur die Antwort auf eine bereits ausgeführte Zahlung. Prüfen Sie zuerst den Zustand über lookup_invoice oder direkt in der Wallet. Schweigen bestätigt keinen Fehlschlag. Eine neue Anfrage ist nicht automatisch eine sicher wiederholbare Fassung derselben Aktion; zunächst muss deren Ergebnis geklärt werden. [1]

App und Wallet tauschen verschlüsselte Nachrichten aus. Bei der aktuellen Aushandlung wird nip44_v2 bevorzugt; das veraltete nip04 bleibt aus Kompatibilitätsgründen erhalten. Fehlt das encryption-Tag, gilt der ältere Modus. NIP-44 bietet allerdings keine forward secrecy, also keinen Schutz früherer Kommunikation bei einem später kompromittierten Langzeitschlüssel. Ein Relay kann außerdem Eventarten, Tags, öffentliche Verbindungsschlüssel und Zeitpunkte sehen. Für NWC sollte deshalb nicht der hauptsächliche Identitätsschlüssel verwendet werden, mit dem jemand auf Nostr veröffentlicht. Getrennte Schlüssel erschweren die Zuordnung von Zahlungen zu einem öffentlichen Profil, garantieren aber keine vollständige Anonymität. [1] [4]

Im Alltag müssen Sie keine Nachrichtennummern kennen, bei einer Integration sind sie jedoch wichtig. Info verwendet kind 13194, Anfragen 23194 und Antworten 23195. kind bezeichnet die Eventart. Das p-Tag benennt die Gegenseite, das e-Tag in der Antwort verweist auf die ursprüngliche Anfrage. Der Client prüft Signatur, erwarteten Dienstschlüssel, diese Zuordnung und result_type, den Befehl, zu dem das Ergebnis gehört. Irgendeine Nachricht vom Relay genügt nicht als Bestätigung. Sonst könnte eine fremde Antwort oder die Antwort auf eine andere Aktion als Ergebnis dieser Zahlung missverstanden werden. [1]