Multi-trampoline multipart payments

[bitromortac]

Based on #7426 (first four commits) and partially fixes #7604, related to #7648.

• Refactored create_trampoline_route.
• Enables end-to-end multi-trampoline multipart payments. Trampoline-to-legacy payments are still not enabled, as this is currently not supported by Eclair.
• Reintroduces a global trampoline fee level.

[bitromortac]

Rebased.

[SomberNight]

• Removes all second-hop trampoline forwarders for the legacy case, as trampoline failures are currently not handled properly, see (Many trampoline payment attempts due to wrong TrampolineFeeInsufficient attribution #7648), with the downside of removing some privacy (not much, there are only three trampolines), but the upside of improvements in sending reliability.
• In the e2e case, we sometimes need two trampoline forwarders, e.g., when the two endpoints are connected to different trampolines. We cannot know about which of the two trampoline fee levels should be bumped on insufficient fee error, therefore we revert to a global fee level and bump both (which doubles the fees).

Why remove the second hop TF for the legacy case -- can't we just use the same approach as for e2e and revert to a global fee level?

[bitromortac]

Why remove the second hop TF for the legacy case -- can't we just use the same approach as for e2e and revert to a global fee level?

My impression is that currently it takes many attempts to make larger payments, with quite a few fee bumps involved.

The is some dynamics between random choice of second forwarder and insufficient fees which gets doubled up if we consider a global policy. I don't know if the next makes fully sense (for say a 1Msat payment) or if there are other edge cases, there could be more fee bumps:

two TF scenario (kind of worst case):

• Route: TF1 -> TF2 -> Receiver
  Fee is insufficient for T1 -> T2, bump fee level
• Route TF1 -> TF3 -> Receiver
  Fee is insufficient for T1 -> T3, bump fee level
• Route TF1 -> TF2 -> Receiver
  Fee is insufficient for T2 -> Receiver, bump fee level
• Route TF1 -> TF3 -> Receiver
  Fee is insufficient for TF3 -> Receiver, bump fee level

fee level: 4 -> 0.001000 * 1_000_000 sat = 1000 sat -> 2000 sat

single TF scenario:

• Route: TF1 -> Receiver
  Fee is insufficient for T1 -> Receiver, bump fee level
• Route: TF1 -> Receiver
  Fee is insufficient for T1 -> Receiver, bump fee level

fee level: 2 -> 0.000100 * 1_000_000 sat = 100 sat

Of course there's a tradeoff between reliability, fees, payment time and privacy. I didn't make many large trampoline payments but from my experience they seemed rather unreliable.

[ecdsa]

@bitromortac can you clarify in the example above, whether those are MPPs or sequential attempts?

[bitromortac]

@bitromortac can you clarify in the example above, whether those are MPPs or sequential attempts?

Those would be sequential attempts, but considering the fee_level dict, going back to a global fee level could fix things, as you wrote.

[bitromortac]

I reverted to a global fee rate and added the second forwarder again for legacy payments.

[ecdsa]

The PR looks good to me.
One question, though: the pay-to-open-feature-bit branch on ACINQ seems to only add the feature bits, but I do not see how it inhibits the pay-to-open behaviour if a client does not have the feature bit.

[bitromortac]

I will explicitly test again an e2e payment to a wallet with a channel which has not enough receiving capacity with ACINQ and will let you know.

[ecdsa]

I tested myself, it looks like the ACINQ node no longer tries pay-to-open on Electrum clients.