Expand InputType with new variant: Bolt12 offer

[ok300]

This PR extends the input parsed in sdk-common to recognize Bolt12 offers.

[ok300]

@hydra-yse your older PR #598 parses the offer to more detailed fields:

breez-sdk-greenlight/libs/sdk-bindings/src/breez_sdk.udl

Lines 735 to 755 in ad384b1

	[Enum]
	interface Amount {
	Bitcoin(u64 amount_msat);
	Currency(string iso4217_code, u64 fractional_amount);
	};
	dictionary LNOffer {
	string bolt12;
	sequence<string> chains;
	string description;
	string signing_pubkey;
	Amount? amount;
	u64? absolute_expiry;
	string? issuer;
	};
	[Enum]
	interface InputType {
	BitcoinAddress(BitcoinAddressData address);
	Bolt11(LNInvoice invoice);
	Bolt12Offer(LNOffer offer);

As that PR is still in review, I'm not sure if that structure is final (LNOffer, InputType::Bolt12Offer(LNOffer offer)).

So would you say we need those fields as defined there? If so, I can integrate them in this PR.

[dangeross]

So would you say we need those fields as defined there? If so, I can integrate them in this PR

I think they are needed, we need to parse the offer for the user. I also think our PR struct is out of date and I would suggest bumping the lightning/lightning-invoice dependencies. The current version doesn't parse offers according to the latest spec (e.g. the description field is now optional), which I think is not compatible with Phoenix

[JssDWt]

As that PR is still in review, I'm not sure if that structure is final (LNOffer, InputType::Bolt12Offer(LNOffer offer)).

So would you say we need those fields as defined there? If so, I can integrate them in this PR.

Also keep in mind there are invoice requests and invoices in bolt12, next to offers. We don't have to support them, but let's make the interface in such a way that we don't have to break anything to support them in the future.

[ok300]

I tried to bump lightning and lightning-invoice as suggested above. Indeed we would need them to support optional descriptions, like in the Bolt12 invoices from Boltz.

However due to inter-dependencies between crates, this means also updating bech32, bip21, bitcoin crates. This results in two problems:

• The change becomes huge (>100 individual errors) and it needs careful review and extensive tests because it touches critical places.
• There appear to be unfixable conflicts with structs and methods used in node_api.rs, since it relies on the old (current) lightning, lightning_invoice and bitcoin versions to interface with gl-client.

(This is reflected in the last commit f0d19cc . Almost half the errors are fixed, but I stopped when realizing the node_api issue.)

The only way to avoid the above is to store the unparsed Bolt12 option as String in the InputParser::Bolt12 variant.

Another option is to ask GL to update their lightning, lightning-invoice and bitcoin crates to the newer ones we would use, but I don't know how feasible that is.

Am I missing something? Do you see a simpler way to bump lightning and lightning-invoice?

[ok300]

As discussed, this is adding a simple Bolt12Offer { offer: String } variant, until gl-client supports the newer lightning and lightning-invoice crates.

In addition, Liquid SDK will attempt to parse the offer locally.

[dangeross]

LGTM

[hydra-yse]

Should we also add parsing for recurrence- and quantity based fields, or are those outside the scope of what will be used? Perhaps they can be added later as they seem useless for now. Besides that, looking good! 👍

[ok300]

IMO it's best to add them when they will also be tested and used.