The complexity of Lightning has seen many users opt for custodial wallet options; this reliance on custodial wallet providers to hold user balances or generate Lightning Addresses exposes users to the possibility of getting rugged through services shutting down or ceasing operations due to regulatory changes, risking the accessibility and privacy of their funds.
Over the last month, we’ve seen Lightning-based companies start to change their policies to front-run what they feel will be stricter regulation. Wallet of Satoshi removed itself from the U.S. Apple and Google app stores, while Alby has opted for an invite-only model for custodial users.
These moves illustrate the need to improve non-custodial Lightning wallet options and privacy tech.
Phantom node payments are a privacy tech that lets larger users running high-volume lightning nodes generate invoices that can be paid to one of multiple production nodes. Phantom nodes work under the assumption that payers will retry payments along an alternate route hint if one fails, phantom payments allow for load balancing between nodes and resilience if a node or nodes go down.
What are Phantom Node payments?
Imagine invisible nodes flitting through the Lightning Network, unseen yet providing an essential service in adding a layer of privacy to payments. These are Phantom Nodes, fake Lightning Network nodes that don’t exist but handle your transactions without revealing your identity. Think of them as cloaked couriers, silently delivering your satoshis to their destination.
So, how do they work?
Phantom Nodes utilise a unique protocol that masks your Lightning Channel endpoints. Instead of providing your own node as the final destination, your transaction is destined for a Phantom Node, making it appear as if the payment isn’t intended for you. It’s like sending a letter with a fake return address, leaving the recipient (and everyone else) none the wiser about your true location.
When a payment is made to your associated Phantom node, a hint is left for your node to retrieve the payment.
The limitations of Phantom nodes
One potential drawback to phantom node payments is the lack of support for multi-path payments (MPP). MPP payments benefit large transactions as payments can be split through different routes and recompiled in your node. Phantom invoices are ideally designed for smaller payments, which are the most common and are unlikely to use MPP.
What are ‘Ghost Addresses’?
Lightning Network payment solutions company Amboss has borrowed some of the elements of Phantom Node Payments to launch a new product called “Ghost Addresses”. Ghost Addresses are a type of Lightning Address that enables users to receive payments directly into their own node, avoiding reliance on dominant custodial wallets.
Similar to Lightning Addresses, a Ghost Address functions as a static, reusable endpoint that makes receiving payments into a connected Lightning wallet. Anyone running their lightning node can have a Lightning Address without needing a custodial third party or a publicly accessible server.
Ghost Addresses are compatible with any Lightning Network implementation through integration with its API but are currently only available via Thunderhub, which uses the LND implementation.
How do Ghost Addresses work?
When a user pays a Ghost Address, they will receive a request from the ghost.to server, which provides a BOLT 11 lightning invoice to a Phantom Node, which technically does not exist. Since a payment cannot settle on a node that doesn’t exist, Amboss includes 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.
When a payment routes towards a phantom node, the receiver node requests the preimage from the Amboss API. Using the preimage, the receiver node can intercept the payment destined for the phantom node and claim the payment for themselves.
Ghost Address privacy
Payments made to a Ghost Address use invoices that Amboss generates, revealing the payment amount. Amboss then serves the preimage to the generated invoice upon authenticating the request. Amboss doesn’t know about subsequent withdrawals or other payments. In this context, receiving a payment to a Ghost Address will be far more private than using a custodial Lightning Address.
Risk of getting Ghosted
When using a Ghost Address provider you are involved in a trust model and run the risk that the provider (Amboss) could alter the node destination for payments or their server could be compromised by a hacker who would redirect payments.
Limitations of Ghost Addresses
Ghost Addresses uses LDK’s Phantom Payments as part of its stack, making it incompatible with Multi-Path Payments (MPP). Consequently, some wallets that use simple or atomic multi-path payments cannot send funds to Ghost Addresses.
How do you set up a Ghost Address?
Getting started is simple and should take a few minutes; all you need to do is open up your Lightning node and install Thunderhub or update your current version if you already use the interface.
- Update Thunderhub to a Ghost-enabled version (>0.13.29).
- Claim your Ghost Address by going to the Amboss tab in Thunderhub.
- You can now use your new lightning address <username>@ghst.to, which will be used to receive payments directly to your node!
The current landscape for Lightning Addresses
Lightning Addresses have grown in popularity, especially with the introduction of Nostr, as Lightning addresses are used as the primary payment method for zaps. Still, the overwhelming majority of addresses have been custodial services like Alby, Zebedee, Blink Wallet, and Wallet of Satoshi, which handles all the complexity for users.
Ghost Addresses might not change that, but they provide an option for users who might be pushed towards running their own Lightning Node, as custodial services come under stricter regulation.
As a Lightning Node runner, your options are to use a bridging server with your Lightning Addresses, such as the HODL invoice approach used by Zeus Wallet, or to self-host the entire stack and run a Lightning Address on your own domain.
When BOLT12?
Lightning Addresses, while helpful, seem like a stop-gap solution for the lack of BOLT 12 support. BOLT12 offers a way to streamline the payment process by permitting a payee to give a static BOLT12 offer to a payer, who can then make a payment directly along an LN route to the payee using a newly generated hash from a random preimage.
This procedure allows the payment to be conducted without an intermediary web server. It’s mentioned that nodes capable of issuing or understanding BOLT12 inherently support this feature, which keeps intermediate nodes in the dark about the new feature, eliminating the necessity for their upgrade.
Additionally, there are implications that BOLT12 could potentially integrate with various web payment protocols being developed by groups like the W3C Web Payments Working Group, suggesting that BOLT12 might have broader applications beyond direct LN transactions.
Do your own research.
If you want to learn more about phantom payments, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research, check out their official resources below or review other articles and videos tackling the topics.
