While Nostr is by no means a privacy protocol, it could bring potential improvements to Bitcoin privacy.

Nostr, short for “Notes and other stuff transmitted through relays,” is a new communication protocol developed in 2021 by Lightning Network developer fiatjaf, which evolved out of LNBits developer Ben Arc’s attempt at a fully-decentralized marketplace called Diagon Alley. As opposed to other communication solutions, which mostly function via dumb clients and smart servers, Nostr offers smart clients and dumb servers, which heightens censorship resistance for users.

In Nostr, all data is stored locally with users and merely distributed via relays, rather than stored on central servers, such as via Twitter. In the case of social media, Nostr increases censorship resistance, as users are enabled to fully own their own content and profiles. In light of recent controversies around Twitter’s censorship policies, users began migrating toward the federated communications solution Mastodon. However, in Mastodon, ownership over content and profiles lies with those running the Mastodon servers users signed up with. While federations such as Mastodon offer more censorship resistance than centralized servers — as users are able to simply sign up to another server when censored — criticism has arisen around potential censorship on Mastodon through server owners.

In December 2022, the Nostr community received a 14 BTC grant from Twitter Founder Jack Dorsey, which brought unprecedented attention to the protocol. As applications built on Nostr evolved, the mobile client Damus jumped to number one in social networking on the iOS app store in China, resulting in its ban. In an apparent effort to contain the #MarchOffTwitter, Twitter CEO Elon Musk shortly banned the publication of Nostr-related content, along with bans on other third-party platforms such as Instagram, but to no avail. 

While Nostr is not a privacy protocol per se — among other issues, clients by default leak users’ IP addresses to relays — the Nostr protocol could bring improvements to Bitcoin privacy.

Improving Privacy And Scalability Of BIP47

BIP47 is a Bitcoin Improvement Proposal to create reusable payment codes while protecting the privacy of users for recurring payments. Without BIP47, users need to tediously generate new addresses by hand to avoid address reuse. When a user reuses an address for transactions, the user enables anyone watching the blockchain to easily cluster all transactions belonging to the address reused and form a graph of the user’s payment history and net worth. The prevention of address reuse is therefore a privacy best practice in Bitcoin and already implemented in many Bitcoin wallets by default. However, when a user aims to establish recurring payments with another party, such as in a merchant-customer relationship, a frequent generation of new addresses can be inconvenient.

With BIP47, a customer can generate a set of addresses to use for payments for the merchant. If a customer purchases products monthly, the merchant would need to send the customer an address each month. With BIP47, the customer creates a dedicated payment code for the merchant, which functions similarly to an extended public key. This allows the customer to automatically generate new addresses for the merchant, instead of the merchant needing to create addresses for the customer.

BIP47 makes use of notification addresses, which are monitored by HD wallets for outputs. In a notification transaction, the merchant sends the customer a blinded public key and chain code via the OP_RETURN field, together with a shared secret to keep the shared addresses private on the public blockchain. This exchange creates several issues due to the architecture of the Bitcoin network. The first two are economic: A notification transaction consists of 80 bytes, which can become expensive for users when fees on the Bitcoin network are high. Notification transactions, in addition, create unsendable outputs, which bloat the UTXO set over time. This increases the computing load on Bitcoin nodes who, at the time*, need to store the entire UTXO set, meaning every Bitcoin output that has not been used as a new input to ensure the validity of transactions.

A notification transaction creates so-called toxic change. When a user receives change from a notification transaction and spends the change to a third party, anyone watching the blockchain is able to correlate the user’s recurring payments to their non-recurring payments, even when addresses are not reused. A notification address also only exists once for each wallet. If a merchant wanted to establish recurring payments with 10 customers, anyone watching the blockchain is able to gain insight into the merchant’s customer base, as 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 could be exchanged via Nostr. As opposed to other communication methods, Nostr is suitable for the exchange of BIP47 payment codes as no central authority exists to potentially censor the exchange of messages. At the same time, all direct messages on Nostr are encrypted by default, eliminating the need to compute shared secrets. By making use of BIP47 via Nostr, users can avoid the creation of UTXO set bloat via unspendable outputs and eliminate the correlation of recurring versus non-recurring payments as well as the publication of customer bases through the avoidance of toxic change and the re-use of notification addresses.

