Silent Payments notifications via Nostr

The discussion revolves around the intricacies of implementing a minimal approach in transaction identification and verification within a blockchain context, focusing on the utility and limitations of using transaction identifiers (txids) and taproot outputs. The conversation begins with an acknowledgment of the challenges that light clients face when they rely solely on filters and block pulling to locate a specific transaction using its txid. It is suggested that employing taproot output as opposed to merely txid could offer a more efficient method for scanning via regular block filters, although the concept of txid filters is also recognized as a theoretical possibility.

The dialogue then transitions into the realm of trust dynamics, particularly highlighting the Web of Trust (WoT) model where the probability of Denial of Service (DoS) is relatively low. This model allows for a scenario where a receiver, referred to as Bob, can obtain the transaction data from any source he trusts without needing the scripts of the inputs, provided he has the necessary tweak. This raises a broader point about the extent to which transactions should be verified if the sender is trusted. If the trust in the sender is absolute, there is no need to fetch additional data from external sources, since the sender can provide all that is necessary for spending the output. This perspective is further elaborated through a linked post, which underscores the potential for enhancing client design flexibility.

However, skepticism is expressed regarding the reliance on a Web of Trust due to the current lack of a robust and reliable system to support such a framework. This skepticism extends to the strategy of timing notifications related to transactions, particularly whether a sender, referred to as Alice, should wait for transaction confirmation before alerting the recipient. The preference from Alice's standpoint for immediate notification is acknowledged, but the broader implications for protocol design, depending on whether waiting for confirmation is deemed necessary, are considered critical for practical implementation. The conversation suggests a cautious approach towards protocol development, emphasizing a well-informed understanding of client design possibilities before committing to flexible solutions.