Interest in a Lightning Address Alias Service? \ stacker news ~bitcoin

pull down to refresh

Interest in a Lightning Address Alias Service?

7432 sats \ 22 comments \ @privnut 11 Aug 2023 bitcoin freebie

Hi All,

I'm writing to gauge interest for a lightning address alias service for privacy before I spend the time deploying the proof of concept I've built.

Problem: Lightning addresses are public identifiers that are generally tied to a single wallet. This can raise privacy concerns for individuals that work on multiple projects or have multiple online identities. For example, I go by different handles on Reddit, nostr, and Twitter and may like those identities to remain separated. Putting my lightning address in all 3 places would easily link those identities together.

Solution: Lightning Address Aliases

I'm proposing a completely free service that would allow users to generate unlimited lightning addresses that serve as aliases to a single, existing, lightning address. Similar to SimpleLogin and AnonAddy services that exist for email.

Example:

Lightning Address Alias Service is hosted at https://privacy.ln (example for demonstration, not real domain)
Main Lightning Address I want to keep private, the Destination Address: privnut @stacker.news
Users can create unlimited aliases such as alias1 @privacy.ln (I envision multiple domains being available for selection) and set those aliases to point to the Destination Address privnut @stacker.news
Further alias examples: MyTwitterHandle @privacy.ln, MyRedditHandle @privacy.ln, MyNostrHandle @privacy.ln, you get the point
Sats sent to any of these aliases would arrive at privnut @stacker.news without revealing that privnut @stacker.news is the destination or even exists.
Users would be asked for an email address, any email address, when creating an alias. Users could then log in to a dashboard to manage their aliases, create new ones, or redirect them to a new Destination Address (handy if you move to a new wallet provider, so you don't have to update your lightning address everywhere).

These aliases would not touch the sats, redirect them, or change their route. LNURL-Pay requests sent to any of the aliases linked to a Destination Address would all generate the same invoice.

That leads us to, Drawbacks:

Requires having an existing lightning address to use as the Destination Address
The payee pub key would be the same for all aliases and the Destination Address. Theoretically aliases and the Destination Address could be linked by mass requesting invoices from addresses, decoding them to gather pub keys and using those pub keys to link addresses, breaking the privacy of the aliases.

Thoughts? Suggestions? Concerns? Would this be something you'd use? Is this even necessary? or do the drawbacks listed (and maybe some I've missed) make it worthless?

view all related items

130 sats \ 0 replies \ @0fje0 12 Aug 2023

Late to the party, but...

After watching @TonyGiorgio's appearance on WhatBitcoinDid, I discovered I already had this thread open on SN, but hadn't read any of it yet. I certainly didn't consciously decide to first go watch WBD before reading here, but I'm sure glad I did, or else the discussion here would have made a lot less sense to me.

Unfortunately, it doesn't imply that I can offer meaningful feedback on your idea, so instead I'd just recommend that other "tech simpletons like me" consider watching that WBD episode as well. Really informative, I thought.

Great to have these minds here on SN! Thanks, I appreciate the high signal-to-noise ratio here. :)

214 sats \ 7 replies \ @BBitcoinUSA 11 Aug 2023

Definitely interested, tech simpletons like me need a lot more help in this department

264 sats \ 6 replies \ @privnut OP 11 Aug 2023

That's good to hear. What would you use lightning address aliases for? Anything that wasn't mentioned above?

Understanding all the potential use cases will help me build a better product if I push forward with this.

138 sats \ 5 replies \ @BBitcoinUSA 11 Aug 2023

For me it would be in terms of logging into sites and services with Lightning. I haven’t been doing this to date due to my lack of understanding in the tech/tracking/privacy department. So I’ve been using one of those email alias tools a lot lately for creating online accounts (in the middle of a job search and have to do that frequently). But I still have all of the usual concerns about those tools in terms of data breaches, hacks, etc I hear so much about in the news, such as that password manager last year which had some big breach I read about, blanking on the name of it.

64 sats \ 3 replies \ @privnut OP 11 Aug 2023

I will need to look into whether or not I could support lnurl-auth (the flow used to log in with lightning) with my planned approach, I'm not sure that I could.

