Nostr's Privacy Paradox and Improvements to Bitcoin Privacy

Although Nostr is not a privacy protocol, it may bring potential improvements to Bitcoin's privacy.

Original title: "THE NOSTR PRIVACY PARADOX"

Written by: Wendy

Compilation: DAOrayaki

Nostr, which stands for "notes and other content transmitted through relays", is a new communication protocol developed by Lightning Network developer fiatjaf in 2021. It is a complete communication protocol called Diagon Alley by LNBits developer Ben Arc. Attempts to decentralize marketplaces evolved. Unlike other communication solutions, most of which work through dumb clients and smart servers, Nostr provides smart clients and dumb servers, thus increasing users' resistance to censorship.

In Nostr, all data is stored locally on the user and only distributed through relays, rather than being stored on a central server like Twitter. In the case of social media, Nostr adds censorship resistance because users have full ownership of their content and profiles. In light of the recent controversy surrounding Twitter's censorship policies, users are migrating to federated communications solution Mastodon. In Mastodon, however, ownership of content and profiles rests with the operator of the Mastodon server on which the user is registered. While a federated system like Mastodon offers more resistance to censorship than a central server, since users can simply register to another server if they are censored, there have been criticisms that Mastodon may enforce censorship through the server owner .

In December 2022, the Nostr community received funding of 14 BTC from Twitter founder Jack Dorsey, which brought unprecedented attention to the protocol. As apps built on Nostr continued to grow, the mobile client Damus ranked #1 in the social networking category of the Chinese iOS app store and was banned as a result. In an effort to curb the #MarchOffTwitter movement, Twitter CEO Elon Musk quickly banned Nostr-related content and banned other third-party platforms such as Instagram, without success.

Although Nostr itself is not a privacy protocol — by default, clients leak users’ IP addresses to relayers — the Nostr protocol could potentially improve Bitcoin’s privacy.

Improve the privacy and scalability of BIP47

BIP47 is a Bitcoin Improvement Proposal to create reusable payment codes for recurring payments while protecting user privacy. Without BIP47, users would need to painstakingly generate new addresses manually in order to avoid address reuse. When a user reuses an address for transactions, anyone observing the blockchain can easily aggregate all transactions belonging to that address, forming a graph of the user's payment history and net worth. Therefore, in Bitcoin, preventing address reuse is a privacy best practice and is already implemented by default in many Bitcoin wallets. However, frequent generation of new addresses may be inconvenient when a user is attempting to establish a recurring payment relationship with another party, such as between a merchant and a customer.

Through BIP47, customers can generate a set of payment addresses for merchants. If the customer purchases products every month, the merchant needs to send an address to the customer every month. With BIP47, the customer creates a dedicated payment code for the merchant, similar to an extended public key. This allows the customer to automatically generate a new address for the merchant without requiring the merchant to create an address for the customer.

BIP47 uses notification addresses, which are monitored by HD wallets for outputs. In a notify transaction, the merchant sends the customer the blinded public key and chaincode via the OP_RETURN field, along with a shared secret key used to keep the shared address private on the public blockchain. Due to the architecture of the Bitcoin network, this exchange creates several problems. The first two problems are economic: a notification transaction consists of 80 bytes, which can become expensive for users when transaction fees on the Bitcoin network are high. Additionally, notification transactions create unsendable outputs, bloating the UTXO set over time. This increases the computational load on Bitcoin nodes as they currently need to store the entire set of UTXOs, i.e. every Bitcoin output that is not used as a new input to ensure a transaction is valid.

Notifying transactions creates what is known as "poisoned change". When a user receives change from a notification transaction and pays it to a third party, anyone observing the blockchain will be able to correlate the user's recurring payment with a non-repeating payment, even if the address is not reused. A notification address only exists once per wallet. If a merchant wishes to have recurring payment relationships with 10 customers, anyone observing the blockchain will be able to learn about the merchant's customer base, since all 10 customers would need to create notification transactions for the merchant to the same notification address.

Instead of using notification transactions to exchange payment codes between merchants and customers, payment codes can be exchanged through Nostr. Unlike other communication methods, Nostr is suitable for exchanging BIP47 payment codes because there is no central authority that could censor message exchanges. At the same time, all direct messages on Nostr are encrypted by default without computing a shared secret. By using BIP47 through Nostr, users can avoid creating bloat for the UTXO set with unspendable outputs, delink double-spends from non-duplicative spends by avoiding toxic change and reuse of notification addresses, and by avoiding exposing clients base to eliminate the release of the customer base.

