📅 Original date posted:2023-06-15
🗒️ Summary of this message: Thomas Voegtlin proposes a new feature for BOLT-11 to allow for prepayment of fees using a different preimage, which could benefit Lightning Labs and ACINQ. The feature would be optional and could be made available during a transition period. Matt Corallo questions the feasibility of adding a new feature to BOLT-11 and suggests exploring splice-out and building on OMs for more privacy.
📝 Original message:
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
Thomas Voegtlin [ARCHIVE] /
npub10f…7ej47
2023-06-19 17:42:39
in reply to nevent1q…7wct
Author Public Key
npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47Published at
2023-06-19 17:42:39Event JSON
{
"id": "8f5336d5b24bc13dff41d6017d8134b64bb78c70792fa77ac55722167195711f",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1687196559,
"kind": 1,
"tags": [
[
"e",
"043a2b35dbcb1356289d59114e00fee40fb32cc69bf8e3d2ab2d8da4ebc027ca",
"",
"root"
],
[
"e",
"98f60f0cba6e1d0b72bfd6d569c361caf3f45ee121333f81e2b472630890a10d",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2023-06-15\n🗒️ Summary of this message: Thomas Voegtlin proposes a new feature for BOLT-11 to allow for prepayment of fees using a different preimage, which could benefit Lightning Labs and ACINQ. The feature would be optional and could be made available during a transition period. Matt Corallo questions the feasibility of adding a new feature to BOLT-11 and suggests exploring splice-out and building on OMs for more privacy.\n📝 Original message:\nHello Matt,\n\nI think it is not too late to add a new feature to BOLT-11. In any\ncase, the belief that BOLT-11 is ossified should not be a reason to\nmake interactive something that fundamentally does not require more\ninteractivity than what BOLT-11 already offers. Technical decisions\nshould be dictated by technical needs, and I am a minimalist when it\ncomes to adding new messages to protocols.\n\nI believe that two major implementations have an incentive to support\nthis proposal (although I cannot speak for them):\n - Lightning Labs could potentially offer their Loop service to\n non-LND users.\n - ACINQ would be able to open channels to Phoenix users without\n requesting the preimage first. This would put them on the safe side\n of the upcoming MICA regulation; I cannot emphasize enough how\n important that is.\n\nIn addition, you could certainly decide to support that feature in\nLDK, and I can speak for Electrum :-)\n\nIt is the first time I suggest a change to the Lightning protocol, and\nwhat I am proposing is really a tiny change. All we need is a new\ninvoice feature, that describes the prepayment of a fee using a\ndifferent preimage. This feature does not need to be set on all\ninvoices, and it could be made optional during a transition period.\n\nHere is how that feature could possibly made optional:\n - a new feature bit is defined, BUNDLE_PREPAYMENT\n - two extra fields are defined: prepayment_amount, prepayment_hash\n - if the sender does not support BUNDLE_PREPAYMENT and the feature is\n optional, it ignores the new fields\n - if the sender support BUNDLE_PREPAYMENT:\n - sender sends (amount - prepayment_amount) with payment_hash\n - sender sends prepayment_amount with prepayment_hash\n\nThe decision to make this feature required or optional remains with\nthe service provider. I can see how submarine swap providers who are\nalready exposed to the mining fee griefing attack could decide to make\nit optional for a transition period.\n\ncheers,\nThomas\n\n\nRegarding your question (a) about the distinction between splice-out\nand submarine swaps: Submarine swaps make it possible to add receiving\ncapacity to a channel.\n\n\n\n\nOn 14.06.23 19:28, Matt Corallo wrote:\n\u003e I think the ship has probably sailed on getting any kind of new interoperable change in to BOLT-11.\n\u003e \n\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 \n\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 \n\u003e Matt\n\u003e \n\u003e On 6/13/23 1:10 AM, Thomas Voegtlin wrote:\n\u003e\u003e Good morning list,\n\u003e\u003e\n\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\n\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 - Submarine swaps\n\u003e\u003e - JIT channels\n\u003e\u003e\n\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\n\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\n\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\n\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\n\u003e\u003e The semantics of bundled payments is as follows:\n\u003e\u003e - 1. the BOLT-11 invoice contains two preimages and two amounts: prepayment and main payment.\n\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 - 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\n\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\n\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\n\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\n\u003e\u003e Cheers,\n\u003e\u003e ThomasV\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\n\n-- \nElectrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany\nSitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636\nGeschäftsführer: Thomas Voegtlin",
"sig": "63e78ac2898f5219a8998307595e9e25c8d383e247c46f2243fb71a00f13d0044a1e556085bb7785d99b0fbe87e1ca423e31c5cafe46a42067655a23ac9cb632"
}