LSPS2: Prepayment probing breaks flow

[johncantrell97]

If the app used to pay the JIT channel invoice does prepayment probing it will successfully trigger the htlc_intercepted => OpenChannel event => ChannelReady and attempt to forward the probe. When the app goes to send the actual payment we will get htlc_intercepted again but this time the library will throw an error because the OutboundJITChannelState is not in the AwaitingPayment state anymore.

Haven't looked into best way to handle this.

I think at a high level we will either need to allow htlc_intercepted to happen when the channel is already ready and allow it to be forwarded OR detect the failed probe and rollback channel state so the subsequent htlc can be routed as if it was the first.

[tnull]

Well, generally we know that LSPS2 is broken in the face of pre-payment probing, which is one of the arguments why we should move on to LSPS4 ASAP.

That said, we probably need to accept/handle HTLCs coming in via the intercept ID anyways, as the spec says:

LSPs MUST consider the jit_channel_scid as yet another alias for the specified client, up to until the valid_until time selected.

https://github.com/BitcoinAndLightningLayerSpecs/lsp/tree/main/LSPS2#6--post-opening-normal-operation

[johncantrell97]

Fixed by #102