*Note: By implementing UTreeXO, the need for Bitcoin nodes to store the entire current set of UTXOs may be eliminated in the future. UTreeXO shifts the burden of proving whether a transaction uses a valid UTXO to the owner of the UTXO, reducing storage requirements from a few GB to a few KB. *

Nostr Pay-To-EndPoint

In Bitcoin, the blockchain analysis service maps transactions to identities using the "common input ownership" heuristic. According to this rule, transactions containing different public keys as input are classified as belonging to the same person. The Bitcoin protocol is also susceptible to subset summation analysis due to its UTXO-based architecture whereby the inputs and outputs of transactions are correlated. In subset-sum analysis, an attacker is able to calculate the probability that an input and an output belong to the same entity, even if different public keys are used as inputs to a transaction. For example, if a transaction has inputs 1, 4, 7, 23, and 6 and outputs 5 and 36, it can be inferred that inputs 1 and 4 and inputs 7, 23, and 6 belong to the same entity.

Source: Knowledge Discovery in Cryptocurrency Trading: A Survey, 2021 by Xia Fan Lu and Xin-Jiang Jang

Pay-to-EndPoint (P2EP) is a privacy-preserving redesign of Satoshi Nakamoto's Pay-to-IP (P2IP), encoded into the original Bitcoin client. One form of P2EP transactions is the PayJoin transaction, designed to break the heuristic rule of joint input ownership. In a PayJoin transaction, both the sender and receiver provide inputs to break the common input heuristic. Using PayJoins, users can exchange information about UTXOs to be used as inputs to construct Partially Signed Bitcoin Transactions (PSBTs) via any communication channel (such as Tor Onion as an endpoint). Once both parties agree to the terms and sign the transaction, the PayJoin transaction looks like any other Bitcoin transaction on the blockchain. Since the parties involved play both the roles of sender and receiver, the PayJoin transaction not only breaks the co-ownership heuristic rule, but also breaks the subset-sum analysis: the parties can provide inputs of 3 and 5, and the output generated by the transaction for 6 and 2.

Source: Pay To EndPoint by Adam Fiscor, 2018

Problem: Coordination of PayJoin transactions is rather complex, as participants must be online at the same time, whether using clearnet domains or Tor Onion endpoints. If a user initiates a P2EP transaction, for example by turning off their computer or losing their network connection, the transaction cannot communicate. In Nostr, communication is asynchronous: users get information from the relay after the network connection is restored. It is easier to coordinate P2EP transactions by using Nostr keys instead of Tor Onion as the endpoint for P2EP transactions.

Another implementation of P2EP is the controversial LNURL. With LNURL, instead of tediously generating new invoices for each transaction, users can receive a static endpoint pointing to a web server to automatically generate new invoices. However, because web servers rely on the global Domain Name Service (DNS), users using LNURL inevitably reveal their identities to hosting providers and, if proper precautions are not taken, their IP addresses to payees. Widespread adoption of LNURL will be detrimental to the anonymity of the Lightning Network. Instead of using a web server as the end point for LNURL transactions, users can use Nostr keys as the end point for LNURL transactions to hide their identities.

Nostr for CoinJoin

While PayJoin breaks co-ownership heuristics and subsetting and analysis nicely, PayJoin fails to provide sender and receiver with privacy protection from collaborating parties. PayJoin is essentially a two-party CoinJoin, limited to two participants, meaning that both the sender and receiver know their own inputs and outputs, making their partners' inputs and outputs identifiable. Unless a CoinJoined transaction is used to facilitate PayJoin, users risk revealing their wallet balances and past and future transactions to PayJoin partners.

In an anonymous amount certificate system like Wasabi Wallet's CoinJoin coordination protocol (WabiSabi), the Nostr key can serve as the communication endpoint for coordinating CoinJoin transactions. This allows the sender and receiver of a CoinJoin transaction to exchange the credentials required to participate in a CoinJoin round, enabling a discrete form of payment in CoinJoin. By using the Nostr key as the endpoint in CoinJoins, the collaborating parties remain hidden from the crowd and remain ignorant of their counterparty's balances and transactions. At the same time, using Nostr keys as the endpoint of CoinJoin transactions helps PayJoin users save fees by making payments directly in CoinJoin instead of facilitating payments through CoinJoin.

