-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to distinguish a Lightning address from email addresses? #27
Comments
There have been discussions around getting a |
The more I dig into LN addresses the more I think the way to assert where and what these identifiers are is via DNS (I'll admit to being a DNS guy, so "hammer -> nail" may apply). But using a well known location assumes the json file lives on the hostname of the @domain.com portion of the label, but people may want to store the payload elsewhere (tangentially, unless I'm missing something, if there is a web vulnerability where the ln address json file is stored, say, in the CMS of the webserver, then an antagonist can overwrite the destination with their own). In this issue's case, if the data was stored in a TXT record (see Issue #43 ) then you could answer the email vs ln pay URI by testing for the existence of a TXT record, for example. Going forward, we'll see more DNS metadata move on-chain (or elsewhere), we'll still want the ability to have a level of abstraction between the identifier ([email protected]) and what and were the payment specifier is. (FWIW, I've been thinking about this for a long time, since before Lightning existed, but dropped it when a core dev of the era told me it was stupid. I'm thinking about it again now after a couple conversations with people I met at #Bitcoin2022 in Miami a couple weeks ago). |
@andrerfneves do you have any thoughts on this proposal from @markjr? A TXT record pointing to a bridge server or directly to a LNURL-pay server seems a good way to move forward. |
Thinking out loud here; With DNS, we have CNAME where the service can be overlayed onto a different domain, but that service is for all users, not a subset. To stick with the normal internet model, what you are referring to is perhaps closer to a CNAME alias. For a DNS-based aliasing system to work, the target service would need to 'know' the domain name which it is providing service for. Since http 1.1, web browsers have delivered the name of the domain in their payload so that the servier is able to properly handle the request. This allows many web sites to be served from one IP address. That is at the HTTP level of abstraction. The API is at a level of abstraction higher than that and should be independent of the HTTP implementation used to deliver the API payload. The DNS model we have today does allow publication of capabilities and short-data domain-wide configuration. The effects of "poisoning" the DNS system is mitigated with SSL certificates for HTTPS requests. Relying on DNS entries, which can potentially be "poisoned" could therefore be less safe than delivering payment configuration over HTTPS or Tor. If DNS could be determined as "safe enough", or if some form of signing made it safe, the resolver would need to incorporate the original domain name as well as the user name in a request to a different server. This could maybe be implemented with something like Where the original payment was sent to [email protected] and that request was forwarded to a server outside of the domain to handle the LNURL payment request. Maybe with a TXT record: |
@marcbarbosa to my knowledge this is the only place where I've seen this discussion |
As Lightning addresses are identical to email addresses, how would we go about distinguishing them from emails? This concern came up here BitcoinDesign/Guide#581 (comment).
Two possible solutions mentioned:
pay
sub-domain format like[email protected]
?pay:[email protected]
to distinguish it from emails which useemailto:[email protected]
.The text was updated successfully, but these errors were encountered: