# Revisiting BIP21

**URL:** <https://delvingbitcoin.org/t/revisiting-bip21/630>\
**Category:** Implementation\
**Tags:** taproot, address, wallet\
**Created:** [March 1, 2024, 1:48pm UTC](https://delvingbitcoin.org/t/revisiting-bip21/630 "2024-03-01T13:48:06Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![josibake](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/josibake/32/83_2.png) [@josibake](https://delvingbitcoin.org/u/josibake)\
**Post date:** [March 1, 2024, 4:03pm UTC](https://delvingbitcoin.org/t/revisiting-bip21/630/7 "2024-03-01T16:03:29Z")

</div>

> [@josibake](#):
>
> only usable with addresses that have an HRP (bech32, bech32m)

The more I think about it, this seems like a nice middle ground: update BIP21 to allow anything that already self identifies with an HRP to be included as a parameter. If it doesn’t have an HRP or if the HRP doesn’t indicate the protocol being used (payjoin, for example), it needs an extension key. This would allow URIs of the form:

- `bitcoin:sp1q..?lno...`
- `bitcoin:bc1p..?lnbc..`
- `bitcoin:sp1q..?bc1p..`
- `bitcoin:bc1p..?pj=<>`

The really nice thing here is we don’t need to define a new `addr` key and wallets that support address type X already know how to check for an HRP.

---

_[View the full topic](https://delvingbitcoin.org/t/revisiting-bip21/630)._