Re: [Lightning-dev] Proposal: Bundled payments
I think the ship has probably sailed on getting any kind of new interoperable change in to BOLT-11. We already can't get amount-less BOLT-11 invoices broadly supported, rolling out yet another new incompatible version of BOLT-11 and expecting the entire ecosystem to support it doesn't seem all that likely. If we're working towards specifying some "standard" way of doing swaps, (a) I'd be curious to understand why the need isn't obviated by splice-out, and (b) why it shouldn't be built on OMs so you can do it more privately. Matt On 6/13/23 1:10 AM, Thomas Voegtlin 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
Re: [Lightning-dev] Proposal: Bundled payments
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 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:
Re: [Lightning-dev] Proposal: Bundled payments
> 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 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
