plugins/offers_invreq_hook.h

#ifndef LIGHTNING_PLUGINS_OFFERS_INVREQ_HOOK_H
#define LIGHTNING_PLUGINS_OFFERS_INVREQ_HOOK_H
#include "config.h"
#include <plugins/libplugin.h>

/* We got an onionmessage with an invreq! */
struct command_result *handle_invoice_request(struct command *cmd,
					      const u8 *invreqbin,
					      struct blinded_path *reply_path STEALS,
					      const struct secret *secret TAKES);
#endif /* LIGHTNING_PLUGINS_OFFERS_INVREQ_HOOK_H */
plugins/offers: add code to catch invoice_request onion messages. We prepare an invoice, but there's no code to send an error reply yet (future patch). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 2020-12-16 13:43:32 +10:30			`#ifndef LIGHTNING_PLUGINS_OFFERS_INVREQ_HOOK_H`
			`#define LIGHTNING_PLUGINS_OFFERS_INVREQ_HOOK_H`
			`#include "config.h"`
			`#include <plugins/libplugin.h>`

			`/* We got an onionmessage with an invreq! */`
			`struct command_result handle_invoice_request(struct command cmd,`
common: remove support for pre v0.10.2 onionmessages. Temporarily disable sendpay_blinding test which uses obsolete onionmsg; there's still some debate on the PR about how blinded HTLCs will work. Changelog-EXPERIMENTAL: onionmessage: removed support for v0.10.1 onion messages. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 2021-11-30 13:36:04 +10:30			`const u8 *invreqbin,`
offers: check they use the blinded path if one is specified. Now we can specify a blinded path in an offer, we have to check they used it (or didn't use it, if we didn't have one!). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 2024-07-17 12:53:25 +09:30			`struct blinded_path *reply_path STEALS,`
			`const struct secret *secret TAKES);`
plugins/offers: add code to catch invoice_request onion messages. We prepare an invoice, but there's no code to send an error reply yet (future patch). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 2020-12-16 13:43:32 +10:30			`#endif /* LIGHTNING_PLUGINS_OFFERS_INVREQ_HOOK_H */`