Steve Lee [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-20 🗒️ Summary of this message: Electrum plans ...
đź“… Original date posted:2023-06-20
🗒️ Summary of this message: Electrum plans to implement BOLT-12 support in the coming months, but the author believes it may take years for it to become the dominant payment method on Lightning.
đź“ť Original message:
On Tue, Jun 20, 2023 at 6:17 AM Thomas Voegtlin <thomasv at 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 <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
> >>
> >
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230620/df9efe13/attachment-0001.html>;
🗒️ Summary of this message: Electrum plans to implement BOLT-12 support in the coming months, but the author believes it may take years for it to become the dominant payment method on Lightning.
đź“ť Original message:
On Tue, Jun 20, 2023 at 6:17 AM Thomas Voegtlin <thomasv at 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 <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
> >>
> >
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230620/df9efe13/attachment-0001.html>;