Reintroduce support for the old submarine swap protocol

[MartyIX]

Closes #10611

This PR

• Reintroduces the old v1 flow for submarine swaps.
  • A preliminary check ensures the LN payment route has a high chance of success before proceeding.
• Updates the swap server to signal support for forwardv1 (the old protocol).

Motivation

We've been trying to expand Electrum Swap ecosystem by creating interface – https://whales.exchange – for people who do not use Electrum Wallet. We have released the first public version of https://whales.exchange where we implemented support for reverse swaps. We would like to support forward swap as well in order to provide complete swap gateway to Electrum Swaps.

The current implementation of submarine swaps in Electrum require control over user's LN wallet which https://whales.exchange does not control (see the design). However, Electrum used to implement a different protocol, so called old flow or simply v1 flow, for submarine swaps which did not have the requirement. The old implementation was removed because:

The old flow was removed because servers sometimes fail to find a route for the LN payment, in which case users have to get an on-chain refund (funds locked + mining fees). The new flow cannot be supported with bolt11 invoices; it requires a wallet that supports hold invoices.

This PR attempts to bring back the old flow, so Electrum would support the old and the new submarine protocols. Moreover, to address the above issue, a new preliminary "is-there-a-LN-payment-route" check was added to somewhat mitigate the issue.

A short description of both protocols follows:

Old submarine swap flow (v1) is

• User generates an LN invoice with RHASH, and knows preimage.
• User creates on-chain output locked to RHASH.
• Server checks if there is a LN payment route, otherwise the swap is rejected [new]
• Server pays LN invoice. By completing payment, user reveals preimage.
• Server spends the on-chain output using preimage.

New submarine swap flow is:

• User requests swap (RPC 'createnormalswap')
• Server creates preimage, sends RHASH to user
• User creates hold invoice, sends it to server (RPC 'addswapinvoice')
• Server sends HTLC, user holds it
• User creates on-chain output locked to RHASH
• Server spends the on-chain output using preimage (revealing the preimage)
• User fulfills HTLC using preimage

Discussions

• [Electrum Swap,WEX] Third party client forward swaps require different protocol on swap server side #10611
• https://x.com/ElectrumWallet/status/2048374535578062988

(edit: Rebased to b9be974. Originally, it was based on 9b26c18.)

[SomberNight]

So you are not actually probing? HTLCs are not sent, this is just testing if the offline path finder can create some routes at all.

E.g. if Alice is trying to pay Bob, this is just testing that Alice has enough outbound capacity on the direct channel, and that some path can be found in the graph from Alice to Bob based on the gossip and the invoice r hints only. If Alice is using trampoline, it is checking even less, as Alice does not even have the graph.

Consider that Bob has a channel with the ACINQ node, and Alice has a channel with the "Electrum Trampoline" node. Bob likely only generates a bolt11 invoice if the Bob<->ACINQ channel has liquidity. Similarly, Alice knows if the Alice<->"Electrum Trampoline" channel has liquidity. Whether there is liquidity on any path from "Electrum Trampoline" to ACINQ is not checked here.

[MartyIX]

So you are not actually probing? HTLCs are not sent, this is just testing if the offline path finder can create some routes at all.

Yes, the check is very basic. It was somewhat intentional to get some feedback.

E.g. if Alice is trying to pay Bob, this is just testing that Alice has enough outbound capacity on the direct channel, and that some path can be found in the graph from Alice to Bob based on the gossip and the invoice r hints only. If Alice is using trampoline, it is checking even less, as Alice does not even have the graph.

Consider that Bob has a channel with the ACINQ node, and Alice has a channel with the "Electrum Trampoline" node. Bob likely only generates a bolt11 invoice if the Bob<->ACINQ channel has liquidity. Similarly, Alice knows if the Alice<->"Electrum Trampoline" channel has liquidity. Whether there is liquidity on any path from "Electrum Trampoline" to ACINQ is not checked here.

Thank you for the elaboration. Please help me understand if you find this to be a hard requirement for this PR, or not. I'm not sure how to add this behavior at the moment (perhaps @dejfcz does). If you do know how to add it, any pointer would be very helpful and much appreciated. It would save us time. :)

[dejfcz]

some path can be found in the graph from Alice to Bob based on the gossip

Yes. The suggestion is to start with something trivial, which can later be improved by someone with deeper knowledge of Electrum code base. As it is now, it does prevent accepting swap in some scenarios, but of course full probing would be much better. So it is more about setting up the interface (probe_only parameter) for now.