Add silentpayments logic

[Sosthene00]

I needed to parse Silent Payments address inscribed in DNS record according to the BIP353 specification, I think that's rather straightforward the only thing I'm not quite sure of is support for testnet/signet sp addresses. Opening it as a draft for now

[TheBlueMatt]

Hmm, what's the status of upstreaming address parsing into rust-bitcoin? I presume it could be upstreamed without support for broader SP payment support to get it done here.

I'm not super excited about adding hex, serde, serde-json, and bimap (which appears to be a single-developer crate) to the transitive dependency set, and I'm not clear on how many wallets will actually support silent payments until it's upstreamed anyway.

[TheBlueMatt]

GitHub won't let me comment on the diff (man it's gone to shit) but you should maybe also handle req-sp, I imagine? Though the semantics of that are maybe somewhat ill-defined if it's not the only address (I guess it means "you have to support parsing this but you can choose to not use it"?)

[Sosthene00]

Thanks for your quick feedback, I'll try to answer each point as best as I can:

what's the status of upstreaming address parsing into rust-bitcoin?

I took a look and afaict it hasn't been moving for a while and I don't think there's anything usable by now.

I'm not super excited about adding hex, serde, serde-json, and bimap (which appears to be a single-developer crate) to the transitive dependency set

Yes totally agree, as a temporary solution waiting for upstream address parsing in rust-bitcoin I can try to rethink how things are done in rust-silentpayments to reduce transitive dependencies at bare minimum?

you should maybe also handle req-sp, I imagine?

Yes actually to be honest I was indeed a little confused about that, so I decided to let it aside. I think if we signal a silent payment address in payment instructions we are unlikely to add a static fallback address anyway, but that would be totally possible and legitimate to have both sp and lno, but then we shouldn't make any of them req?

[TheBlueMatt]

I took a look and afaict it hasn't been moving for a while and I don't think there's anything usable by now.

I assume this is because they're waiting on the secp256k1 silent payments module? Are there any wallets using/likely to use the rust-silentpayments crate before its upstream in rust-bitcoin?

Yes totally agree, as a temporary solution waiting for upstream address parsing in rust-bitcoin I can try to rethink how things are done in rust-silentpayments to reduce transitive dependencies at bare minimum?

Yea, or even just a subcrate that only does address parsing and none of the other logic, which rust-silentpayments can then depend on. That subcrate would presumably only depend on bech32 or so.

[TheBlueMatt]

I think if we signal a silent payment address in payment instructions we are unlikely to add a static fallback address anyway

Depends a lot on the wallet, I imagine, though indeed some folks will want to avoid a fallback.

but that would be totally possible and legitimate to have both sp and lno, but then we shouldn't make any of them req?

I guess? The spec says Query parameter keys which are prefixed with a req- are considered required. If a client does not implement handling a query parameter which has a key prefixed with req-, it MUST consider the entire URI invalid.. I read that to mean "if you understand how to parse the given query parameter, great, even if you don't use it, that's fine. So we should happily read silent payments with a req- prefix.