This approach aims to simplify the resolution of human-readable names to Bitcoin payment addresses across various platforms, including lightning networks, on-chain transactions, payjoin mechanisms, and silent address systems. The initiative highlights the strong user demand for such functionalities, leveraging the global and hierarchical nature of the Domain Name System (DNS) to map human-readable labels to specific records securely through DNSSEC, a suite of extensions designed to add security to the DNS.

The specification mandates that Bitcoin wallets should prioritize direct methods of payment addressing, such as standard Bitcoin addresses or explicit BIP 21 URIs when available, over DNS-based resolution. It outlines the structure for payment instruction records, requiring them to be associated with a user and a domain and stored in a singular TXT record at a specified DNS path. These records must be secured with DNSSEC signatures and may utilize CNAME or DNAME records for resolution, provided all associated records are also DNSSEC-signed. Additionally, it specifies encoding requirements for non-ASCII user and domain names and sets guidelines for handling multiple or invalid TXT records.

The proposal underscores the importance of minimizing address reuse by advocating for regular rotation of on-chain addresses and suggesting a short DNS Time-To-Live (TTL) for quick updates. For cases where address reuse is unavoidable, it recommends omitting on-chain addresses from payment instructions. It also details how wallets should display recipient information and handle external payment information, emphasizing the need for RFC 9102-formatted proofs to authenticate the recipient's identity.

Addressing the rationale behind choosing DNS over blockchain or HTTP-based solutions, the proposal argues for the DNS's widespread adoption and simplicity despite its lesser censorship resistance compared to some blockchain alternatives. It acknowledges the trade-offs between privacy and practicality in DNS querying, suggesting the use of public recursive resolvers or privacy-focused solutions like Tor for enhanced privacy. The document discusses the potential for user enumeration through DNS and advises strategies to mitigate this risk.

Included examples demonstrate how a user's payment instruction is resolved through DNS, highlighting the incorporation of lightning network BOLT12 offers. The proposal also references implementation resources, including a DNSSEC proof generation and validation tool and a lightning-specific resolver, available at their respective GitHub repositories.