Of course, a submarine swap client needs to do the proper checks and sweep
the funds. In the case of Boltz, their website serves javascript that does
that, and they are also distributing a Progressive Web App [1]. I have no
idea whether their app is doing all this correctly, my point is rather that
it is possible to distribute a submarine swap client that is separate from
the lightning wallet of the user, and they are doing just that.
This separation between wallet and submarine swap providers is what would
enable competition. Lightning Loop could benefit from that, by distributing
an app that does not require a local LND instance. This would vastly increase
your potential user base. The only ingredient that is missing is the bundling
of fee prepayment and main payment in the same invoice.
Note that there is an ongoing standardization effort for LSP protocols [2]. My
understanding is that Boltz is currently working to add submarine swaps to it.
cheers,
Thomas
[1] https://twitter.com/Boltzhq/status/1668590610998079488
[2] https://github.com/synonymdev/lsp-spec/tree/main
On 14.06.23 04:56, Olaoluwa Osuntokun wrote:
Their website shows an invoice to the user, whose wallet that is agnostic
about the swap, and it would be unpractical for them to show two invoices
to be paid simultaneously
In order to be properly non-custodial, a submarine swap client needs to be
able to unilaterally sweep or timeout an on chain HTLC and also validate all
the swap parameters.
Assuming I understand this web based flow correctly, it still requires
"dedicated logic" on the client side to sweep (reveal the preimage) or
timeout the on chain HTLC. If one wishes to avoid the awareness of the
subswap itself, then a user would need to manually go to the website in
order to obtain a signed sweep transaction (for a Loop Out like sub-swap, so
off-chain to on-chain). However, that would still require the wallet to
sign
the HTLC sweep path, once again requiring dedicated logic. A website could
have an option to give a user a signed sweep or refund transaction, but that
can't be created until user goes on chain as something like no_input doesn't
exist today on mainnet. Even then, a website can let the user act first,
then just never give them the necessary signed transaction.
In other words: one always requires dedicated logic in order to fully verify
the swap parameters and also perform an on-chain sweep/timeout, which is a
requirement for a trust minified swap. A user can trust the service to just
send to the given address or pay an invoice for them, but that's not a trust
minimized swap.
-- Laolu
On Tue, Jun 13, 2023 at 6:52 AM Thomas Voegtlin <thom...@electrum.org>
wrote:
Good morning list,
I would like to propose an extension to BOLT-11, where an invoice can
contain two bundled payments, with distinct preimages and amounts.
The use case is for services that require the prepayment of a mining fee
in order for a non-custodian exchange to take place:
- Submarine swaps
- JIT channels
In both cases, the service provider receives a HTLC for which they do not
have the preimage, have to send funds on-chain (to the channel or submarine
swap funding address), and wait for the client to reveal the preimage when
they claim the payment. Because there is no guarantee that the client will
actually claim the payment, the service providers need to ask prepayment of
mining fees.
In the case of submarine swaps, services that use dedicated client
software, such as Loop by Lightning Labs, can ask for a prepayment, because
their software can handle it (this is called "no show penalty" on the Loop
website). However, competitors who do require a dedicated wallet, not such
as the Boltz exchange, cannot do that. Their website shows an invoice to
the user, whose wallet that is agnostic about the swap, and it would be
unpractical for them to show two invoices to be paid simultaneously. This
creates a situation where Boltz is vulnerable to DoS attacks, where the
attacker forces them to pay on-chain fees.
In the case of JIT channels, providers who want to protect themselves
against this mining fee attack need to ask the preimage of the main payment
before they open the channel. I believe this is what Phoenix does (although
their pay-to-open service is not open-source, so I cannot really check).
The issue is that a service that asks for the preimage first becomes
custodian. From a legal perspective, it does not matter whether they open
the channel immediately after receiving the preimage, the ordering of
events makes their service custodian. In Europe, such a service will fall
within the European MICA regulation. Competitors who refuse to offer
custodian services, such as Electrum, are excluded from that game.
In order to solve that, it would be beneficial to bundle the prepayment
and the main payment in the same BOLT-11 invoice.
The semantics of bundled payments is as follows:
- 1. the BOLT-11 invoice contains two preimages and two amounts:
prepayment and main payment.
- 2. the receiver should wait until all the HTLCs of both payments have
arrived, before they fulfill the HTLCs of the pre-payment. If the main
payment does not arrive, they should fail the pre-payment with a MPP
timeout.
- 3. once the HTLCs of both payments have arrived, the receiver fulfills
the HTLCs of the prepayment, and they broadcast their on-chain transaction.
Note that the main payment can still fail if the sender never reveal the
preimage of the main payment.
Of course, nothing in my proposal prevents the service provider from
stealing the pre-payment, but that is already the case today.
I believe this proposal would level the field in terms of competition
between lightning service providers. Currently, you need to use a dedicated
client in order to use Loop, and competitors who do not have an established
user base running a dedicated client are exposed to the mining fee attack.
I also believe that ACINQ would benefit from this, because it would make it
possible for them to make their pay-to-open service fully non-custodian. My
understanding is that in its current form, the 'pay-to-open' service used
by Phoenix will fall into the scope of the European MICA regulation, which
they should consider as a serious issue.
Finally, I believe that such a change should be implemented in BOLT-11,
and not using BOLT-12 or onion messages. Indeed, my proposal does not
require the exchange of new messages. Some of the initial feedback I
received was that this is a use case for BOLT-12 or OM, but I think that
this is making things unnecessarily complicated. We should not add new
messages when things can be done in a non-interactive way.
Cheers,
ThomasV
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
