Big Barry Bitcoin on Nostr: Reading the spec more carefully, here is what I see: > However, wallets providing ...
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 <user>@<domain> address is identified as BIP-353 compatible, it is effectively 'upgraded" indefinitely.
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 calle 👁️⚡👁️ (nprofile…f2j4) 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.
> 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 <user>@<domain> address is identified as BIP-353 compatible, it is effectively 'upgraded" indefinitely.
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 calle 👁️⚡👁️ (nprofile…f2j4) 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.