My focus, initially, at least, would be on aliases receiving payments.

46 sats \ 2 replies \ @BBitcoinUSA 11 Aug 2023

still a great idea, does anything else like that exist yet? about the drawbacks,

Requires having an existing lightning address to use as the Destination Address
The payee pub key would be the same for all aliases and the Destination Address. Theoretically aliases and the Destination Address could be linked by mass requesting invoices from addresses, decoding them to gather pub keys and using those pub keys to link addresses, breaking the privacy of the aliases.

#1 doesn't seem to difficult to overcome #2 I think it's definitely a valid concern, but the undertaking required for someone to achieve that would be pretty massive, but I don't understand tech enough to say that with any confidence

174 sats \ 1 reply \ @privnut OP 11 Aug 2023

I haven't seen anything else like this, but it's possible I have missed it. There are services like https://satspay.to/ which allow you to create a lightning address and point it at your own lightning node, but that is quite a bit different than the aliases I have planned.

Regarding Drawbacks: #1: Agreed, we would probably just refer users to a service such as Alby or even Stacker News to get their first lightning address if they did not already have one. #2: I'm still debating internally whether this drawback defeats the entire point of the aliases. If you are using aliases to stay 100% private, any way to pierce that privacy veil, no matter how difficult or theoretical that threat is, is likely a deal-breaker. But if you simply wanted aliases to add a bit of privacy and the ability to use multiple lightning addresses that point to a single wallet, I can see that use case. I'd love more feedback and thoughts on this, to anyone lurking.

I'm just not sure how many people would use the aliases if they were not 100% private, it's probably a pretty big drawback.

I really, really appreciate your feedback @BBitcoinUSA

92 sats \ 0 replies \ @BBitcoinUSA 11 Aug 2023

Happy to help, I think the added convenience would definitely outweigh the risk for most people, but I wouldn't want to encourage that since most people just aren't aware of the risk in the first place. I'm probably missing something, I don't think I understand how onerous the process is for mass requesting invoices and then "decoding the invoices" would be - is it just a matter of running each invoice through a hash calculator type of thing or do I have it all backwards?

10 sats \ 0 replies \ @TonyGiorgio 11 Aug 2023

LNURL auth has nothing to do with lightning. Just the seed words you use for your lightning node. There's non lightning apps that log in via lnurl auth. Doesn't publicly tie to your node or across multiple services.

46 sats \ 5 replies \ @TonyGiorgio 11 Aug 2023

The payee pub key would be the same for all aliases and the Destination Address.

This almost makes the whole effort useless. You'd need to combine it with something like LNProxy or the voltage flow 2.0 LSP to gain the privacy here. Or wait till route blinding.

0 sats \ 4 replies \ @privnut OP 11 Aug 2023

Thanks for the feedback Tony. I'm familiar with LNProxy, but did not want to touch the users' sats if at all possible. I'm going to read up on voltage flow 2.0.

Regarding the payee public key, I think I should have specified that (at least to my understanding) this would only reveal the node, not the user of the node, assuming the user is using a custodial wallet, which I assume most lightning address users are, this may not pierce the privacy veil as much as I implied in the OP.

All invoices I've asked Stacker.news to create have had the same payee pub key, for different users, so perhaps this is less privacy revealing than my original post makes clear.

Someone snooping around may be able to tell that a alias points to a Stacker News user, but would they be able to tell which Stacker News user, based on the invoice? If not, this may be acceptable to many users.

I assume there is some other information in the invoice that may, potentially, be linkable to a user, but I need to do more research on lightning invoice format to get to the bottom of that.

0 sats \ 3 replies \ @TonyGiorgio 11 Aug 2023

If the main solutions this solves is on the custodian side, then can't the user make a bunch of custodian accounts anyways? It wouldn't really be much different than making a bunch of proxy.ln accounts that point to the same custodian.

Yes, with LNProxy / Flow 2.0, there is someone that touches the sats, but only in terms of forwarding them. They can't take the funds, only the user has the preimage.

9 sats \ 2 replies \ @privnut OP 11 Aug 2023

