We at Amboss Technologies are super excited to share something we've been working on: Ghost Addresses. This is our latest innovation for the Bitcoin Lightning Network, and we believe it's going to make a big impact.
What's a Ghost Address? Imagine combining the cleverness of Phantom Payments with the straightforward user experience of a Lightning Address. That's what a Ghost Address is all about. It's designed to make receiving Bitcoin on the Lightning Network as easy as receiving an email.
Why Does This Matter? For anyone running their own lightning node, Ghost Addresses are a game-changer. No more dependency on custodial third parties or needing a public Lightning Address server.
The Technical Stuff Ghost Addresses use Phantom Payments, a sophisticated routing technique that ensures payments are secure and efficient. You get a reusable address that keeps your transactions simple and straightforward. For a deeper understanding of Phantom Payments, check out this LDK blog post.
Easy to Get Started Setting up is really easy. Just update to a Ghost-enabled version of Thunderhub (v0.13.29), claim your Ghost Address, and you're ready to start receiving payments directly to your node.
Learn More and Get Started If you're as excited as we are and want to learn more, check out our detailed blog post: amboss.tech/blog/ghost-addresses and ghst.to.
We're thrilled to bring this to the Lightning Network community and can't wait to see how you all use Ghost Addresses. Let us know your thoughts, questions, or any cool ideas you have!
Cheers, Amboss Technologies Team
#Bitcoin #LightningNetwork #Innovation #SelfCustody
This might be the final nail in the coffin to actually getting my first node. So bullish.
reply
Seems a very weird way to do this and have amboss generated the preimage of the payment.
reply
Keep in mind that Amboss benefits when you download ThunderHub, as it includes functionalities that transmit confidential data to Amboss, which is then shared with external entities.
reply
Worth mentioning this is fully opt-in, not opt-out.
reply
only if you enable them. don't enable the feature and you'll be fine.
reply
This is even worse than the standard routing on lightning. You are deliberately funneling all your payment traffic through amboss servers.
reply
we can't wait to see how you all use Ghost Addresses.
Hence why I'll never use it.
reply
Amboss likes to make tools for node runners that force their perfectly good nodes to use Amboss' node instead.
reply
This does not use the Amboss node. You can even build this yourself if you want, based on the documentation.
reply
Just implement and use Bolt 12. Stop cheering for this centralized, steal your funds bullshit.
reply
This is interesting. I was thinking along similar lines, but would like to solve the opposite problem. I'm okay running a server, but don't want to link my node id with every invoice. I was envisioning solving this with an invoice bouncer:
Ask a peer node to sign an invoice for you. Add some extra final cltv delta and when the htlc reaches them, they know to forward a final hop to you in exchange for your preimage. This way the node id on the invoice may or may not be the node that's receiving the payment. Fees and payment failures could be tricky, but I'd be much more comfortable handing out lightning addresses if the invoice node id was always correlated to the final recipient in the lightning address. Adoption of BOLT12 could work too.
reply
... of course adding a phantom address to the invoice bouncer solves both the fee and payment error issues.
reply
Your invoice bouncer sounds a little like lnproxy.
reply
Definitely! Thanks for sharing.
reply
If I'm understanding correctly the use-case for this is as a failover if your node is down? In which case it's still relying on hold invoices?
People should also understand that there's no such thing as non-custodial Lightning address without your own webserver, because the webserver can ultimately serve any invoice to payers, not just the intended one you have the preimage for.
I'm disappointed to see continuation of that framing.
reply
This does not use hold invoices and will not work if your node is offline. The payments will fail immediately in that case.
reply
It's a trap! Don't get too excited before you study it in details first. You have been warned.
reply
If you have concerns share them here if not, why spread FUD?
reply
Just use Bolt 12. This solution is still centralized and has the potential to steal your funds.
reply
Expand on that a bit? I am sure there are privacy trade offs. One more bow in the 'fungible assets are and always should remain private quiver' no?
reply
👻
reply
Wow! This is a good innovation as it put emphasis to privacy
reply
Seems cool, i'll probably check it out.
reply
This issue is very interesting, I will study this issue carefully
reply
deleted by author
reply