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
