Re: [Lightning-dev] Proposal: Bundled payments
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 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
Re: [Lightning-dev] Proposal: Bundled payments
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 b
