Silent Payments notifications via Nostr

The discussion focuses on a method for sending notifications for incoming Silent Payments transactions through Nostr, building upon the concept of stealth addresses using Nostr. Silent Payments are introduced as a novel, non-interactive way to receive payments, where the sender knows the transaction details, but the receiver must search for their specific transactions among many. The necessity arises for a mechanism to notify the receiver (Bob) when a payment has been sent by the sender (Alice), without requiring Bob to check every transaction. A proposed solution involves Alice notifying Bob with at least the transaction ID (txid), and ideally additional information like the tweak used in the transaction and an optional confirming blockhash or height to facilitate Bob's verification process.

The schema for such notifications is laid out, suggesting a JSON format that includes the txid, tweak, and an optional blockhash. This format would allow Bob to efficiently locate the transaction and verify its relevance to him. Furthermore, the use of Nostr as a communication layer for these notifications is examined. The potential privacy implications of different approaches to sending and receiving these notifications via Nostr are discussed, including the choice of keys used by Bob to receive notifications, to mitigate the risk of metadata leakage that could affect privacy.

The design also considers the practicalities of implementing this notification system, highlighting the necessity for Alice and Bob to share at least one common Nostr relay to ensure notifications are received. It suggests a final design where Bob advertises his Silent Payment address along with optional tags for his public key (npub) and a list of recommended relays. This approach aims to streamline the process, reducing the scanning time required by Bob to identify relevant transactions.

Additionally, the write-up touches on potential issues such as spam prevention and the challenges posed by incorrect implementation, particularly regarding the provision of correct tweaks in notifications. It concludes with reflections on the broader implications of integrating Silent Payments with stealth address concepts and the usability improvements offered by this design, referencing discussions from a previously posted Gist and summarizing concerns raised therein, including spam prevention strategies and the handling of incorrect tweak information. The overall aim is to enhance the user experience by reducing the need for exhaustive scanning while maintaining privacy and security within the framework of Silent Payments and Nostr communication.