📅 Original date posted:2023-06-20
🗒️ Summary of this message: A proposal for Lightning Network payments involves potentially three entities, including a swap service provider, and requires updates to existing software used by senders. A submarine swap scenario is used as an example.
📝 Original message:
Hi Thomas, Bastien, and list,
One point I would like to stress for this idea, is that there are potentially three different entities at play in these payments.
This might not be obvious at first glance especially for the submarine swap example, where people expect just two entities: the user ("customer") and the server ("swap provider"). Bastien already hinted at this, but I just want to make it very explicit that this is a (or perhaps *the*) use case here.
> First of all, I'd like to highlight something that may not be obvious
> from your email, and is actually pretty important: your proposal
> requires *senders* to be aware that the payment will lead to a channel
> creation (or a splice) on the *receiver* end. In particular, it requires
> all existing software used by senders to be updated.
In particular, for the submarine swap scenario, consider Alice, a new user with a freshly installed wallet, who generates an invoice as they want to receive some money onchain; and Bob, who wants to pay that invoice via Lightning. There are three entities: Alice, a swap service provider (server), and Bob. Only Alice knows about the swap server being there.
Alice needs client-side logic for doing a swap; and Bob needs to implement Thomas' proposal (or equivalent), i.e. parsing an invoice that can convey two payment hashes and one corresponding amount each, one pair being used as a "prepayment".
Using a swap service, Bob could pay Alice, so that Bob pays on Lightning, and Alice receives onchain:
- Alice generates a preimage and calculates its hash RHASH1, for the actual ("large") amount1 Alice wants to receive
- Alice contacts the swap server via e.g. HTTP, providing RHASH1 and amount1
- the swap server generates another preimages and its hash RHASH2, for the small prepayment amount2
- the swap server generates a lightning invoice, and puts (RHASH1, amount1) and (RHASH2, amount2) in it, and sends it back to Alice
- Alice checks the lightning invoice, e.g. verifies that it includes the expected amounts and RHASH1
- Alice now gives the invoice to Bob, using some side-channel, as typical
- Bob does not need to know that the nodeid signing the ln invoice does not belong to Alice, etc
- Bob sees that the invoice contains two payment hashes and amounts, and sends HTLCs to cover both
- the HTLCs arrive at the swap server, who holds them and waits until it sees HTLCs with enough offered money for both the prepayment (RHASH2) and the main payment (RHASH1)
- the server has the preimage for RHASH2 (but not RHASH1), so it now fulfills the HTLCs for the prepayment
- the server creates a swap funding tx onchain paying to a locking script redeemable by the preimage of RHASH1 - the mining fees for this and the service fee has already been paid by the fulfilled HTLCs for RHASH2
- Alice sees the swap funding tx onchain, and waits until it gets mined. Alice also validates that it is the expected script, and the timeout for the refund path is not too short, etc.
- Alice broadcasts a claim tx spending the funding tx output using the preimage for RHASH1
- the server fulfills the still pending HTLCs for RHASH1 using this preimage
Note that Bob is a simple lightning wallet, with the only added assumption that his wallet is able to parse/pay this new type of LN invoice that contains two hashes. All the security checks and swap logic is only implemented on Alice's side. A clear drawback though is that Bob, paying lightning, expects the payment to go through fast, but will end up waiting for onchain txs getting mined (which he does not know or need to know about).
Also note that instead of this special bolt11 invoice (or maybe bolt12 offer), Alice could create a bip21 URI instead, containing both an onchain address and the lightning invoice. This way, Alice would still receive onchain, but now Bob has the choice of either paying onchain or via lightning.
---
Besides swaps, the other clear use case is JIT channels. Analogous to the above swap example, Alice could negotiate with the service provider to have a JIT channel opened to her, and the HTLC forwarded using that. Alice can wait for the channel funding to be mined before releasing the preimage for the main payment (RHASH1) by fulfilling the HTLC offchain.
Bob is completely agnostic to what happens between the service provider and Alice. The only thing visible is the long time it takes for the HTLC to get fulfilled. (though if Alice opted-in not to wait for confirmations and trust the server, the delay could be removed)
If Alice waits for confirmations, in both the swap and the JIT channel scenarios, the server is only trusted with the prepayment amount.
Regards,
ghost43 / SomberNight
------- Original Message -------
On Thursday, June 15th, 2023 at 09:01, Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Hi Thomas,
>
> First of all, I'd like to highlight something that may not be obvious
> from your email, and is actually pretty important: your proposal
> requires *senders* to be aware that the payment will lead to a channel
> creation (or a splice) on the *receiver* end. In particular, it requires
> all existing software used by senders to be updated. For this reason, I
> think extending Bolt 12 (which requires new sender code anyway) makes
> more sense than updating Bolt 11.
>
> I see only three strategies to provide JIT liquidity (by opening a new
> channel or making a splice, I'll only use the open channel case below
> for simplicity):
>
> 1. Ask receiver for the preimage and a fee, then open a channel and
> push the HTLC amount minus the fee
> 2. Open a channel, then forward the HTLC amount minus a fee
> 3. Pre-pay fee, then open a channel and forward the whole HTLC amount
> on that channel
>
> What is currently deployed on the network is 1) and 2), while you're
> proposing 3). Both 1) and 2) have the advantages that the sender doesn't
> need to be aware that JIT liquidity is happening, and doesn't need to do
> anything special for that payment, which is the main reason those
> strategies were chosen.
>
> If all you're concerned about is trust and regulation, solution 2) works
> fine as long as the mempool isn't empty: if the user doesn't release the
> preimage after you've opened the channel, you should just blacklist that
> channel, reject payments made to it, and double-spend it whenever you
> have another on-chain transaction to make (and use 1 sat/byte for JIT
> liquidity transactions). Even if the mempool is empty, if your LSP has
> transactions to make at every block, it's likely that it will succeed
> at double-spending the faulty channel, and thus won't lose anything.
>
> But I agree that this only works when coupled with 0-conf. If we're not
> using 0-conf anymore, pre-paying fees would make more sense. But we will
> likely keep on using 0-conf at least until Bolt 12 is deployed, so it
> seems more reasonable to include this new feature in Bolt 12 rather than
> Bolt 11, since all implementations are actively working on this?
>
> Cheers,
> Bastien
>
> Le jeu. 15 juin 2023 à 10:52, Thomas Voegtlin <thomasv at electrum.org> a écrit :
>
> > Hello Matt,
> >
> > I think it is not too late to add a new feature to BOLT-11. In any
> > case, the belief that BOLT-11 is ossified should not be a reason to
> > make interactive something that fundamentally does not require more
> > interactivity than what BOLT-11 already offers. Technical decisions
> > should be dictated by technical needs, and I am a minimalist when it
> > comes to adding new messages to protocols.
> >
> > I believe that two major implementations have an incentive to support
> > this proposal (although I cannot speak for them):
> > - Lightning Labs could potentially offer their Loop service to
> > non-LND users.
> > - ACINQ would be able to open channels to Phoenix users without
> > requesting the preimage first. This would put them on the safe side
> > of the upcoming MICA regulation; I cannot emphasize enough how
> > important that is.
> >
> > In addition, you could certainly decide to support that feature in
> > LDK, and I can speak for Electrum :-)
> >
> > It is the first time I suggest a change to the Lightning protocol, and
> > what I am proposing is really a tiny change. All we need is a new
> > invoice feature, that describes the prepayment of a fee using a
> > different preimage. This feature does not need to be set on all
> > invoices, and it could be made optional during a transition period.
> >
> > Here is how that feature could possibly made optional:
> > - a new feature bit is defined, BUNDLE_PREPAYMENT
> > - two extra fields are defined: prepayment_amount, prepayment_hash
> > - if the sender does not support BUNDLE_PREPAYMENT and the feature is
> > optional, it ignores the new fields
> > - if the sender support BUNDLE_PREPAYMENT:
> > - sender sends (amount - prepayment_amount) with payment_hash
> > - sender sends prepayment_amount with prepayment_hash
> >
> > The decision to make this feature required or optional remains with
> > the service provider. I can see how submarine swap providers who are
> > already exposed to the mining fee griefing attack could decide to make
> > it optional for a transition period.
> >
> > cheers,
> > Thomas
> >
> >
> > Regarding your question (a) about the distinction between splice-out
> > and submarine swaps: Submarine swaps make it possible to add receiving
> > capacity to a channel.
> >
> >
> >
> >
> > On 14.06.23 19:28, Matt Corallo wrote:
> > > 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
> >
> > --
> > 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
SomberNight [ARCHIVE] /
npub1r3…f8xs3
2023-06-20 23:25:30
in reply to nevent1q…d2m2
Author Public Key
npub1r3wz0qhmtp77ddyvm98wpy4zsta0k5ash8ejndqjp6s8epnx5plq2f8xs3Published at
2023-06-20 23:25:30Event JSON
{
"id": "55e416c498cc6a6d921aa088a8a7e21235e47e1a47d33b32a1b3cf29ad1f4eaa",
"pubkey": "1c5c2782fb587de6b48cd94ee092a282fafb53b0b9f329b4120ea07c8666a07e",
"created_at": 1687303530,
"kind": 1,
"tags": [
[
"e",
"043a2b35dbcb1356289d59114e00fee40fb32cc69bf8e3d2ab2d8da4ebc027ca",
"",
"root"
],
[
"e",
"706265e97bdcc9aad870b578e945f8ed9191dff3334dcd929c4c87717350b57d",
"",
"reply"
],
[
"p",
"187d1b2536d3c9a7ee875c4ca256b1e8e9ff67697d15b26d8d0fd20f9431bfac"
]
],
"content": "📅 Original date posted:2023-06-20\n🗒️ Summary of this message: A proposal for Lightning Network payments involves potentially three entities, including a swap service provider, and requires updates to existing software used by senders. A submarine swap scenario is used as an example.\n📝 Original message:\nHi Thomas, Bastien, and list,\n\nOne point I would like to stress for this idea, is that there are potentially three different entities at play in these payments.\nThis might not be obvious at first glance especially for the submarine swap example, where people expect just two entities: the user (\"customer\") and the server (\"swap provider\"). Bastien already hinted at this, but I just want to make it very explicit that this is a (or perhaps *the*) use case here.\n\n\u003e First of all, I'd like to highlight something that may not be obvious\n\u003e from your email, and is actually pretty important: your proposal\n\u003e requires *senders* to be aware that the payment will lead to a channel\n\u003e creation (or a splice) on the *receiver* end. In particular, it requires\n\u003e all existing software used by senders to be updated.\n\nIn particular, for the submarine swap scenario, consider Alice, a new user with a freshly installed wallet, who generates an invoice as they want to receive some money onchain; and Bob, who wants to pay that invoice via Lightning. There are three entities: Alice, a swap service provider (server), and Bob. Only Alice knows about the swap server being there.\nAlice needs client-side logic for doing a swap; and Bob needs to implement Thomas' proposal (or equivalent), i.e. parsing an invoice that can convey two payment hashes and one corresponding amount each, one pair being used as a \"prepayment\".\n\nUsing a swap service, Bob could pay Alice, so that Bob pays on Lightning, and Alice receives onchain:\n- Alice generates a preimage and calculates its hash RHASH1, for the actual (\"large\") amount1 Alice wants to receive\n- Alice contacts the swap server via e.g. HTTP, providing RHASH1 and amount1\n- the swap server generates another preimages and its hash RHASH2, for the small prepayment amount2\n- the swap server generates a lightning invoice, and puts (RHASH1, amount1) and (RHASH2, amount2) in it, and sends it back to Alice\n- Alice checks the lightning invoice, e.g. verifies that it includes the expected amounts and RHASH1\n- Alice now gives the invoice to Bob, using some side-channel, as typical\n- Bob does not need to know that the nodeid signing the ln invoice does not belong to Alice, etc\n- Bob sees that the invoice contains two payment hashes and amounts, and sends HTLCs to cover both\n- the HTLCs arrive at the swap server, who holds them and waits until it sees HTLCs with enough offered money for both the prepayment (RHASH2) and the main payment (RHASH1)\n- the server has the preimage for RHASH2 (but not RHASH1), so it now fulfills the HTLCs for the prepayment\n- the server creates a swap funding tx onchain paying to a locking script redeemable by the preimage of RHASH1 - the mining fees for this and the service fee has already been paid by the fulfilled HTLCs for RHASH2\n- Alice sees the swap funding tx onchain, and waits until it gets mined. Alice also validates that it is the expected script, and the timeout for the refund path is not too short, etc.\n- Alice broadcasts a claim tx spending the funding tx output using the preimage for RHASH1\n- the server fulfills the still pending HTLCs for RHASH1 using this preimage\n\nNote that Bob is a simple lightning wallet, with the only added assumption that his wallet is able to parse/pay this new type of LN invoice that contains two hashes. All the security checks and swap logic is only implemented on Alice's side. A clear drawback though is that Bob, paying lightning, expects the payment to go through fast, but will end up waiting for onchain txs getting mined (which he does not know or need to know about).\n\nAlso note that instead of this special bolt11 invoice (or maybe bolt12 offer), Alice could create a bip21 URI instead, containing both an onchain address and the lightning invoice. This way, Alice would still receive onchain, but now Bob has the choice of either paying onchain or via lightning.\n\n---\n\nBesides swaps, the other clear use case is JIT channels. Analogous to the above swap example, Alice could negotiate with the service provider to have a JIT channel opened to her, and the HTLC forwarded using that. Alice can wait for the channel funding to be mined before releasing the preimage for the main payment (RHASH1) by fulfilling the HTLC offchain.\n\nBob is completely agnostic to what happens between the service provider and Alice. The only thing visible is the long time it takes for the HTLC to get fulfilled. (though if Alice opted-in not to wait for confirmations and trust the server, the delay could be removed)\n\nIf Alice waits for confirmations, in both the swap and the JIT channel scenarios, the server is only trusted with the prepayment amount.\n\nRegards,\nghost43 / SomberNight\n\n\n\n------- Original Message -------\nOn Thursday, June 15th, 2023 at 09:01, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e wrote:\n\n\n\u003e Hi Thomas,\n\u003e \n\u003e First of all, I'd like to highlight something that may not be obvious\n\u003e from your email, and is actually pretty important: your proposal\n\u003e requires *senders* to be aware that the payment will lead to a channel\n\u003e creation (or a splice) on the *receiver* end. In particular, it requires\n\u003e all existing software used by senders to be updated. For this reason, I\n\u003e think extending Bolt 12 (which requires new sender code anyway) makes\n\u003e more sense than updating Bolt 11.\n\u003e \n\u003e I see only three strategies to provide JIT liquidity (by opening a new\n\u003e channel or making a splice, I'll only use the open channel case below\n\u003e for simplicity):\n\u003e \n\u003e 1. Ask receiver for the preimage and a fee, then open a channel and\n\u003e push the HTLC amount minus the fee\n\u003e 2. Open a channel, then forward the HTLC amount minus a fee\n\u003e 3. Pre-pay fee, then open a channel and forward the whole HTLC amount\n\u003e on that channel\n\u003e \n\u003e What is currently deployed on the network is 1) and 2), while you're\n\u003e proposing 3). Both 1) and 2) have the advantages that the sender doesn't\n\u003e need to be aware that JIT liquidity is happening, and doesn't need to do\n\u003e anything special for that payment, which is the main reason those\n\u003e strategies were chosen.\n\u003e \n\u003e If all you're concerned about is trust and regulation, solution 2) works\n\u003e fine as long as the mempool isn't empty: if the user doesn't release the\n\u003e preimage after you've opened the channel, you should just blacklist that\n\u003e channel, reject payments made to it, and double-spend it whenever you\n\u003e have another on-chain transaction to make (and use 1 sat/byte for JIT\n\u003e liquidity transactions). Even if the mempool is empty, if your LSP has\n\u003e transactions to make at every block, it's likely that it will succeed\n\u003e at double-spending the faulty channel, and thus won't lose anything.\n\u003e \n\u003e But I agree that this only works when coupled with 0-conf. If we're not\n\u003e using 0-conf anymore, pre-paying fees would make more sense. But we will\n\u003e likely keep on using 0-conf at least until Bolt 12 is deployed, so it\n\u003e seems more reasonable to include this new feature in Bolt 12 rather than\n\u003e Bolt 11, since all implementations are actively working on this?\n\u003e \n\u003e Cheers,\n\u003e Bastien\n\u003e \n\u003e Le jeu. 15 juin 2023 à 10:52, Thomas Voegtlin \u003cthomasv at electrum.org\u003e a écrit :\n\u003e \n\u003e \u003e Hello Matt,\n\u003e \u003e \n\u003e \u003e I think it is not too late to add a new feature to BOLT-11. In any\n\u003e \u003e case, the belief that BOLT-11 is ossified should not be a reason to\n\u003e \u003e make interactive something that fundamentally does not require more\n\u003e \u003e interactivity than what BOLT-11 already offers. Technical decisions\n\u003e \u003e should be dictated by technical needs, and I am a minimalist when it\n\u003e \u003e comes to adding new messages to protocols.\n\u003e \u003e \n\u003e \u003e I believe that two major implementations have an incentive to support\n\u003e \u003e this proposal (although I cannot speak for them):\n\u003e \u003e - Lightning Labs could potentially offer their Loop service to\n\u003e \u003e non-LND users.\n\u003e \u003e - ACINQ would be able to open channels to Phoenix users without\n\u003e \u003e requesting the preimage first. This would put them on the safe side\n\u003e \u003e of the upcoming MICA regulation; I cannot emphasize enough how\n\u003e \u003e important that is.\n\u003e \u003e \n\u003e \u003e In addition, you could certainly decide to support that feature in\n\u003e \u003e LDK, and I can speak for Electrum :-)\n\u003e \u003e \n\u003e \u003e It is the first time I suggest a change to the Lightning protocol, and\n\u003e \u003e what I am proposing is really a tiny change. All we need is a new\n\u003e \u003e invoice feature, that describes the prepayment of a fee using a\n\u003e \u003e different preimage. This feature does not need to be set on all\n\u003e \u003e invoices, and it could be made optional during a transition period.\n\u003e \u003e \n\u003e \u003e Here is how that feature could possibly made optional:\n\u003e \u003e - a new feature bit is defined, BUNDLE_PREPAYMENT\n\u003e \u003e - two extra fields are defined: prepayment_amount, prepayment_hash\n\u003e \u003e - if the sender does not support BUNDLE_PREPAYMENT and the feature is\n\u003e \u003e optional, it ignores the new fields\n\u003e \u003e - if the sender support BUNDLE_PREPAYMENT:\n\u003e \u003e - sender sends (amount - prepayment_amount) with payment_hash\n\u003e \u003e - sender sends prepayment_amount with prepayment_hash\n\u003e \u003e \n\u003e \u003e The decision to make this feature required or optional remains with\n\u003e \u003e the service provider. I can see how submarine swap providers who are\n\u003e \u003e already exposed to the mining fee griefing attack could decide to make\n\u003e \u003e it optional for a transition period.\n\u003e \u003e \n\u003e \u003e cheers,\n\u003e \u003e Thomas\n\u003e \u003e \n\u003e \u003e \n\u003e \u003e Regarding your question (a) about the distinction between splice-out\n\u003e \u003e and submarine swaps: Submarine swaps make it possible to add receiving\n\u003e \u003e capacity to a channel.\n\u003e \u003e \n\u003e \u003e \n\u003e \u003e \n\u003e \u003e \n\u003e \u003e On 14.06.23 19:28, Matt Corallo wrote:\n\u003e \u003e \u003e I think the ship has probably sailed on getting any kind of new interoperable change in to BOLT-11.\n\u003e \u003e \u003e\n\u003e \u003e \u003e 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.\n\u003e \u003e \u003e\n\u003e \u003e \u003e 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.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Matt\n\u003e \u003e \u003e\n\u003e \u003e \u003e On 6/13/23 1:10 AM, Thomas Voegtlin wrote:\n\u003e \u003e \u003e\u003e Good morning list,\n\u003e \u003e \u003e\u003e\n\u003e \u003e \u003e\u003e I would like to propose an extension to BOLT-11, where an invoice can contain two bundled payments, with distinct preimages and amounts.\n\u003e \u003e \u003e\u003e\n\u003e \u003e \u003e\u003e The use case is for services that require the prepayment of a mining fee in order for a non-custodian exchange to take place:\n\u003e \u003e \u003e\u003e - Submarine swaps\n\u003e \u003e \u003e\u003e - JIT channels\n\u003e \u003e \u003e\u003e\n\u003e \u003e \u003e\u003e 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.\n\u003e \u003e \u003e\u003e\n\u003e \u003e \u003e\u003e 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.\n\u003e \u003e \u003e\u003e\n\u003e \u003e \u003e\u003e 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.\n\u003e \u003e \u003e\u003e\n\u003e \u003e \u003e\u003e In order to solve that, it would be beneficial to bundle the prepayment and the main payment in the same BOLT-11 invoice.\n\u003e \u003e \u003e\u003e\n\u003e \u003e \u003e\u003e The semantics of bundled payments is as follows:\n\u003e \u003e \u003e\u003e - 1. the BOLT-11 invoice contains two preimages and two amounts: prepayment and main payment.\n\u003e \u003e \u003e\u003e - 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.\n\u003e \u003e \u003e\u003e - 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.\n\u003e \u003e \u003e\u003e\n\u003e \u003e \u003e\u003e Of course, nothing in my proposal prevents the service provider from stealing the pre-payment, but that is already the case today.\n\u003e \u003e \u003e\u003e\n\u003e \u003e \u003e\u003e 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.\n\u003e \u003e \u003e\u003e\n\u003e \u003e \u003e\u003e 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.\n\u003e \u003e \u003e\u003e\n\u003e \u003e \u003e\u003e Cheers,\n\u003e \u003e \u003e\u003e ThomasV\n\u003e \u003e \u003e\u003e _______________________________________________\n\u003e \u003e \u003e\u003e Lightning-dev mailing list\n\u003e \u003e \u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e \n\u003e \u003e --\n\u003e \u003e Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany\n\u003e \u003e Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636\n\u003e \u003e Geschäftsführer: Thomas Voegtlin\n\u003e \u003e _______________________________________________\n\u003e \u003e Lightning-dev mailing list\n\u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "d85ef43a882cda8d1bca7b61e919a9426f09d7ddfe100f50e8c78395fe689774bcead4f2cc42b8bc5a7ce29911e687479517e18b4900414343fce4ff5680bcad"
}