Creating many custodial accounts is certainly an option and I bet it is what most users do today that are lightning address users and have this privacy concern. My goal with the aliases was to offer an easier path.

Which is easier, having 20 accounts, all with different amounts of sats that you have to log into and log out of. Or having 20 aliases that all send your sats to a single account you are always logged into?

I find the latter much more user friendly, and that's why I built it for myself. If custodial LSPs allowed you to create unlimited lightning addresses that all pointed to 1 account, this would be a moot point. But I haven't seen any that do that, yet.

Taking it from something I built for my own personal use, to a product that is user friendly for everyone is a big lift, and will cost me to run monthly.

If others, like yourself, don't find it useful, that's perfectly fine and I get it. It just means I probably shouldn't waste time productizing it and just keep using my personal version.

I really appreciate your feedback, Tony. It, and the lack of comments from others so far (apart from @BBitcoinUSA) is making me lean towards shelving this project for now and keeping it personal-use only. I'm not sure many would find it useful other than a privacy nut like myself!

0 sats \ 1 reply \ @TonyGiorgio 12 Aug 2023

If privacy is what they're seeking but they're collecting all those sats onto a single custodian then they're not really going to get much at that point. If it was combined with LNProxy then it would be better. You don't have to touch the sats at all yourself. It's a simple 2 step process. Create normal invoice, then post it to LNProxy and use the returned one. They offer APIs for that. That would allow for easy alias management with invoices that look like they're coming from LNProxy. It would actually be a good offering and something I wanted to build for myself to protect my node identity but still have an LNURL. Just never had the time.

0 sats \ 0 replies \ @privnut OP 12 Aug 2023

How does LNProxy handle liquidity, fees, etc? The main reason I didn't want to touch the sats was to not inject an additional point of failure for the payment.

I'm looking into LNProxy more, you might have convinced me if there aren't fee, liquidity, or other issues that may cause the payment to fail.

Thanks Tony.

0 sats \ 1 reply \ @jamesviggy 13 Aug 2023

Sounds like it would be useful!

Would the recipient be able to know which one of their aliases were being used for each payment they receive?

10 sats \ 0 replies \ @privnut OP 13 Aug 2023

The plan would be that this info would be included as a memo/note, yes.

0 sats \ 1 reply \ @SpaceHodler 12 Aug 2023

I believe I've seen a similar service already.

Users would be asked for an email address, any email address, when creating an alias. Users could then log in to a dashboard to manage their aliases, create new ones, or redirect them to a new Destination Address

Why not LNURL Auth instead of email?

0 sats \ 0 replies \ @privnut OP 12 Aug 2023

Do you know the service you saw? I can't find anything.

LNURL Auth would be an easy add, will definitely do that.

0 sats \ 2 replies \ @netstatic 11 Aug 2023

As mentioned by @TonyGiorgio, the privacy it gives is surface-level for anyone willing to put in the effort to extract and compare invoices, which is something you also noted. I don't think it's useless though. Having different lightning addresses for each of my websites will prevent them from being enumerated from just one of my lightning addresses on Google at least

0 sats \ 1 reply \ @privnut OP 11 Aug 2023

Thanks for the feedback!

For users using a custodial wallet, such as Alby, WoS, right here on SN, etc. All invoices generated by those services contain the same payee public key. So you could certainly link an alias to a wallet service. But there are tens, or hundreds of thousands of users using the popular wallet services.

I'm struggling to find a way to link two invoices, from a custodial service like above, to a single user. Honestly, I'm not very familiar with how accounts work for these custodial services where many users share a single node and whether any user info is included in the invoice. Perhaps they just link the invoice to the user account on the backend, when the invoice is generated, and credit the account when the invoice is paid. @TonyGiorgio, as a wallet developer, do you have any idea?

If anyone else has any insight around that, it would be very helpful!

10 sats \ 0 replies \ @k00b 12 Aug 2023

Just use https://lnproxy.org/ to hide the destination's pubkey.

If you're self-hosting you'll need to have enough liquidity to support routing all proxied lightning invoices but you'd achieve meaningful levels of privacy.