*Note: Storing the entire current UTXO set for Bitcoin nodes may potentially be eliminated in the future via the implementation of UTreeXO, which shifts the burden of proving that a transaction spends a valid UTXO to the owner of the UTXO, reducing the storage requirements from gigabytes to kilobytes.

Nostr Pay-To-EndPoint

In Bitcoin, blockchain analysis services operate the heuristic of “common input ownership” to map transactions to identities. Within this heuristic, a transaction containing different public keys used as inputs is classified as belonging to one person. Due to its UTXO-based architecture, through which inputs and outputs of transactions are linked, the Bitcoin protocol is also prone to subset sum analysis. In subset sum analysis, adversaries are able to calculate the probability of inputs and outputs belonging to the same entity, even when different public keys are used as inputs to one transaction. For example, if a transaction has inputs of 1, 4, 7, 23 and 6, and outputs of 5 and 36, it can be deduced that input 1 and 4 and inputs 7, 23 and 6 belong to the same entity.

Pay-to-EndPoint (P2EP) is a privacy-preserving reinvention of Satoshi Nakamoto’s Pay-to-IP (P2IP) coded into the original Bitcoin client. One form of a P2EP transaction are PayJoins, which are transactions designed to break the common input ownership heuristic. In a PayJoin transaction, both the sender and the receiver contribute inputs to a transaction to break the common input heuristic. With PayJoins, users exchange information about what UTXOs will be used as inputs via any communication channel, such as a Tor Onion, which functions as the end point, to construct a partially-signed bitcoin transaction (PSBT). Once both parties have agreed to the terms and signed the transaction, a PayJoin transaction looks just like any other Bitcoin transaction on chain. Because involved parties act as both sender and receiver, a PayJoin transaction breaks the common ownership heuristic as well as subset sum analysis: parties may contribute inputs of 3 and 5, while the transaction generates outputs of 6 and 2.

The problem: PayJoin transactions are complicated to coordinate, as participants have to be online at the same time when using a clearnet domain or Tor Onion endpoints. If a user initiates a P2EP transaction and, for example, closes their computer or otherwise disturbs network connectivity, the transaction cannot be communicated. In Nostr, communication is asynchronous: users fetch information from relays once network connectivity is restored. By using Nostr keys instead of Tor Onions as endpoints for P2EP transactions, P2EP transactions could be coordinated more easily.

Another implementation of P2EP is the much-debated LNURL. With LNURL, instead of tediously needing to generate new invoices for each transaction, users are able to receive a static endpoint pointing at a web server to automatically generate new invoices. However, because web servers are reliant on the global Domain Name Service (DNS), users of LNURL inevitably reveal their identity to the hosting provider, as well as their IP address to payees if no proper precautions are taken. Wide adoption of LNURL would therefore be a detriment to the pseudonymity of the Lightning Network. Instead of using a web server as the endpoint for LNURL, users could use Nostr keys as endpoints for LNURL transactions to conceal their identities.

Nostr For CoinJoins

While a PayJoin is great to break the common ownership heuristic as well as subset sum analysis, PayJoins are unable to offer privacy to both sender and receiver toward the cooperating party. PayJoins are essentially two-party CoinJoins, limited to two participants — this means that both sender and receiver are aware of their own inputs and outputs, leaving the inputs and outputs of their partner identifiable. Unless a PayJoin is facilitated with CoinJoined transactions, users risk revealing their wallet balances as well as past and future transactions to their PayJoin partners.

In anonymous-amount credential systems such as Wasabi Wallet’s protocol for CoinJoin coordination, WabiSabi, Nostr keys can function as communication endpoints for the coordination of a CoinJoin transaction. This enables the sender and receiver of a CoinJoin transaction to exchange the credentials needed to participate in CoinJoin rounds, essentially enabling a form of discreet payments within a CoinJoin. With the use of Nostr keys as endpoints in CoinJoins, cooperating parties remain unaware of their counterparties’ balances and transactions by hiding in the crowd. At the same time, using Nostr keys as endpoints for CoinJoin transactions helps PayJoin users save on fees by facilitating payments directly within the CoinJoin, rather than CoinJoining to facilitate the payment after.

