Lightning Address in a Bolt 12 world

The discussion focuses on the enhancement of the lightning address protocol, aiming to improve user experience while addressing its current privacy and security issues. The protocol is appreciated for its user experience benefits but has been criticized for exposing the payment sender's IP address, enabling potential invoice swapping by domain owners, and necessitating an HTTP stack and DNS server dependency on the sender's side. To rectify these problems, two primary mechanisms are proposed: one to obtain the node_id associated with a domain privately, and another to contact the domain to acquire the recipient's payment details without compromising privacy.

One design option suggests using DNS records to link domains to nodes. Domain owners would add a DNS TXT record containing a blinded path or the direct node_id. Payment senders like Alice could then make a DNS query to retrieve this information without revealing their identity or intent to pay to both the LSP and the domain manager. An example provided illustrates how Alice would query the TXT record to obtain the blinded path and subsequently use an onion message to request payment details from Bob.

Despite presenting three design options in the gist, the author proposes implementing only options 1 and 3 to maintain simplicity in implementation and deployment. They suggest that clients should first attempt to use option 3 (DNS request) and if unsuccessful, fall back to option 1. Domain owners are encouraged to implement just one of the two options depending on their DNS capabilities.

The author expresses a desire to refine these ideas into a bLIP (Bitcoin Improvement Proposal) after gathering sufficient community feedback and acknowledges Rusty and Matt for reviewing early drafts. The goal is to enhance the lightning address protocol to provide a better balance between user experience and privacy/security concerns.