> 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 >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
