Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-14 🗒️ Summary of this message: Proposing an ...
📅 Original date posted:2023-06-14
🗒️ Summary of this message: Proposing an extension to BOLT-11 for bundled payments to address prepayment of mining fees for non-custodian exchanges. However, getting a new interoperable change into BOLT-11 seems unlikely.
📝 Original message:
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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
🗒️ Summary of this message: Proposing an extension to BOLT-11 for bundled payments to address prepayment of mining fees for non-custodian exchanges. However, getting a new interoperable change into BOLT-11 seems unlikely.
📝 Original message:
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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev