https://amboss.tech/_next/image?url=%2Fassets%2Fblog%2Fghost-addresses%2Fhero.webp&w=1920&q=75 Hey Stackers,
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. https://amboss.tech/_next/image?url=%2Fassets%2Fblog%2Fghost-addresses%2F2.webp&w=1920&q=75
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
Seems a very weird way to do this and have amboss generated the preimage of the payment.
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.
https://github.com/apotdevin/thunderhub/pull/546
Worth mentioning this is fully opt-in, not opt-out.
only if you enable them. don't enable the feature and you'll be fine.
This is even worse than the standard routing on lightning. You are deliberately funneling all your payment traffic through amboss servers.
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.
... of course adding a phantom address to the invoice bouncer solves both the fee and payment error issues.
Your invoice bouncer sounds a little like lnproxy.
Definitely! Thanks for sharing.
Just implement and use Bolt 12. Stop cheering for this centralized, steal your funds bullshit.
view on twitter.comHence why I'll never use it.
Amboss likes to make tools for node runners that force their perfectly good nodes to use Amboss' node instead.
This does not use the Amboss node. You can even build this yourself if you want, based on the documentation.
This might be the final nail in the coffin to actually getting my first node. So bullish.
It's a trap! Don't get too excited before you study it in details first. You have been warned.
If you have concerns share them here if not, why spread FUD?
Just use Bolt 12. This solution is still centralized and has the potential to steal your funds.
view on twitter.comExpand 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?
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.
This does not use hold invoices and will not work if your node is offline. The payments will fail immediately in that case.
👻
https://www.system-concepts.com/wp-content/uploads/2020/02/excited-minions-gif.gif
Wow! This is a good innovation as it put emphasis to privacy
Seems cool, i'll probably check it out.
This issue is very interesting, I will study this issue carefully
deleted by author