# 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:** 12

<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, 5:59pm UTC](https://delvingbitcoin.org/t/revisiting-bip21/630/12 "2024-03-01T17:59:02Z")

</div>

> [@MattCorallo](#):
>
> but not sure if any existing implementations try to parse parameters as K/V and fail if there’s no =

If they are requiring an `=` they aren’t spec compliant? 🙂 But agree, we don’t want to break anything. This is pretty easy to verify, though, since we have a good list of implementations listed at [https://bitcoinqr.dev/](https://bitcoinqr.dev/) which can be used to verify, and this is a somewhat trivial fix if they are requiring an `=`.

This seems less risky then specifying `bitcoin:?key=val`, which seems _more_ likely to break existing implementations since a spec compliant implementation _would_ expect an address in the root of the URI.

Furthermore, this can be used along side existing `key=val` parameter pairs, so you can even start using the new technique along with the old way in a backwards compatible way. Seems like a no brainer to me.

---

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