Another use for Nostr in CoinJoins lies in the discovery of coordinators. While most CoinJoin coordinators run behind Tor to obscure the identity of CoinJoin participants, users are currently unable to easily discover new coordinators to join with the exception of JoinMarket, a CoinJoin marketplace targeted toward more advanced CoinJoin users. While CoinJoin users are able to add custom coordinators to Wasabi Wallet — a trivial task as easy as exchanging a URL in the backend — no way exists to automate the process of updating coordinators due to the lack of a platform for publication. Instead, to discover new coordinators, users must search social media and forums, such as Reddit or Twitter, to add coordinators manually. However, the publication of a coordinator service via social media or forums may pose a risk to coordination providers depending on the policies applied to the service, as certain pages may easily be shut down.

If Tor is an anonymous remailer, meaning a protocol facilitating the anonymous forwarding and receiving of messages between peers, Nostr can function as an anonymous bulletin board. CoinJoin coordinators can publish their services via a Nostr event type, and CoinJoin wallets can be enabled to automatically pull from those relays to display within their clients. The broadcasting of coordinator servers via Nostr, such as facilitated via BTCPay’ Servers CoinJoin plugin and proposed in the Lightning-enabled CoinJoin software Vortex, can eliminate the need to manually search for and add CoinJoin coordinators in CoinJoin clients, helping to further decentralize the CoinJoin coordination landscape.

Circumventing IP Requirements With NOSTR

As touched upon previously, the Nostr protocol was originally conceptualized to realize a fully-decentralized marketplace called Diagon Alley. As the Nostr protocol evolved, Diagon Alley became the LNbits extension NostrMarkets: a Nostr-native marketplace which enables merchants and customers to run and interact with online shops via relays. In NostrMarkets, customers can subscribe to a merchant’s public key to fetch products from relays instead of accessing a merchant’s site via a webshop. This increases the censorship resistance of online shops, as merchants are not dependent on seizable websites — rather, a merchant’s shop is hosted with all relays the shop sets up to communicate with. Even if the merchant’s server were to be seized, its shop could easily be set up at a different location, as all products are stored with relays on the Nostr network. NostrMarkets handles order and payment coordination via encrypted Nostr direct messages, while payments are facilitated through the Lightning Network.

In addition to its censorship resistance, the LNbits extension NostrMarkets enables fully-anonymous marketplaces. Instead of exposing a merchant’s IP to the whole world, both merchants and customers only reveal their IPs to the relays they connect to, which can easily be mitigated by running a client or shop behind Tor. As an upside to fully running a shop behind Tor, which makes a shop only accessible via the Tor browser and .onion web pages, NostrMarkets can run in any web browser or smartphone, improving the user experience of privacy-preserving, client-server communications. Because payments are negotiated via encrypted Nostr direct messages and facilitated via the Lightning Network, payments in NostrMarkets remain comparatively private as long as the shop’s Lightning node runs behind Tor, as a payment coordination direct message is indistinguishable from other direct messages in Nostr.

Another way to circumvent the requirement of IP addresses in server client communication is NOSTREST. REST, short for “representational state transfer,” is part of the software architecture of the world wide web, used to facilitate communication between servers and clients via GET, POST, PUT, DELETE and PATCH requests. But, when a client sends a REST request to a server, IP addresses are revealed, potentially revealing personally-identifiable information. On GitHub, __escapee__ proposed a REST API bridge built on Nostr, called NOSTREST. By using Nostr keys without identification headers, both users and server operators do not need to know the IP addresses of their counterparts. A NOSTREST implementation can therefore improve the privacy of Bitcoin applications using REST as servers do not need the clients’ IP addresses.

One such example could be the running of custodial Chaumian e-cash mints, a form of anonymous-amount credential systems. In an e-cash mint, the mint operator does not know the balances or value exchanged by its users. However, due to the current architecture of REST, it does learn the user’s IP address unless running behind Tor by default, such as in the e-cash system Cashu. But implementing and managing Tor support is tedious. With the NOSTREST bridge, projects can easily preserve the privacy of their users. By running an e-cash mint behind Tor using NOSTREST to communicate between server and clients, communication can be facilitated asynchronously, while both server operator and user only learn each other’s public keys, eliminating the risk of identification via IP.

This is a guest post by L0la L33tz. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.