Open tnull opened 1 month ago
Right, so the {Route,Payment}Parameters
abstractions don't make any sense in a BOLT 12 world. They also don't really make sense in a BOLT 11 world if we pass a Bolt11Invoice
directly to ChannelManager
(which we should do now that lightning
depends on lightning-invoice
).
So I think this tees us up for a nice patchset - define some new struct which captures the options you describe, pass it to pay_for_offer
and use that + the BOLT 12 invoice to build an initial RouteParameters
, then do the same on the BOLT 11 side - drop lightning::ln::bolt11_payment
and replace it with a Channelmanager
method that does the same thing as the BOLT 12 path, just with BOLT 11 and the new parameters struct.
Giving this a shot! 🚀
For BOLT11 we allow to set
RouteParameters
as an argument tosend_payment
. However,pay_for_offer
only allows to setmax_total_routing_fee_msat
, but not other routing-related fields such asmax_total_cltv_expiry_delta
,max_path_count
,max_channel_saturation_power_of_half
.I'm a bit dubious if
pay_for_offer
and paying for refunds should be parametrized byRouteParameters
,PaymentParameters
, or the relevant fields independently, but we should provide a way to set them for BOLT12 payments, too.