Matt Corallo

Right, so basically there's no point in splitting by dust/non-dust because we're not longer going to be able to rely on the order of the HTLCSources in the update, and...

Needs rebase.

ISTM a lot of this confusion comes because we have one `BlindedPath` type to handle two totally different things - payment blinded paths and messaging blinded paths. Should we split...

> would be somewhat annoying to serialize Wait, why? We can just have a wrapper and nothing else, the code wouldn't have to change?

> I guess the wrapper just wouldn't implement Writeable. Hmm? The wrappers would presumably implement the same thing that the current `BlindedPath` implements, and the current `BlindedPath` would be an...

Okay, then payment paths wouldn't implement `Writeable`? Don't really see why splitting the paths into two structs poses more issues than the current API of only having one.

``` error: public documentation for `next_blinding_override` links to private item `BlindedPath` --> lightning/src/blinded_path/payment.rs:204:20 | 204 | /// Set if this [`BlindedPath`] is concatenated to another, to indicate the | ^^^^^^^^^^^...

``` error[E0063]: missing field `next_blinding_override` in initializer of `ForwardTlvs` --> src/invoice_request_deser.rs:104:9 | 104 | tlvs: ForwardTlvs { | ^^^^^^^^^^^ missing `next_blinding_override` error[E0063]: missing field `next_blinding_override` in initializer of `ForwardTlvs` -->...

Hmm, I'm somewhat at a loss for why MPP was used here at all, honestly. `max_channel_saturation_power_of_half` is ignored for first- and last- hops, but the remaining hops in the first...

Can you post your full patch against the router? It looks like at a minimum your logs are different from what exists upstream (eg your log says `First hop through...