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
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
