Matt Corallo

Please don't bother commenting any further here that "this should use HTTP". If that's your take please read the text of the BIP which clearly explains why HTTP is horribly...

> It is extensible enough to support BTC L2s, LN, Ark, etc. So is this, by reusing logic any wallets already have. > XKCD standards comic🤭 > It already has...

> What would be the benefit if DoH has to be used? You could just do LNURL-pay then. Please read the BIP text, specifically drawbacks (a), (b), and (c). Note...

> Another thought: the parsing of USER@DOMAIN is pretty trivial, but how to do it should be mentioned. Agreed, I'd like to add a section on displaying this info, but...

> I've been trying very hard to understand this. How could a wildcard record solve the problem? Where would names be stored so they can be associated with keys, and...

> Better taproot support: using HRPs directly would allow us to construct backwards compatible taproot URIs of the form bitcoin:bc1q...?bc1p...=o / bitcoin:bc1q...?bc1p... I think this ship has sailed, but K/V-vs-no-K...

> No, they are not the same. This is especially relevant if wallets are using a BIP21 library: my wallet supports new address type abc1xxxx, which (according to your proposal)...

> While certainly not perfect, I think this is better than the alternative of whitelisting a set of addresses that are allowed in a root in this BIP and requiring...

> Effectively, this is what you get with my proposal: This is unrelated to the K/V/no-K/V discussion. We can get it either way. > The only distinction is newer bech32m...

> I’m a bit on the fence regarding this PR. There clearly exists a divergence of the practical use from the specification, and it makes sense to address this and...