-
Notifications
You must be signed in to change notification settings - Fork 47
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
Comments
I ended up proposing the name inclusion in BOLTs as lightning/bolts#1180.
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).
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).
Good point.
Do you have any specific recommendations? Not sure what else to add.
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? |
Opened bitcoin/bips#1672 and #48 |
blip-0032 says
blips/blip-0032.md
Line 86 in b6c3e8c
and
blips/blip-0032.md
Line 118 in b6c3e8c
Where is this blip? Are these just added to the BOLT12 messages?
Also stated is
blips/blip-0032.md
Line 117 in b6c3e8c
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.
The text was updated successfully, but these errors were encountered: