Bitcoin

Nostr Wallet Connect: Bitcoin Application Collaboration Layer

The future of Bitcoin adoption and development has one of the most important hurdles developers will have to deal with: software interaction issues called compatibility. As applications and protocols in this space become more complex and feature-rich to meet the needs of real users and use cases, this fundamentally presents a dilemma that has two real answers. An application or wallet must internally integrate all protocols and functions necessary to meet its purpose requirements. Otherwise, different applications must be able to communicate with each other.

One example of where this issue occurs is integrating Lightning into various applications and software tools. Lightning is a very complex protocol stack to implement, with numerous subprotocols that specify how to coordinate and handle updates to Lightning channel state. This includes the transaction structure for each channel state and what it enforces, the order in which each step of creating and signing a new transaction is performed to ensure the safety of user funds, and the block to automatically react in the appropriate way when: Includes the ability to monitor the chain. Invalid states are submitted to the blockchain.

This is too complex for a single application developer to integrate directly into his or her project. If it’s too much effort, the obvious conclusion is that you can simply rely on ready-made software that handles Lightning implementation issues and build an application that communicates with that external software. This leads to the next problem. What happens if your application users don’t use a particular Lightning implementation or wallet?

Even with the app’s functionality outsourced, the development team still hasn’t completely escaped the complexity problem. While there is no need to fully implement Lightning on their own, developers who take this route will now have to deal with integrated API support for every Lightning wallet that could potentially be used by users of their application. This requires keeping up with changes to the different Lightning wallets, their APIs, how their internals work, and what features they support. Failure to keep up with changes to a particular wallet may result in application disruption for users of that wallet.

Some standardized mechanism needs to exist for the software on both sides of this gap to be able to implement one thing that allows all these different tools to talk to each other. This allows each application developer and each Lightning wallet developer to simply integrate and maintain one single protocol that allows their applications to communicate with each other.

Nostr Wallet Connect is a protocol that attempts a truly generalized mechanism to meet this need. When we tried to include Lightning payments in Nostr, we ran into all these complexities that came up in how we did it.

Lightning and NWC

The team behind Amethyst, a Nostr client, and Alby, a web-based Lightning wallet, created NWC to solve the problem of Nostr users looking to integrate Lightning into their Nostr experience without using a special-purpose wallet. The application/protocol is based on Nostr’s identity architecture, where every message (event) sent through Nostr is signed by a cryptographic key pair that acts as your identity in Nostr. This allows your application to simply generate a Nostr key pair, and with that alone you have a cryptographic authentication mechanism that will be used to communicate with external Bitcoin wallets to perform your app’s functions.

After you register an external application with your Lightning wallet using a key pair, your application can now ping your wallet to initiate payments. This specification currently supports BOLT 11 invoice payments, key transfer payments (invoiceless payments on the node’s public key), simultaneous payments of multiple invoices, creating invoices to pay to others, and several other features that allow payment history and payments. do. Query your wallet balance from an external application.

All of this is coordinated through Nostr, allowing a highly redundant means of communication that does not rely on a single central messaging mechanism, or users who have to rely on complex software such as Tor or other protocols to facilitate network connectivity between their applications and wallet software. do. Or infrastructure running on your home network. Nostr also supports encrypted direct messages. This means that the communication between your wallet and the application is completely private and no details about the payments being coordinated to the Nostr relay used for communication are revealed.

The wallet side of the NWC bridge can implement security restrictions to prevent external applications from gaining unrestricted access to wallet funds if the Nostr key used to communicate with the wallet is compromised. Limits on how much you are allowed to spend and how often you make payments can be configured on the wallet side of the connection.

NWC is useful for more than just integrating Lightning into Nostr applications. As a protocol, the entire design philosophy of Nostr itself has been focused on keeping it simple enough that any developer can easily and correctly implement the entire protocol with minimal time and resources. Non-Nostr-related applications can easily integrate NWC or similar protocols with little overhead or complexity, solving the fundamental problem of how to connect a Bitcoin wallet to their application without having to build it directly into the app.

beyond lightning

The potential for protocols like NWC to provide tremendous value to wallet and application developers goes beyond integrating Lightning wallets into special-purpose applications. Rather than some amazing fundamental innovation that no one has realized yet, the entire long-term direction of interacting with Bitcoin is towards a protocol for interaction between multiple users.

Multi-party coin pools are a perfect example. Many of the specific design proposals, such as Ark or Timeout trees, are built around a central coordinating party or service provider, which could easily facilitate a means of passing messages between user wallets, but this hinders the design space due to single points of failure. If 100 users are in a coinpool together on top of a single UTXO, the security model is based on a pre-signed path that allows each user to unilaterally withdraw coins from the chain. This mechanism can be implemented to ensure that funds are not lost if the coordinator fails or disappears, but this is the most efficient way to handle the worst-case scenario.

If we can find a mechanism that allows users to communicate with each other without a service provider or coordinator, we can achieve much more efficient on-chain exits by using larger group multi-signatures to transfer funds to other places much more efficiently (and thus more cheap) on-chain space. NWC and Nostr are perfectly suited to this scenario.

Collaborative multi-signature wallets between multiple parties can also benefit from these protocols. When combined with standards like PSBT, the simple Nostr communication mechanism can greatly simplify the complexities of various wallets through multi-signature support that coordinates transaction signatures in a seamless and user-friendly manner.

Discreet Log Contracts (DLC) are another surprising use of these protocols. The entire DLC scheme relies on both parties having access to the oracle signature to properly terminate the contract unilaterally if the two parties do not work together to resolve the contract. Nostr is the perfect mechanism for oracles to broadcast these signatures, allowing a simple subscription to Nostr keys in a user’s wallet to automatically track and obtain signatures as oracles broadcast them.

Over time, as more applications and protocols are built on top of Bitcoin that require interaction between users and between different applications, there will be a pressing need for a universal communication mechanism that facilitates this without relying on a single point of failure. . .

Nostr is the perfect baseline protocol to facilitate this, given its incredible simplicity and the redundancy of the large set of relays it can leverage. NWC is a perfect example of a workable solution.

Related Articles

Back to top button