Another use of Nostr in CoinJoins is coordinator discovery. While most CoinJoin coordinators operate behind Tor to mask the identities of CoinJoin participants, users currently cannot easily discover new coordinators, except on JoinMarket (a CoinJoin marketplace for more advanced CoinJoin users). While CoinJoin users can add custom coordinators to Wasabi Wallet (as easy as exchanging URLs in the background), there is no way to automate the process of updating coordinators due to the lack of a publishing platform. Therefore, in order to discover new coordinators, users must manually search social media and forums (such as Reddit or Twitter) to add coordinators. However, posting a Coordinator service via social media or forums may pose a risk to the Coordination Provider, depending on the policies applied to the service, as some pages may be easily shut down.

If Tor is an anonymous relay server, a protocol that facilitates anonymous forwarding and receiving of messages between peers, Nostr can act as an anonymous bulletin board. CoinJoin coordinators can publish their services via the Nostr event type, and CoinJoin wallets can be enabled to automatically fetch information from these relay servers and display it in their clients. Broadcasting coordinator servers by Nostr, such as via BTCPay's Servers CoinJoin plugin and the approach proposed in Lightning Network-based CoinJoin software Vortex, can eliminate the need to manually search for and add CoinJoin coordinators in CoinJoin clients, further decentralizing the CoinJoin coordination landscape .

Bypass IP requirements via NOSTR

As mentioned before, the original concept of the Nostr protocol was to implement a fully decentralized marketplace called Diagon Alley. With the development of the Nostr protocol, Diagon Alley became LNbits' extension NostrMarkets: a Nostr-enabled marketplace natively enabling merchants and customers to run and interact with online stores through relays. In NostrMarkets, customers can subscribe to the merchant's public key and get products from the relay instead of visiting the merchant's website through the webshop. This increases the censorship resistance of the online store because instead of relying on a censorable website, the merchant's store is hosted by all the relays it communicates with. Even if the merchant's server is seized, the store can easily be set up in different locations, because all products are stored on the relay on the Nostr network. NostrMarkets handles order and payment coordination via encrypted Nostr Direct Messages, while payments are made via the Lightning Network.

In addition to being censorship-resistant, LNbits' extension NostrMarkets enables a fully anonymous market. Merchants and customers don't expose their IP addresses to the world, only to the relay they connect to, and this can be easily resolved by running the client or store behind Tor. The advantage of running the store entirely behind Tor is that the store can only be accessed through the Tor browser and .onion web pages, NostrMarkets can run on any web browser or smartphone, improving the user experience with privacy-preserving client-server communication. Since payments are negotiated via encrypted Nostr Direct Messages and implemented via the Lightning Network, payments in NostrMarkets will remain relatively private as long as the store's Lightning node is running behind Tor, as payment coordination Direct Messages are incompatible with other Direct Messages in Nostr distinguish.

Another way to bypass the IP address requirement in server-client communication is NOSTREST. REST stands for "Representational State Transfer," and it's part of the software architecture of the worldwide Web for communication between servers and clients via GET, POST, PUT, DELETE, and PATCH requests. However, when a client sends a REST request to a server, the IP address is exposed, potentially revealing personally identifiable information. On GitHub, __escapee__ proposed a REST API bridge built on top of Nostr called NOSTREST. By using Nostr keys without an authentication header, users and server operators do not need to know each other's IP addresses. Therefore, the implementation of NOSTREST can improve the privacy of Bitcoin applications using REST, since the server does not require the client's IP address.

An example of this could be running a custodial Chaumian e-cash mint, an anonymous voucher system for amounts. In an e-cash mint, the mint operator does not know its users' balances or the value of the exchange. However, due to the current REST architecture, unless running behind Tor by default (eg in the e-cash system Cashu), it knows the user's IP address. However, implementing and managing Tor support is cumbersome. Through the NOSTREST bridge, the project can easily protect the privacy of users. By running the e-cash mint behind Tor and using NOSTREST to communicate between the server and client, asynchronous communication can be achieved, while the server operator and user only know each other's public key, eliminating the need for identification by IP risk.