Introducing Ghost Addresses: A Lightning Address For Every Node \ stacker news ~litdevs

Introducing Ghost Addresses: A Lightning Address For Every Node

16.9k sats \ 26 comments \ @ambosstech 21 Dec 2023 litdevs

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.

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

view all related items

280 sats \ 0 replies \ @boisechampion 21 Dec 2023

This might be the final nail in the coffin to actually getting my first node. So bullish.

2154 sats \ 0 replies \ @benthecarman 21 Dec 2023

Seems a very weird way to do this and have amboss generated the preimage of the payment.

1364 sats \ 2 replies \ @anon 21 Dec 2023

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

41 sats \ 0 replies \ @Line2Wire 22 Dec 2023

Worth mentioning this is fully opt-in, not opt-out.

31 sats \ 0 replies \ @derekross 22 Dec 2023

only if you enable them. don't enable the feature and you'll be fine.

597 sats \ 0 replies \ @BlueSlime 21 Dec 2023

This is even worse than the standard routing on lightning. You are deliberately funneling all your payment traffic through amboss servers.

228 sats \ 0 replies \ @Eobard 21 Dec 2023

deleted by author

439 sats \ 2 replies \ @nullcount 21 Dec 2023

we can't wait to see how you all use Ghost Addresses.

Hence why I'll never use it.

1 sat \ 1 reply \ @nullcount 21 Dec 2023

Amboss likes to make tools for node runners that force their perfectly good nodes to use Amboss' node instead.

10 sats \ 0 replies \ @ambosstech OP 21 Dec 2023

This does not use the Amboss node. You can even build this yourself if you want, based on the documentation.

459 sats \ 0 replies \ @rhombus 21 Dec 2023

Just implement and use Bolt 12. Stop cheering for this centralized, steal your funds bullshit.

https://twitter.com/TheBlueMatt/status/1737906697941696637

404 sats \ 3 replies \ @endothermicdev 21 Dec 2023

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.

387 sats \ 0 replies \ @endothermicdev 21 Dec 2023

... of course adding a phantom address to the invoice bouncer solves both the fee and payment error issues.

52 sats \ 1 reply \ @k00b 22 Dec 2023

Your invoice bouncer sounds a little like lnproxy.

42 sats \ 0 replies \ @endothermicdev 22 Dec 2023

Definitely! Thanks for sharing.

30 sats \ 1 reply \ @justin_shocknet 21 Dec 2023

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.

273 sats \ 0 replies \ @ambosstech OP 21 Dec 2023

This does not use hold invoices and will not work if your node is offline. The payments will fail immediately in that case.

161 sats \ 3 replies \ @anon 21 Dec 2023

It's a trap! Don't get too excited before you study it in details first. You have been warned.

136 sats \ 1 reply \ @boisechampion 21 Dec 2023

If you have concerns share them here if not, why spread FUD?

1 sat \ 0 replies \ @rhombus 21 Dec 2023

Just use Bolt 12. This solution is still centralized and has the potential to steal your funds.

https://twitter.com/TheBlueMatt/status/1737906697941696637

100 sats \ 0 replies \ @xz 21 Dec 2023

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?

21 sats \ 0 replies \ @kr 21 Dec 2023

👻

21 sats \ 0 replies \ @0xbitcoiner 21 Dec 2023