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

BIP 321: URI Scheme (Replace BIP 21 with a new BIP containing information about more modern usage of it) #1555

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open
Prev Previous commit
Link BIP 352 and add BIP 351 to list of keys
  • Loading branch information
TheBlueMatt committed Oct 19, 2024
commit d7c021a10278391580de33f847d443d5fcc1be53
3 changes: 2 additions & 1 deletion bip-XXXX.mediawiki
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,8 @@ The following keys are currently defined for payment instructions of various for

*lightning: Lightning BOLT 11 invoices
*lno: Lightning BOLT12 offers
*sp: Silent Payment addresses
*pay: [[bip-0351.mediawiki|BIP 351 Private Payment addresses]]
*sp: [[bip-0352.mediawiki|BIP 352 Silent Payment addresses]]

New payment instructions using bech32 or bech32m encodings SHOULD reuse their address format's Human Readable Part as the parameter key.
TheBlueMatt marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the discussion on this PR, some reviewers were suggesting using bc1q and bc1p as parameter keys for native segwit payment instructions. In case that was meant to be proposed here, I wanted to point out that the human-readable part for all native segwit versions is bc.

If you meant to propose that bc1q, bc1p, bc1z, to be used, this could be described as:

Suggested change
New payment instructions using bech32 or bech32m encodings SHOULD reuse their address format's Human Readable Part as the parameter key.
New payment instructions using bech32 or bech32m encodings SHOULD reuse their address format's _human-readable part (HRP)_ as the parameter key. As all native segwit outputs share the same HRP, Bech32m addresses for future native segwit output types SHOULD use the four-character prefix of the address as the parameter key, e.g. `bc1p`, `bc1z`, `bc1r`, etc.


Expand Down