Skip to content
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

open ends in blip 0032 #47

Open
AndySchroder opened this issue Sep 24, 2024 · 2 comments
Open

open ends in blip 0032 #47

AndySchroder opened this issue Sep 24, 2024 · 2 comments

Comments

@AndySchroder
Copy link

blip-0032 says

Finally, a forthcoming bLIP will define a method to include the `user` part of the human-readable

and

The node receiving the `invoice_request` can use the `user` field to determine for which user the

Where is this blip? Are these just added to the BOLT12 messages?

Also stated is

a wildcard record may be provisioned as *.user._bitcoin-payment.`domain` with the same contents.

Why is this not defined in https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki ? Also what is the resolution order of the wildcard vs non-wildcard record? Seems like this needs to be defined.

Also, I think there should be some guidance on offer expiry and DNS record TTL. The record TTL should always expire before the offer.

Generally, I think the connection between BIP-0353 and blip-0032 is a bit loose and the should be referenced more tightly. Also, it might make more sense to separate the payer protocol from the DNS proof records over onion messages in blip-0032 into seperate blips (or at least make the blip title more inclusive of both topics). It is a bit confusing to have these mashed together and it might be easier to connect to BIP-353 if there is more clear separation of topics.

@TheBlueMatt
Copy link
Contributor

TheBlueMatt commented Oct 2, 2024

I ended up proposing the name inclusion in BOLTs as lightning/bolts#1180.

...wildcard...
Why is this not defined in https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki ?

Its not super useful outside of the lightning context (otherwise all "user"s will end up paying to the same address with no way to differentiate).

Also what is the resolution order of the wildcard vs non-wildcard record? Seems like this needs to be defined.

DNS specific records override wildcard records (and in fact if you receive a wildcard DNSSEC proof you must validate that the proof contains non-existence proofs for the specific record).

Also, I think there should be some guidance on offer expiry and DNS record TTL. The record TTL should always expire before the offer.

Good point.

Generally, I think the connection between BIP-0353 and blip-0032 is a bit loose and the should be referenced more tightly.

Do you have any specific recommendations? Not sure what else to add.

Also, it might make more sense to separate the payer protocol from the DNS proof records over onion messages in blip-0032 into seperate blips (or at least make the blip title more inclusive of both topics).

bLIP 32 doesn't define the payer protocol at all, it only describes it in the non-normative discussion sections for completeness. It seems pretty separated given its in two totally separate sections of the document?

@TheBlueMatt
Copy link
Contributor

Opened bitcoin/bips#1672 and #48

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants