bip353: improve ₿-prefix instructions #1645

pull Sjors wants to merge 1 commits into bitcoin:master from Sjors:2024/07/bip353 changing 1 files +4 −2
  1. Sjors commented at 7:24 pm on July 11, 2024: member

    I was very confused when reading the ₿-prefix instruction for BIP353. Others have been confused as well:

    This PR reorders the sentences and slightly rewords them.

    Because the rationale comes after these instructions, it’s important to first point out the main aim: ₿user@example.com should be the default rendering, it’s not just some optional alternative format.

    I moved the bit about external (hardware) wallets down.

    I’m unconvinced the ₿-prefix is a good idea in the first place, but this PR doesn’t change it.

  2. TheBlueMatt approved
  3. in bip-0353.mediawiki:71 in 286783f161 outdated
    67@@ -68,9 +68,11 @@ Payment instructions which do contain on-chain addresses which will be re-used S
    68 
    69 === Display ===
    70 
    71-Wallets SHOULD parse recipient information in the form `user`@`domain` or ₿`user`@`domain` and resolve such entry into recipient information using the above record. Similarly, wallets accepting payment information from external devices (e.g. hardware wallets) SHOULD accept RFC 9102-formatted proofs (as a series of unsorted `AuthenticationChain` records) and, if they verify, SHOULD display the recipient in the form ₿`user`@`domain`. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved.
    72+When displaying a verified human-readable address wallets SHOULD prefix it with ₿, i.e. ₿`user`@`domain`. They SHOULD parse recipient information in both `user`@`domain` and ₿`user`@`domain` forms and resolve such entry into recipient information using the above record. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved.
    


    jonatack commented at 8:00 pm on July 11, 2024:
    0When displaying a verified human-readable address, wallets SHOULD prefix it with , i.e. `user`@`domain`. They SHOULD parse recipient information in both `user`@`domain` and `user`@`domain` forms and resolve such entry into recipient information using the above record. For the avoidance of doubt, the  is *not* included in the DNS label which is resolved.
    

    Sjors commented at 7:12 am on July 12, 2024:
    Added the comma.
  4. in bip-0353.mediawiki:75 in 286783f161 outdated
    72+When displaying a verified human-readable address wallets SHOULD prefix it with ₿, i.e. ₿`user`@`domain`. They SHOULD parse recipient information in both `user`@`domain` and ₿`user`@`domain` forms and resolve such entry into recipient information using the above record. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved.
    73 
    74-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`).
    75+Wallets providing users the ability to "copy" their address information SHOULD copy the underlying URI directly, rather than the human-readable address. This avoids an additional DNS lookup by the application in which it is pasted. Wallets that nevertheless provide users the ability to copy their human-readable address, MUST include the ₿ prefix (i.e. copy it in the form ₿`user`@`domain`).
    76+
    77+Wallets accepting payment information from external devices (e.g. hardware wallets) SHOULD accept RFC 9102-formatted proofs (as a series of unsorted `AuthenticationChain` records) and, if they verify, SHOULD display the recipient in the form ₿`user`@`domain`.
    


    jonatack commented at 8:03 pm on July 11, 2024:
    and, if they verify," -> seems ambiguous, suggest using the specific subject “they” refers to here.

    Sjors commented at 7:09 am on July 12, 2024:
    I changed it to “if verification succeeds”
  5. in bip-0353.mediawiki:73 in 286783f161 outdated
    67@@ -68,9 +68,11 @@ Payment instructions which do contain on-chain addresses which will be re-used S
    68 
    69 === Display ===
    70 
    71-Wallets SHOULD parse recipient information in the form `user`@`domain` or ₿`user`@`domain` and resolve such entry into recipient information using the above record. Similarly, wallets accepting payment information from external devices (e.g. hardware wallets) SHOULD accept RFC 9102-formatted proofs (as a series of unsorted `AuthenticationChain` records) and, if they verify, SHOULD display the recipient in the form ₿`user`@`domain`. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved.
    72+When displaying a verified human-readable address wallets SHOULD prefix it with ₿, i.e. ₿`user`@`domain`. They SHOULD parse recipient information in both `user`@`domain` and ₿`user`@`domain` forms and resolve such entry into recipient information using the above record. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved.
    73 
    74-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`).
    75+Wallets providing users the ability to "copy" their address information SHOULD copy the underlying URI directly, rather than the human-readable address. This avoids an additional DNS lookup by the application in which it is pasted. Wallets that nevertheless provide users the ability to copy their human-readable address, MUST include the ₿ prefix (i.e. copy it in the form ₿`user`@`domain`).
    


    jonatack commented at 8:05 pm on July 11, 2024:
    "copy" their address -> somewhat ambiguous; “their” could refer to either “wallets” or to “users” -> perhaps s/their/the user's/

    Sjors commented at 7:10 am on July 12, 2024:
    I changed to: “providing the ability for users to “copy” their address”

    jonatack commented at 1:18 pm on July 12, 2024:
    Thanks for updating. Another way that would be clearer would be “providing the ability for a user to “copy” his or her address” – but I’m probably looking for more precision than most people care about :)
  6. jonatack commented at 8:06 pm on July 11, 2024: contributor
    Approach ACK
  7. jonatack added the label Proposed BIP modification on Jul 11, 2024
  8. bip353: improve ₿-prefix instructions ceb4f332a4
  9. Sjors force-pushed on Jul 12, 2024
  10. t-bast approved
  11. t-bast commented at 7:22 am on July 12, 2024: contributor
    Thanks, ACK!
  12. jonatack commented at 1:19 pm on July 12, 2024: contributor
    ACK, thanks!
  13. jonatack merged this on Jul 12, 2024
  14. jonatack closed this on Jul 12, 2024

  15. Sjors deleted the branch on Jul 12, 2024

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-03 16:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me