cln-bip353: add plugin that fetches payment instructions from human readable addresses

[daywalker90]

Changelog-Add: new plugin cln-bip353 that can fetch payment instructions from human readable addresses

Important

25.09 FREEZE July 28TH: Non-bugfix PRs not ready by this date will wait for 25.12.

RC1 is scheduled on August 11th

The final release is scheduled for September 1st.

Adds a new rpc command fetchbip353 [address] that fetches payment instructions from a bip-353 address and returns an object containing:

• proof: lowercase hex encoded proof
• instructions: An array of bip353 payment instruction objects

These objects either contain an onchain instruction:

• onchain: a bitcoin address
• onchain_amount_sat: an optional amount for fixed amount payments
• description: an optional description provided by the recipient

or an offchain instruction:

• offer: a bolt12 offer string
• offchain_amount_msat: an optional amount for fixed amount payments
• description: an optional description provided by the recipient

Fixes: #8361

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

• The changelog has been updated in the relevant commit(s) according to the guidelines.
• Tests have been added or modified to reflect the changes.
• Documentation has been reviewed and updated as needed.
• Related issues have been listed and linked, including any that this PR closes.

[daywalker90]

Added a basic test with the same address the library uses in it's tests. Let me know if you have more addresses you'd like to see tested.

Also updated the bitcoin_payment_instructions library to an unreleased version that supports proxying and implemented proxying incase always_use_proxy is set.

For documentation i've added a json schema file.

I have reworked the reponse structure a bit to also support onchain instructions.

[rustyrussell]

Great! The always-use-proxy was my only question on this PR.

Ack d669e6f

[daywalker90]

rebased after merge of wss-proxy which created some conflicts.

[daywalker90]

I had the dependency lock wrong: the keyword is rev not commit. Would be nice to get a new release on crates.io for bitcoin-payment-instructions @TheBlueMatt

[TheBlueMatt]

If you're using the HTTPResolver you may get an LNURL instruction instead. It might be worth trying to do onion message resolution instead of HTTP resolution to a global DNS service. What does the plugin architecture look like on the CLN side for sending an onion message? After rust-bitcoin/bitcoin-payment-instructions#7 (and maybe one other PR to take a DNS-resolving node by node-id instead of doing a scan of the LDK network graph structure) you should be able to do a resolve, then poll release_pending_messages, get back a DNSSECQuery bLIP-32 message and a "context" (for your purposes some bytes that need to be shoved in the reply path that is included when the onion message is sent). From there, when we get back a bLIP-32 DNSSECProof message (and the context that was included in the blinded path) you can call handle_dnssec_proof and the original async resolution should complete.

If you're interested in giving this a go I'm happy to add the ability to provide a resolver node rather than relying on the LDK network graph.

[daywalker90]

@rustyrussell can we do that with injectonionmessage? If so do you want me to change it to use the onion-based resolver? I'm a bit concerned about latency/reliability. In my gossip store there are currently 11 nodes which have the dns_resolver flag set. 2 of those were offline, 8 tor only and 1 clearnet/tor hybrid.

If you're using the HTTPResolver you may get an LNURL instruction instead

The fact that we can get LNURL instructions via the HTTP resolver should not be important since we just skip them.

and maybe one other PR to take a DNS-resolving node by node-id instead of doing a scan of the LDK network graph structure

I've skimmed over the tests for that new resolver and i saw that currently you are loading the whole graph in there, that would be quite slow here and so yes we would need such a PR

you should be able to do a resolve, then poll release_pending_messages, get back a DNSSECQuery bLIP-32 message and a "context" (for your purposes some bytes that need to be shoved in the reply path that is included when the onion message is sent). From there, when we get back a bLIP-32 DNSSECProof message (and the context that was included in the blinded path) you can call handle_dnssec_proof and the original async resolution should complete

I understood about 10% of that (yet). I'm not that familiar with onion messaging.

If you're interested in giving this a go I'm happy to add the ability to provide a resolver node rather than relying on the LDK network graph.

Can you elaborate? You want me to hard-code in your node for resolving DNS queries instead of searching the graph for the dns_resolver flag?

[TheBlueMatt]

In my gossip store there are currently 11 nodes which have the dns_resolver flag set. 2 of those were offline, 8 tor only and 1 clearnet/tor hybrid.

If you filter them properly I think it's only my personal node :( https://github.com/rust-bitcoin/bitcoin-payment-instructions/blob/main/src/onion_message_resolver.rs#L149

[TheBlueMatt]

Can you elaborate? You want me to hard-code in your node for resolving DNS queries instead of searching the graph for the dns_resolver flag?

No, you'd scan CLN's graph db and provide the nodes you want to use to resolve to the resolver logic.

[rustyrussell]

Doing an onion based resolver is a whole other plugin, TBH. Maybe next release...