Hi Thomas, I thought it would be interesting to specify this in details, to figure out the potential subtleties. I did that in a gist [1], that I plan to turn into a bLIP after writing some prototype code for it.
Feel free to comment, either on the gist or here. Cheers, Bastien [1] https://gist.github.com/t-bast/69018875f4f95e660ec2cbbc80f711a6 Le mar. 20 juin 2023 à 19:17, Steve Lee <steven.j....@gmail.com> a écrit : > > > On Tue, Jun 20, 2023 at 6:17 AM Thomas Voegtlin <thom...@electrum.org> > wrote: > >> >> >> We have not implemented BOLT-12 yet in Electrum. Would you care to >> describe whether bundled payments already would work with the current >> specification, or whether they would require changes to BOLT-12? We >> are going to implement BOLT-12 support in Electrum in the coming >> months, and I would be happy to help here. >> >> > Fantastic news! > > >> I believe that it will take years *after it is merged*, until BOLT-12 >> actually becomes the dominant payment method on Lightning. OTOH, if >> this feature was adopted in BOLT-11, I think it could be deployed much >> faster. >> >> > Why do you think it will be adopted faster? History has shown that any > upgrade requiring wallets to change takes years even if it is a small > change to an existing design. For example, despite only requiring a tiny > change, there is still not widespread bech32m support [1]. Bech32/native > segwit support also took years. > > [1] http://whentaproot.com/ > > >> >> cheers, >> >> Thomas >> >> >> >> >> >> On 15.06.23 11:01, Bastien TEINTURIER 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 <thom...@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@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@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@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
