Re: [Lightning-dev] Proposal: Bundled payments
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 a écrit : > > > On Tue, Jun 20, 2023 at 6:17 AM Thomas Voegtlin > 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 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
Re: [Lightning-dev] Proposal: Bundled payments
On Tue, Jun 20, 2023 at 6:17 AM Thomas Voegtlin 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 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:
Re: [Lightning-dev] Proposal: Bundled payments
On 6/20/23 1:45 AM, Thomas Voegtlin wrote: - snip - 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? They will not as-specified, but because BOLT12 offers are reusable you will be able to scan a single offer and send two payments as long as the sender implements this. We are going to implement BOLT-12 support in Electrum in the coming months, and I would be happy to help here. Great to hear that! I believe that it will take years *after it is merged*, until BOLT-12 actually becomes the dominant payment method on Lightning. Absolutely true. OTOH, if this feature was adopted in BOLT-11, I think it could be deployed much faster. I'm not sure why? Indeed, BOLT-12 has some time to go in terms of getting off the ground floor, as it were, but a new BOLT-11 extension has to start from 0 - with zero implementations today and, worse, having to convince people to actually care enough to implement it. At least with BOLT-12 a client that is "swap-aware" you don't have to scan two QR codes or do any complicated dance. The goal of my proposal is to level the field of competition between Lightning service providers, by allowing reverse submarine swap payments to come from any wallet (of course, a dedicated client will still be needed to verify the redeem script and the invoice, and to sweep the funds, as discussed above) I admit I still kinda struggle to see the value here - the user has to have a "swap-aware" client doing the swap setup and enforcement, but then can have any lightning wallet pay it. So it only really makes sense if the user has an on-chain wallet they want to use which is distinct from their lightning wallet (and their lightning wallet doesn't support splice-out, which presumably most will in a year or so). This seems like quite a narrow set of requirements to me. Matt ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal: Bundled payments
Hi Thomas, Bastien, and list,
One point I would like to stress for this idea, is that there are potentially
three different entities at play in these payments.
This might not be obvious at first glance especially for the submarine swap
example, where people expect just two entities: the user ("customer") and the
server ("swap provider"). Bastien already hinted at this, but I just want to
make it very explicit that this is a (or perhaps *the*) use case here.
> 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.
In particular, for the submarine swap scenario, consider Alice, a new user with
a freshly installed wallet, who generates an invoice as they want to receive
some money onchain; and Bob, who wants to pay that invoice via Lightning. There
are three entities: Alice, a swap service provider (server), and Bob. Only
Alice knows about the swap server being there.
Alice needs client-side logic for doing a swap; and Bob needs to implement
Thomas' proposal (or equivalent), i.e. parsing an invoice that can convey two
payment hashes and one corresponding amount each, one pair being used as a
"prepayment".
Using a swap service, Bob could pay Alice, so that Bob pays on Lightning, and
Alice receives onchain:
- Alice generates a preimage and calculates its hash RHASH1, for the actual
("large") amount1 Alice wants to receive
- Alice contacts the swap server via e.g. HTTP, providing RHASH1 and amount1
- the swap server generates another preimages and its hash RHASH2, for the
small prepayment amount2
- the swap server generates a lightning invoice, and puts (RHASH1, amount1) and
(RHASH2, amount2) in it, and sends it back to Alice
- Alice checks the lightning invoice, e.g. verifies that it includes the
expected amounts and RHASH1
- Alice now gives the invoice to Bob, using some side-channel, as typical
- Bob does not need to know that the nodeid signing the ln invoice does not
belong to Alice, etc
- Bob sees that the invoice contains two payment hashes and amounts, and sends
HTLCs to cover both
- the HTLCs arrive at the swap server, who holds them and waits until it sees
HTLCs with enough offered money for both the prepayment (RHASH2) and the main
payment (RHASH1)
- the server has the preimage for RHASH2 (but not RHASH1), so it now fulfills
the HTLCs for the prepayment
- the server creates a swap funding tx onchain paying to a locking script
redeemable by the preimage of RHASH1 - the mining fees for this and the service
fee has already been paid by the fulfilled HTLCs for RHASH2
- Alice sees the swap funding tx onchain, and waits until it gets mined. Alice
also validates that it is the expected script, and the timeout for the refund
path is not too short, etc.
- Alice broadcasts a claim tx spending the funding tx output using the preimage
for RHASH1
- the server fulfills the still pending HTLCs for RHASH1 using this preimage
Note that Bob is a simple lightning wallet, with the only added assumption that
his wallet is able to parse/pay this new type of LN invoice that contains two
hashes. All the security checks and swap logic is only implemented on Alice's
side. A clear drawback though is that Bob, paying lightning, expects the
payment to go through fast, but will end up waiting for onchain txs getting
mined (which he does not know or need to know about).
Also note that instead of this special bolt11 invoice (or maybe bolt12 offer),
Alice could create a bip21 URI instead, containing both an onchain address and
the lightning invoice. This way, Alice would still receive onchain, but now Bob
has the choice of either paying onchain or via lightning.
---
Besides swaps, the other clear use case is JIT channels. Analogous to the above
swap example, Alice could negotiate with the service provider to have a JIT
channel opened to her, and the HTLC forwarded using that. Alice can wait for
the channel funding to be mined before releasing the preimage for the main
payment (RHASH1) by fulfilling the HTLC offchain.
Bob is completely agnostic to what happens between the service provider and
Alice. The only thing visible is the long time it takes for the HTLC to get
fulfilled. (though if Alice opted-in not to wait for confirmations and trust
the server, the delay could be removed)
If Alice waits for confirmations, in both the swap and the JIT channel
scenarios, the server is only trusted with the prepayment amount.
Regards,
ghost43 / SomberNight
--- Original Message ---
On Thursday, June 15th, 2023 at 09: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
Re: [Lightning-dev] Proposal: Bundled payments
Hi Thomas, > I believe pre-payment of the mining fee can be combined with 0-conf; > I am not sure why you picture them as opposed? Even with BOLT-12, I > don't see 0-conf going away. Sorry if that was unclear, that's not at all what I meant. What I meant is that if we *stopped* using 0-conf for some reason, the solution I described wouldn't work anymore and we would have to use a prepayment. > Would you care to describe whether bundled payments already would > work with the current specification, or whether they would require > changes to BOLT-12? That would require adding a TLV field to Bolt 12 invoices, or a TLV field to onion messages. The design space for a prepayment solution based on Bolt 12 is larger than with Bolt 11: I believe we can come up with a more satisfying protocol. > 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. I'm not sure why you think it would be faster using Bolt 11? It does require all sender and receiver software to be updated, and implementers are currently focused on Bolt 12 so I find it less likely that they will prioritize work on extensions to Bolt 11 (but I could be wrong). > The goal of my proposal is to level the field of competition between > Lightning service providers I agree that it would be great to have a more satisfying solution than what currently exists, but this is not a reason to rush it. I think it's worth trying to build this on top of Bolt 12, where we can probably do something cleaner since invoices are delivered on-the-fly and short-lived. Thanks, Bastien Le mar. 20 juin 2023 à 10:47, Thomas Voegtlin a écrit : > Hello Dave, > > That is an interesting idea; it would indeed save space for the prepayment > hash. > I think the invoice would still need a feature bit, so that the receiver > can > decide to make prepayment optional or required. > > Note that for the feature to be optional, we need to subtract the > prepayment > amount from the main payment amount. Thus, in your example, Alice would > expect > to receive either: > (1 BTC, invoice payment_hash) > or: > (1 BTC - minus 10k sats, invoice payment_hash) + (10k sats, > prepayment_hash via keysend) > > cheers > > Thomas > > > > > On 19.06.23 22:29, David A. Harding wrote: > > On 2023-06-12 22:10, Thomas Voegtlin wrote: > >> 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. > > > > Hi Thomas, > > > > Do you actually require a BOLT11 invoice to contain a payment hash for > > the prepayment, or would it be acceptable for the prepayment to use a > > keysend payment with the onion message payload for the receiver > > indicating what payment hash to associate with the prepayment (e.g., > > Alice wants to receive 1 BTC to hash 0123...cdef with a prepayment of > > 10k sats, so the 10k sats is sent via keysend with metadata indicating > > the receiver shouldn't claim it until they receive the 1 BTC HTLC to > > 0123...cdef). > > > > If so, I think then you'd only need BOLT11 invoices to be extended with > > an extra_fee_via_keysend field. That would be significantly smaller and > > it also allows encoding the extra_fee_via_keysend field in an existing > > BOLT11 field like (d) description or the relatively new (m) metadata > > field, which may allow immediate implementation until an updated version > > of BOLT11 (or an alternative using offers) becomes widely deployed. > > > > Thanks, > > > > -Dave > > -- > 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
Re: [Lightning-dev] Proposal: Bundled payments
Hello Bastien, Thank you for the clarification; indeed I might not have been clear about the fact that senders need to understand the new fields. What you are suggesting (solution 2, blacklisting non-cooperative clients and playing with the mempool) is prone to griefing attacks and it requires manpower and infrastructure not necessarily affordable by small companies. I would also be surprised if that is the approach used by ACINQ. I believe pre-payment of the mining fee can be combined with 0-conf; I am not sure why you picture them as opposed? Even with BOLT-12, I don't see 0-conf going away. 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. 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. The goal of my proposal is to level the field of competition between Lightning service providers, by allowing reverse submarine swap payments to come from any wallet (of course, a dedicated client will still be needed to verify the redeem script and the invoice, and to sweep the funds, as discussed above), and by allowing JIT channels to be provided by companies who do not distribute a dedicated wallet that trusts them. In this context, making this proposal happen earlier rather than later could have a significant impact on the shape of the ecosystem. It remains to be seen how this is understood by everybody. 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 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
Re: [Lightning-dev] Proposal: Bundled payments
Hello Dave, That is an interesting idea; it would indeed save space for the prepayment hash. I think the invoice would still need a feature bit, so that the receiver can decide to make prepayment optional or required. Note that for the feature to be optional, we need to subtract the prepayment amount from the main payment amount. Thus, in your example, Alice would expect to receive either: (1 BTC, invoice payment_hash) or: (1 BTC - minus 10k sats, invoice payment_hash) + (10k sats, prepayment_hash via keysend) cheers Thomas On 19.06.23 22:29, David A. Harding wrote: On 2023-06-12 22:10, Thomas Voegtlin wrote: 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. Hi Thomas, Do you actually require a BOLT11 invoice to contain a payment hash for the prepayment, or would it be acceptable for the prepayment to use a keysend payment with the onion message payload for the receiver indicating what payment hash to associate with the prepayment (e.g., Alice wants to receive 1 BTC to hash 0123...cdef with a prepayment of 10k sats, so the 10k sats is sent via keysend with metadata indicating the receiver shouldn't claim it until they receive the 1 BTC HTLC to 0123...cdef). If so, I think then you'd only need BOLT11 invoices to be extended with an extra_fee_via_keysend field. That would be significantly smaller and it also allows encoding the extra_fee_via_keysend field in an existing BOLT11 field like (d) description or the relatively new (m) metadata field, which may allow immediate implementation until an updated version of BOLT11 (or an alternative using offers) becomes widely deployed. Thanks, -Dave -- 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
Re: [Lightning-dev] Proposal: Bundled payments
On 2023-06-12 22:10, Thomas Voegtlin wrote: 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. Hi Thomas, Do you actually require a BOLT11 invoice to contain a payment hash for the prepayment, or would it be acceptable for the prepayment to use a keysend payment with the onion message payload for the receiver indicating what payment hash to associate with the prepayment (e.g., Alice wants to receive 1 BTC to hash 0123...cdef with a prepayment of 10k sats, so the 10k sats is sent via keysend with metadata indicating the receiver shouldn't claim it until they receive the 1 BTC HTLC to 0123...cdef). If so, I think then you'd only need BOLT11 invoices to be extended with an extra_fee_via_keysend field. That would be significantly smaller and it also allows encoding the extra_fee_via_keysend field in an existing BOLT11 field like (d) description or the relatively new (m) metadata field, which may allow immediate implementation until an updated version of BOLT11 (or an alternative using offers) becomes widely deployed. Thanks, -Dave ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
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
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
Re: [Lightning-dev] Proposal: Bundled payments
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 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org
Re: [Lightning-dev] Proposal: Bundled payments
Of course, a submarine swap client needs to do the proper checks and sweep the funds. In the case of Boltz, their website serves javascript that does that, and they are also distributing a Progressive Web App [1]. I have no idea whether their app is doing all this correctly, my point is rather that it is possible to distribute a submarine swap client that is separate from the lightning wallet of the user, and they are doing just that. This separation between wallet and submarine swap providers is what would enable competition. Lightning Loop could benefit from that, by distributing an app that does not require a local LND instance. This would vastly increase your potential user base. The only ingredient that is missing is the bundling of fee prepayment and main payment in the same invoice. Note that there is an ongoing standardization effort for LSP protocols [2]. My understanding is that Boltz is currently working to add submarine swaps to it. cheers, Thomas [1] https://twitter.com/Boltzhq/status/1668590610998079488 [2] https://github.com/synonymdev/lsp-spec/tree/main On 14.06.23 04:56, Olaoluwa Osuntokun wrote: 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 In order to be properly non-custodial, a submarine swap client needs to be able to unilaterally sweep or timeout an on chain HTLC and also validate all the swap parameters. Assuming I understand this web based flow correctly, it still requires "dedicated logic" on the client side to sweep (reveal the preimage) or timeout the on chain HTLC. If one wishes to avoid the awareness of the subswap itself, then a user would need to manually go to the website in order to obtain a signed sweep transaction (for a Loop Out like sub-swap, so off-chain to on-chain). However, that would still require the wallet to sign the HTLC sweep path, once again requiring dedicated logic. A website could have an option to give a user a signed sweep or refund transaction, but that can't be created until user goes on chain as something like no_input doesn't exist today on mainnet. Even then, a website can let the user act first, then just never give them the necessary signed transaction. In other words: one always requires dedicated logic in order to fully verify the swap parameters and also perform an on-chain sweep/timeout, which is a requirement for a trust minified swap. A user can trust the service to just send to the given address or pay an invoice for them, but that's not a trust minimized swap. -- Laolu On Tue, Jun 13, 2023 at 6:52 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:
Re: [Lightning-dev] Proposal: Bundled payments
> 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 In order to be properly non-custodial, a submarine swap client needs to be able to unilaterally sweep or timeout an on chain HTLC and also validate all the swap parameters. Assuming I understand this web based flow correctly, it still requires "dedicated logic" on the client side to sweep (reveal the preimage) or timeout the on chain HTLC. If one wishes to avoid the awareness of the subswap itself, then a user would need to manually go to the website in order to obtain a signed sweep transaction (for a Loop Out like sub-swap, so off-chain to on-chain). However, that would still require the wallet to sign the HTLC sweep path, once again requiring dedicated logic. A website could have an option to give a user a signed sweep or refund transaction, but that can't be created until user goes on chain as something like no_input doesn't exist today on mainnet. Even then, a website can let the user act first, then just never give them the necessary signed transaction. In other words: one always requires dedicated logic in order to fully verify the swap parameters and also perform an on-chain sweep/timeout, which is a requirement for a trust minified swap. A user can trust the service to just send to the given address or pay an invoice for them, but that's not a trust minimized swap. -- Laolu On Tue, Jun 13, 2023 at 6:52 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
