[Electrum Swap,WEX] Third party client forward swaps require different protocol on swap server side

[dejfcz]

Description

Follow up based on X request https://x.com/ElectrumWallet/status/2048374535578062988 to move the discussion to an issue.

We are trying to expand Electrum Swap ecosystem by creating interface for people who do not use Electrum Wallet. We have released the first public version where we implemented reverse swaps and we would like to support forward swap as well in order to provide complete swap gateway to Electrum Swaps.

The research of forward swaps lead us to discovery of a change in Electrum's implementation (

electrum/electrum/submarine_swaps.py

Line 871 in 9b26c18

Old (removed) flow:

) from an "old flow" (based on standard Bolt11) to a "new flow" (based on HODL invoices).

As we do not have any control of the client's LN wallet and because HODL invoices are not commonly supported by wallets, the new flow does not seem to be viable for us to use. The old flow only requires the user's wallet to be able to generate a standard Bolt11 invoice, so it'd be perfect for us. However, the support for the old flow on the server side has been removed (

electrum/electrum/submarine_swaps.py

Line 1466 in 9b26c18

elif req_type == 'submarine':

) from Electrum's code base.

We would like to ask for ideas on how to reach support for forward swaps.

The only idea we currently have is to reintroduce the server side support for the old flow:

• new extra flag goes into swap announcement, so that we can distinguish providers that we can use for forward swaps from others; this should be backwards compatible with old swap servers and clients, who would still use the old swap announcement and ignore the extra flag
• swap server code would implement both versions of the swap, the new flow that is used by current Electrum swap clients as is, and the old flow, for the purpose of enabling third party access to the ecosystem
• optionally, we could add a setting that could enable/disable the old flow, depending on whether it would be opt-in or opt-out feature

Would Electrum be happy to accept such contribution? Or is there a better solution?

Further, it has been suggested that

Note: If the server uses our protocol (not Boltz), then a reverse swap failing will not result in the user losing fees, because the invoices are bundled.

I am personally unaware of how we could use that. Bundled invoices is something that does not seem to have wide support either. I'd be happy to discuss how we can improve our reverse swap support. Currently, the swap server does not complete the fee invoice before the main swap invoice is also sent, so an honest swap server would not take the fee if the main invoice is not paid. However, a malicious swap server can steal the funds, but the original post I found about this (https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-dev/2023-June/003977.txt) mentions that the theft by malicious provider is not prevented either in case of bundled. Of course, the advantages of having just one invoice are still great, so even if the theft cannot be prevented, we would like to improve the UX. So any help understanding what can be done here would also be appreciated.

[ecdsa]

I am personally unaware of how we could use that. Bundled invoices is something that does not seem to have wide support either. I'd be happy to discuss how we can improve our reverse swap support. Currently, the swap server does not complete the fee invoice before the main swap invoice is also sent, so an honest swap server would not take the fee if the main invoice is not paid. However, a malicious swap server can steal the funds, but the original post I found about this (https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-dev/2023-June/003977.txt) mentions that the theft by malicious provider is not prevented either in case of bundled. Of course, the advantages of having just one invoice are still great, so even if the theft cannot be prevented, we would like to improve the UX. So any help understanding what can be done here would also be appreciated.

Sorry if I was not clear. Electrum swap servers already bundle the two invoices; this simply means that they will not claim the prepayment before the main payment has arrived. Of course a malicious server can steal the prepayment; bundled invoices are not a protocol, it is just internal server logic.

[dejfcz]

Sorry if I was not clear. Electrum swap servers already bundle the two invoices; this simply means that they will not claim the prepayment before the main payment has arrived. Of course a malicious server can steal the prepayment; bundled invoices are not a protocol, it is just internal server logic.

Thank you. Yes, we noticed during testing that the swap server will only complete the fee invoice payment when the main invoice is paid too. So I believe this applies to us as is without any changes.

[ecdsa]

I can see the extra value that supporting the old flow could bring to non-electrum users and swap providers. I guess we could do that.
However:

• other improvements to the submarine swap protocol are also planned (asymmetric fees, taproot); those might be higher priority
• we would need to properly address the fact that users may lose fees because the LN payment fails. This is more likely to be a problem in an ecosystem of small providers than with a single, well connected node.
• if there was a standard for hold invoices (wallet scans qrcode of payment hash in order to create hodl invoice, wallet scans preimage to settle), wouldn't that be better?

[dejfcz]

other improvements to the submarine swap protocol are also planned (asymmetric fees, taproot); those might be higher priority

yes, asymmetric fees would be great and we designed on our end so that we can upgrade easily to this;
taproot we did not do any analysis or preparation, unclear to me what would need to be done, not even if taproot flow would allow for this third party clients that we are focusing on

anyway, we will explore the old forward flow and if we make it working, we can present it to you as a PR or a series of PRs

we would need to properly address the fact that users may lose fees because the LN payment fails. This is more likely to be a problem in an ecosystem of small providers than with a single, well connected node.

we try to inform the user about the risks, even if the amounts at risks are low, so we are in agreement there, it is just about defining what is considered as "properly addressing" - for us it is include it in the documentation as well as warn user on the swap page before they send money

if it is more to you, please specify

if there was a standard for hold invoices (wallet scans qrcode of payment hash in order to create hodl invoice, wallet scans preimage to settle), wouldn't that be better?

sure, that would be amazing, but I can't see that happening any time soon

but when it happens, we can upgrade as well, I don't see it as either-or situation, I rather see it as - start now with what's today and upgrade later if we have better options available