Introducing Ghost Addresses

Today, we’re thrilled to announce our latest innovation on the Lightning Network: Ghost Addresses. This means that anyone running their own lightning node will be able to have a Lightning Address without needing a custodial third party and without needing a publicly accessible server. The days of using custodial wallets or other centralized intermediaries are over. You can seamlessly receive spontaneous payments directly to self-custody.

At a time when the centralized options are becoming fewer and regulation seems to be tightening, we, as bitcoiners, have to build the self-custodial alternative and make it compelling. Custodial services often have great user experiences, but are central points of failure.

✨ Anyone running their own lightning node will be able to have a Lightning Address without needing a custodial third party and without needing a publicly accessible server.

Standing on the Shoulders of Giants

The concept behind a Ghost Address may seem simple, but the impact will be great because of how it advances the goal of removing trusted intermediaries. We also must acknowledge that we are standing on the shoulders of giants—our innovation is leveraging incredible work by others who came before us.

LNURL

One of the key user experience challenges for lightning is handling invoices. With BOLT 11, a new invoice is required for each payment. This drudgery was drastically reduced with the introduction of LNURL, simplifying the process of receiving payments. As the name suggests, LNURL provides a URL that will generate an invoice based on information provided by the payer, eliminating the manual back and forth between payer and payee.

Lightning Addresses

LNURL was followed by the development of Lightning Addresses by André Neves of ZBD. This introduced an intuitive, email-like format for transactions, making the network more accessible to newcomers.

Phantom Nodes and Payments

Elsewhere, the Lightning Dev Kit team introduced the concepts of both Phantom Nodes and Phantom Payments. This development in 2022 was a significant technological advancement aimed at improving load balancing between enterprise lightning nodes. Applying Phantom Nodes and Payments enhances an enterprise's capability to handle high-volume payments and offers more sophisticated routing options.

Introducing the Ghost Address

The Ghost Address is Amboss’ latest innovation, which combines the clever behavior of Phantom Payments with the user experience of the Lightning Address. In combination, a Ghost Address enables any node to receive payments through invoices created using the Lightning Address protocol.

Invoices generated from a Ghost Address use Phantom Payments to allow the destination to intercept routed payments.

The result: a method of invoice creation that enables a lighter-weight solution to receive money. A Ghost Address functions as a static, reusable endpoint that makes receiving payments into self-custody seamless and straightforward.

Getting Started with Ghost Addresses

Getting started is simple and shouldn't take more than a couple minutes.

1. Update Thunderhub to a Ghost enabled version (>0.13.29).
2. Claim your Ghost Address by going to the Amboss tab in Thunderhub.

Your own Lightning Address!

You can now use your new lightning address <username>@ghst.to to receive payments directly to your node!

👻 BONUS - You can enable notifications in Amboss to get a message every time you receive a payment!

Behind the Scenes: How Does a Ghost Address Work?

The following diagram gives a sense of what is happening behind the scenes but we will explain in more detail below.

A Spooky Level of Detail About Phantom Payments

When a payer wants to pay to a Ghost Address, they will make a GET request to the ghst.to server, which provides a BOLT 11 lightning invoice.

The destination in the invoice will be a Phantom Node, which technically does not exist. Since the invoice destination does not exist in the network graph, Amboss will include a route hint in the invoice, which directs the payer to route the payment to the payee’s node and through a specific phantom channel.

The phantom channel is a clue to the payee that the payment that they would otherwise route is instead intended for them. This triggers the payee node to request the preimage from the Amboss API. Using the preimage, the payee node can intercept the payment destined for the phantom node and claim the payment for themselves.

⚠️ As a result of this novel behavior, a node may not register the payment as a normal transaction since it is an intercepted payment forward. This means that as a payee you will not be able to see these payments in your invoices or payments but will instead see the node's balance increase.

Client-side Code

For Ghost payments to work there needs to be client-side code that connects to a Lightning node and intercepts forward requests.

ThunderHub

We’ve added about 40 lines of code to the latest release of Thunderhub (>0.13.29) that enables a node to receive payments to their Ghost Address.

Other Lightning Implementations (CLN, LDK)

Receiving payments made to a Ghost Address is possible using any implementation using a similar methodology as designed for Thunderhub (LND). As with most of our products, we’ve built the client portion into Thunderhub as a reference implementation that is available under an MIT open-source license.

Ghost Address Privacy

Ghost Addresses are intended to replace custodial lightning addresses. In the custodial lightning address scenario, a wallet will generate a lightning invoice using the lightning address standard and then receive the lightning payment. Optimally, the user would then transfer the bitcoin to self-custody. Consequently, a custodial wallet provider would know the amount of the payment, receive payment proof, and see subsequent withdrawals or other payments.

Payments made to a Ghost Address use invoices that Amboss generates, which reveal the amount of a payment. Amboss then serves the preimage to the generated invoice upon authenticated request. This process does not provide proof of payment. Additionally, Amboss will not know about subsequent withdrawals or other payments. When viewed in this context, receiving a payment to a Ghost Address will be far more private than using a custodial Lightning Address.

To improve privacy further while maintaining the payer user experience, a self-hosted, publicly accessible Lightning Address server would be required. Any lightning address server used in this way requires an invoice macaroon from the node, which increases the attack surface for a node.

Not a Panacea

While we’re excited to deliver this upgrade, it won’t solve all the pains of Bitcoin or the Lightning Network. Using a Ghost Address will improve invoice-handling for users. Receiving a lightning payment will still require ample spare capacity (inbound liquidity) for a successful payment. To ensure your node has enough capacity, try Hydro to automatically grow your node’s capacity and improve payment reliability.

Improvements Over Existing Approaches

Existing methods of providing Lightning Addresses, such as the HODL invoice approach championed by Zeus Wallet, represent important steps in the network's evolution, even if they are not without their limitations. These approaches have occasionally led to protracted payment states and force closures, which can be costly for minor transactions. Such technical challenges have been at the center of vigorous industry debate.

Faced with the risk of force closures, some wallets have taken the position of censoring payments to destinations that use HODL invoices. We believe in adopting a more constructive path forward. Our implementation of Ghost Addresses improves upon these early methods, ensuring transactions are immediate, not left in limbo, thereby enhancing the user experience and maintaining a higher standard of conduct within the Lightning Network community.

Troubleshooting and Future Work

In the interest of delivering these features to the network at the speed of lightning, there are a couple of known issues that may cause difficulty for new users:

1. Circuitbreaker currently causes conflicts with the Ghost Address subscription in Thunderhub. There can only be one active subscription to a node's forward request interceptor and the Circuitbreaker subscription will prevent the Ghost Address from working properly.
2. As documented in the LDK announcement, Phantom Payments are incompatible with Multi-Path Payments (MPP). Consequently, some wallets (e.g. Strike) may not be able to send to Ghost Addresses.
3. Most nodes aren’t yet equipped to track payments to a Ghost Address from an accounting perspective. In future work, logging will need to be improved to track the novel process of intercepting a routed payment.

Additional Documentation

See additional documentation on Ghost Addresses here.