# Human Readable Bitcoin Payment Instructions **URL:** \ **Category:** Protocol Design\ **Created:** [February 11, 2024, 1:11am UTC](https://delvingbitcoin.org/t/human-readable-bitcoin-payment-instructions/542 "2024-02-11T01:11:04Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![t-bast](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/t-bast/32/98_2.png) [@t-bast](https://delvingbitcoin.org/u/t-bast)\ **Post date:** [February 12, 2024, 10:12am UTC](https://delvingbitcoin.org/t/human-readable-bitcoin-payment-instructions/542/4 "2024-02-12T10:12:40Z")
That was exactly one of the flows I proposed in [Future of lightning address · GitHub](https://gist.github.com/t-bast/78fd797a7da570d293a8663908d3339b#option-1-use-dns-records-to-link-domains-to-nodes) I think it is useful and simple indeed, especially for lightning providers who want minimal DNS operational burden. EDIT: this is covered in the bLIP that Matt created: [Define blip-0032, DNSSEC proof querying over onion messages by TheBlueMatt · Pull Request #32 · lightning/blips · GitHub](https://github.com/lightning/blips/pull/32) This is the `omlookup` path: a domain that has many users would create a single DNS record `*.user._bitcoin-payment.domain.` containing a blinded path to themselves (which may actually be a 0-hop blinded path directly exposing their `node_id`). Clients then use that blinded path to request an offer for a specific user via an onion message. --- _[View the full topic](https://delvingbitcoin.org/t/human-readable-bitcoin-payment-instructions/542)._