Reading the spec more carefully, here is what I see:
> However, wallets providing users the ability to copy their human-readable address information MUST include the ₿ prefix (i.e. copy it in the form ₿`user`@`domain`).
The spec dominates over LNURL rather than intending to be backward compatible. As soon as a
Imagine the scenario: Alice wishes to receive payment from Bob and his friend Carol. Alice sends payment information to Bob, who pays, and then passes payment info to Carol. Bob has a BIP-353 compatible wallet and the wallet prepends the ₿ prefix and Bob chose to copy payment info from his client. Carol has an older wallet and the payment fails because it doesn't understand how to interpret the prefix. Alice is confused because she set up both LNURL address and BIP-353 and gave a cross-compatible address to Bob.
LNURL addresses are not protected by DNSSEC, arguably making BIP-353 an upgrade and not an alternative. I think this is what the spec implies too in hindsight.
> This work is intended to extend and subsume the existing "Lightning Address" scheme ... Wallets implementing this scheme MAY fall back to existing "Lightning Address" logic if DNS resolution fails but SHOULD NOT do so after this scheme is sufficiently broadly deployed to avoid leaking sender IP address information.
The spec intends to "subsume" LNURL addresses. This is likely a good idea for security reasons, but then there is this weird migration period with teething issues as illustrated above.
Also, when it comes to copying the address, the client is expected to determine the user's intent:
> Wallets providing users the ability to "copy" their address information generally SHOULD copy the underlying URI directly in order to avoid the DNS indirection. However, wallets providing users the ability to copy their human-readable address information MUST include the ₿ prefix (i.e. copy it in the form ₿`user`@`domain`).
I have some closing thoughts about this:
1. As nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcppemhxue69uhkummn9ekx7mp069f2j4 mentioned, the ₿ symbol is hardly human typable, does this really qualify as human readable?
2. This almost appears to be a versioning flag. Parts of the spec may need to change, such as the URI format in the future. Is it worth acknowledging that this is effectively versioning and then adding more flexibility to that versioning scheme?
3. I am very curious how wallets will obey or disobey the copy/paste parts of the spec.
> Bob has a BIP-353 compatible wallet and the wallet prepends the ₿ prefix and Bob chose to copy payment info from his client.
Bobs wallet should copy the bitcoin: URI according to the spec, not the human readable address. Only when Alice and Bob communicate via voice should they use the human readable address. As long as she doesn't type the B symbol then Bobs LNURL fallback will work.
I think you should see indeed BIP-353 as a replacement for LNURL, at least for the this specific purpose of paying someone. It's backwards compatible if the sender types an email-like address, but not in all other scenarios.
It's not just about not needing https. The other difference is that once you've obtained payment info from BIP-353 you have everything you need. Once you have the bolt12 offer everything is lightning protocol native.
With LNURL there's another back and forth to request the actual invoice (IIUC). This is why you can't copy the bitcoin: URI and give it to a wallet that only supports LNURL and bolt12. But you *can* give it to a wallet that supports bolt12 and neither LNURL or BIP-353.
(2) I don't think there's any versioning. BIP21 style bitcoin: URIs are flexible enough to add new stuff later.
* "that only supports LNURL and bolt12" should be "that only supports LNURL and NOT bolt12"
Okay, so with BIP353 implicitly comes support for BIP21 which I have not read through yet 🙈.
This would make sending bitcoin://sjors._bitcoin-payment.provoost.nl sensible then. Since the OS will find the appropriate wallet for the protocol. 👍
Also the protocol is bitcoin:// (obviously) 👍
Now I follow completely.
Thank you.
I interpret it as "If Bob wants to 'share in a human readable format', give him the B prefixed string, but if unsure, clients SHOULD give the URI by default".
If the interpretation is that when I wish to SHARE my or your lightning address on a communication channel like nostr, I should be given the following to send:
Instead of:
Bsjors@provoost.nl
This is even more confusing imo!!!
I know I'm adding an extra step here to introduce the problem, if Bob just copy/pasted what Alice gave, then everything would be fine, but I just know that users will do what I described because humans are trouble makers through and through. 😅
