Matt Corallo

LGTM, basically, feel free to squash. I do find the `issuer` terminology to be super confusing, though - after this PR I can do `InvoiceRequest.issuer_signing_pubkey()` and get back a pubkey...

Why not just use method names that make sense in both contexts? That seems like a bunch of effort to avoid picking a more descriptive name :).

> Some reason given in https://github.com/lightningdevkit/rust-lightning/pull/3218#discussion_r1715748116. I agree with the comments there, but I don't think it specifically argues for "issuer". > It's also inconsistent with other offer field names....

To be clear, we also don't necessarily need to figure it out now - we already use "issuer" to describe the `Offer` creator, so using it again is fine, I...

Needs rebase.

We should probably see how things go with the new gossip - there's been some discussions to add this as a formal part of gossip in the new gossip format,...

Yea, so my thinking here is basically we just wrap a "normal" pathfinding attempt with `(sending_amount - delta)` as the receive amount, or maybe even sending-amount, and then we recalculate...

Yes, the goal would be to send as much as you're allowed to, which would be balance - channel reserve, presumably across all channels. Indeed, may need to fix #1126...

Hmm, maybe? Its still a failed payment and we still need to "punish" the node, however. For RGS users this can get hit sometimes, but best to punish that channel...

> Hm, but munching all the metrics together could really mess with the assumptions of our (historical) liquidity estimation, no? Kinda? I mean, yes, we're learning that we can't send...