vwallace [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-06-30 to 2023-02-27
💬 Posted a total of 5 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 15:12:30

- reply

📅 Original date posted:2023-01-25
🗒️ Summary of this message: Lightning Network researchers seek a solution for offline receivers to create reusable invoices for their LSPs without compromising security. PTLCs may be a solution.
📝 Original message:
Hey all,
The research question still stands, but I wanted to issue a correction to this email –
> However, upon further investigation, it turns out that the current PTLCs design wouldn’t solve this problem: the LSP would be able to steal funds the same as before, see [3].
This is not true: if a regular PTLCs-based invoice generated by the receiver was given out multiple times by the receiver’s LSP, said LSP would not be able to steal the payment funds. This is because payers randomly tweak each hop’s point on every payment attempt, so the receiver’s LSP never learns the invoice’s original secret (unlike with HTLCs, where every hop learns the payment preimage). Further, the LSP would also need to know the sum of the aforementioned per-hop tweaks to steal, and they only know the tweak corresponding to their own hop. See this helpful PTLCs diagram from my teammate Arik: https://imgur.com/a/ZpdbYrt
Note that PTLC invoices when reused still do not provide PoP because the same secret would be revealed to every payer on every payment.
Thanks,
Val
------- Original Message -------
On Tuesday, January 10th, 2023 at 2:41 PM, vwallace <vwallace at protonmail.com> wrote:
> Hi list!
>
> This email is a belated Christmas wishlist for interested researchers to solve an open question in lightning.
>
> For context, recently there’s been some discussion about supporting “async payments”[1]. Supporting this feature would mean that e.g. a mobile noncustodial user would be able to receive payments even if they’re regularly offline. See the linked email and preliminary spec PR[2] for details on this scheme.
>
> The open research question relates to how the sender will get an invoice from the receiver, given that they are offline at sending-time. If the receiver trusts their LSP, this is easy – they’ll give their LSP a bunch of invoices ahead of time, and trust the LSP to never provide the same one twice, since doing this would allow the LSP (or some intermediate node on the path) to steal the funds, due to already knowing the preimage.
>
> This trust isn’t ideal, obviously. In the original ML email[1], the solution presented to this problem is PTLCs. However, upon further investigation, it turns out that the current PTLCs design wouldn’t solve this problem: the LSP would be able to steal funds the same as before, see [3].
>
> Note that even if we don’t want to trust LSPs, this problem doesn’t halt async payment progress entirely: the working solution for now is for the receiver’s LSP to provide a reusable keysend[4] invoice to senders. The current thinking is that BOLT12 invoices will add a feature bit to support keysend, and the recipient’s BOLT12 offer will direct senders to its LSP to retrieve the keysend invoice. This isn’t ideal because it loses the proof-of-payment property, but it seems OK as a stopgap.
>
> So more specifically, the research question is: what is a scheme that allows a regularly-offline receiver to create a reusable invoice for their LSP to provide to senders, such that senders have proof-of-payment? This may ideally be built on top of PTLCs. **Note that while the recipient may be offline when the sender initiates the payment, the recipient will come back online some time later to fulfill the incoming payment.**
>
> A possible direction suggested by BlueMatt could be to stick with keysend, but have the sender encode a nonce + the time they sent the payment + the payment amount as a tweak to the keysend PTLC point (as well as in the onion), and make the receiver tweak their point with the same data when fulfilling the payment. Such a scheme may force the receiver to commit to the sender-encoded data[5], which wouldn’t exactly provide proof-of-payment, but would allow the sender to prove “I sent X amount at Y time.” Handwave handwave.
>
> Thoughts welcome!
>
> Cheers,
>
> Val
>
> [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
>
> [2]: https://github.com/lightning/bolts/pull/989
>
> [3]: https://github.com/lightning/bolts/pull/989#issuecomment-1325389542
>
> [4]: https://github.com/lightning/blips/blob/master/blip-0003.md
>
> [5]: https://github.com/lightning/bolts/pull/989#issuecomment-1327881563
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230125/5b96b964/attachment.html>

2023-06-09 15:12:29

- reply

📅 Original date posted:2023-01-12
🗒️ Summary of this message: The use of AMP invoices or serving them over LNURL/BOLT12 is equivalent to the keysend scheme, but a spec PR for the AMP reusable invoice format is needed for community feedback. Trampoline payments are critical for async payments, and "invoice tunneling" may be a solution, but changes to the onchain script format may be necessary. PoP is a separate discussion, but having a plan for it in the future would be nice.
📝 Original message:
Hi Laolu,
To your point about AMP – yeah, posting an AMP invoice or serving it over LNURL/BOLT12 seems equivalent to the keysend scheme outlined in my email. The current design is based on BOLT12 because it has broader support. I think others have pointed this out, but it would be useful to see a spec PR for the AMP reusable invoice format rather than high-level API docs, otherwise (a) it’s hard to evaluate using it for async payments and (b) it hasn’t gone through a stage of garnering community feedback.
> one of my key takeaways was that: Trampoline payments are a critical part of any sort of async payment scheme.
100% agreed with this point and explanation; async payments are not very interesting without trampoline.
> "invoice tunneling". The idea is that you force the receiver to reveal a unique secret bound to the invoice or payment attempt.
I would be interested to read more about this, it sounds like it’s thinking along similar lines to Matt’s idea mentioned at the end of my email, which is also outlined in the notes from an async payments meeting[1]. Though if it’s HTLCs-based, then I don’t see how it would work without changes to the onchain script format to commit to additional data, since you can’t change the preimage(?).
Whether PoP is necessary or not seems like a separate discussion to me :p the current HTLCs-based async payments plan does not have the PoP property anyway, but it would be nice to have a plan for how we *could* have it in the future, hence the research wishlist.
-Val
[1]: https://docs.google.com/document/d/1X6Hap9Hi5qJ9a-XVXmLILol2cBcpXExutw6-adPLAb0/edit
------- Original Message -------
On Tuesday, January 10th, 2023 at 5:35 PM, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
> Hi Val,
>
> Happy to see ppl continue to work on the problem space after discussions and
> brainstorming we had at the past LN Summit in Oakland.
>
>> The open research question relates to how the sender will get an invoice
>> from the receiver, given that they are offline at sending-time
>
> One existing protocol extension that solves this is AMP [1][2]. The AMP
> invoice is fully reusable (tho it can expire), and can be posted anywhere on
> the internet, enabling a sender to at least _attempt_ the payment without
> the receiver being online. As the sender is the one that generates the
> pre-image, it's easy to prevent payment hash re-use (generate a new root
> hash, just like you do a shared secret when making an onion). The LSP (or
> anyone else) can't steal the funds, as the pre-image shares are in the final
> hop of the onion payload, which can only be decrypted by the receiver.
>
> Each payment can use the payment_addr/payment_secret field in the
> invoice, but then also generate a new set_id for each logical payment. The
> set_id is included in the final hop payload, which lets the receiver
> aggregate the HTLCs until they can finally settle it after recovering the
> root payment pre-image.
>
> Invoice negotiation protocols such as BOLT 12, LN-URL, and Lightning Address
> can also be used to fetch a self-contained AMP invoice.
>
> Here's a testnet AMP invoice that can be paid w/ any amt:
> ```
> lntb1p3murampp56m9m254s7xduktrm7g6j5r7qrpw9kvzc2tpqul7eskhyqfh95lnqdqqcqzpgxq9z0rgqsp5eyam7wajd3mmwk9qmfthzk3t96s0rklv05tc49ak68p8wvks0cmq9q8pqqqssq3jvnkdqn289fd7l3w2weqps89p9zaan4xlqenj3tmclwwkjgudrzn9jvvmkzgemehrdc7dlg4z7sxu0hmeul55keewqk0kdulc6058qpu644f8
> ```
>
>> such that senders have proof-of-payment? This may ideally be built on top
>> of PTLCs
>
> I can't find the original slides (the old LN Conf URL seems to just redirect
> to the Fulmo website now), but back in the day, Conner gave a talk about an
> AMP extension he called "invoice tunneling". The idea is that you force the
> receiver to reveal a unique secret bound to the invoice or payment attempt.
> Rather than having the set_id be a 32-byte value, it would instead be a
> point and mixed in along all the transmitted partial HTLC shares. In order
> to settle the HTLC, both the secret of the point in the original invoice, as
> well as the sender provided root payment pre-image would be required.
>
> As usual though, I'm pretty dubious of any sort of "proof of payment"
> schemes. Particularly given that virtual no wallets today (UI-wise) give you
> direct access to a pre-image, there's no standard that has emerged yet
> (seemingly due to a lack of an actual need) to encode such information, and
> also most schemes would let any 3rd party that learned the pre-image (an
> intermediate node) to claim that they sent the payment (w/o any other
> asymmetric crypto).
>
> Circling back to the discussion in Oakland, one of my key takeaways was
> that: Trampoline payments are a critical part of any sort of async payment
> scheme. Otherwise, you'll require the sender to be online in a synchronous
> manner as _they're_ the ones that need to retry the payment continually.
>
> With Trampoline payments, the sender's "LSP" can retry the payment at will
> w/o needing to fetch a fresh onion each time. With that the entire flow can
> be async:
>
> 1. user tries initial payment
> 2. LSP gets it, can delay the initial try to "phone home" to the receiver
> 3. HTLC eventually gets the penultimate (second to last hop before the
> receiver)
> 4. Receiver comes online eventually to reveal pre-image
> 5. pre-image propagates backwards thru the route
> 6. sender eventually comes back online again to acknowledge receipt
>
> With the way LN works, once step 4 is reached, then the payment has
> effectively been completed from the PoV of the receiver (UI can update,
> etc). With AMP usage, the receiver also doesn't need to be online for the
> sender to even _attempt_ to make a payment.
>
> -- Laolu
>
> [1]: https://github.com/lightning/bolts/pull/658
> [2]: https://docs.lightning.engineering/lightning-network-tools/lnd/amp
>
> On Tue, Jan 10, 2023 at 11:41 AM vwallace via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Hi list!
>>
>> This email is a belated Christmas wishlist for interested researchers to solve an open question in lightning.
>>
>> For context, recently there’s been some discussion about supporting “async payments”[1]. Supporting this feature would mean that e.g. a mobile noncustodial user would be able to receive payments even if they’re regularly offline. See the linked email and preliminary spec PR[2] for details on this scheme.
>>
>> The open research question relates to how the sender will get an invoice from the receiver, given that they are offline at sending-time. If the receiver trusts their LSP, this is easy – they’ll give their LSP a bunch of invoices ahead of time, and trust the LSP to never provide the same one twice, since doing this would allow the LSP (or some intermediate node on the path) to steal the funds, due to already knowing the preimage.
>>
>> This trust isn’t ideal, obviously. In the original ML email[1], the solution presented to this problem is PTLCs. However, upon further investigation, it turns out that the current PTLCs design wouldn’t solve this problem: the LSP would be able to steal funds the same as before, see [3].
>>
>> Note that even if we don’t want to trust LSPs, this problem doesn’t halt async payment progress entirely: the working solution for now is for the receiver’s LSP to provide a reusable keysend[4] invoice to senders. The current thinking is that BOLT12 invoices will add a feature bit to support keysend, and the recipient’s BOLT12 offer will direct senders to its LSP to retrieve the keysend invoice. This isn’t ideal because it loses the proof-of-payment property, but it seems OK as a stopgap.
>>
>> So more specifically, the research question is: what is a scheme that allows a regularly-offline receiver to create a reusable invoice for their LSP to provide to senders, such that senders have proof-of-payment? This may ideally be built on top of PTLCs. **Note that while the recipient may be offline when the sender initiates the payment, the recipient will come back online some time later to fulfill the incoming payment.**
>>
>> A possible direction suggested by BlueMatt could be to stick with keysend, but have the sender encode a nonce + the time they sent the payment + the payment amount as a tweak to the keysend PTLC point (as well as in the onion), and make the receiver tweak their point with the same data when fulfilling the payment. Such a scheme may force the receiver to commit to the sender-encoded data[5], which wouldn’t exactly provide proof-of-payment, but would allow the sender to prove “I sent X amount at Y time.” Handwave handwave.
>>
>> Thoughts welcome!
>>
>> Cheers,
>>
>> Val
>>
>> [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
>>
>> [2]: https://github.com/lightning/bolts/pull/989
>>
>> [3]: https://github.com/lightning/bolts/pull/989#issuecomment-1325389542
>>
>> [4]: https://github.com/lightning/blips/blob/master/blip-0003.md
>>
>> [5]: https://github.com/lightning/bolts/pull/989#issuecomment-1327881563
>> _______________________________________________
>> 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/20230112/22bf5df0/attachment-0001.html>

2023-06-09 15:12:28

- reply

📅 Original date posted:2023-01-10
🗒️ Summary of this message: Lightning developers are seeking a solution to enable offline receivers to create a reusable invoice for their LSP to provide to senders with proof-of-payment.
📝 Original message:
Hi list!
This email is a belated Christmas wishlist for interested researchers to solve an open question in lightning.
For context, recently there’s been some discussion about supporting “async payments”[1]. Supporting this feature would mean that e.g. a mobile noncustodial user would be able to receive payments even if they’re regularly offline. See the linked email and preliminary spec PR[2] for details on this scheme.
The open research question relates to how the sender will get an invoice from the receiver, given that they are offline at sending-time. If the receiver trusts their LSP, this is easy – they’ll give their LSP a bunch of invoices ahead of time, and trust the LSP to never provide the same one twice, since doing this would allow the LSP (or some intermediate node on the path) to steal the funds, due to already knowing the preimage.
This trust isn’t ideal, obviously. In the original ML email[1], the solution presented to this problem is PTLCs. However, upon further investigation, it turns out that the current PTLCs design wouldn’t solve this problem: the LSP would be able to steal funds the same as before, see [3].
Note that even if we don’t want to trust LSPs, this problem doesn’t halt async payment progress entirely: the working solution for now is for the receiver’s LSP to provide a reusable keysend[4] invoice to senders. The current thinking is that BOLT12 invoices will add a feature bit to support keysend, and the recipient’s BOLT12 offer will direct senders to its LSP to retrieve the keysend invoice. This isn’t ideal because it loses the proof-of-payment property, but it seems OK as a stopgap.
So more specifically, the research question is: what is a scheme that allows a regularly-offline receiver to create a reusable invoice for their LSP to provide to senders, such that senders have proof-of-payment? This may ideally be built on top of PTLCs. **Note that while the recipient may be offline when the sender initiates the payment, the recipient will come back online some time later to fulfill the incoming payment.**
A possible direction suggested by BlueMatt could be to stick with keysend, but have the sender encode a nonce + the time they sent the payment + the payment amount as a tweak to the keysend PTLC point (as well as in the onion), and make the receiver tweak their point with the same data when fulfilling the payment. Such a scheme may force the receiver to commit to the sender-encoded data[5], which wouldn’t exactly provide proof-of-payment, but would allow the sender to prove “I sent X amount at Y time.” Handwave handwave.
Thoughts welcome!
Cheers,
Val
[1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
[2]: https://github.com/lightning/bolts/pull/989
[3]: https://github.com/lightning/bolts/pull/989#issuecomment-1325389542
[4]: https://github.com/lightning/blips/blob/master/blip-0003.md
[5]: https://github.com/lightning/bolts/pull/989#issuecomment-1327881563
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230110/8bab4c04/attachment.html>

2023-06-09 15:08:13

- reply

📅 Original date posted:2023-02-27
📝 Original message:
Hi list!
I wanted to bring up the idea of using onion messages for payment probing, which was briefly touched
on at the 2022 LN summit. Tadge Dryja has also brought up a similar idea.
I recommend reading the gist instead since it has the relevant diagrams in-line:
https://gist.github.com/valentinewallace/ebe1741f0438c2360eda0f80f0e075c9 but the scheme is also
posted below for convenience.
## Introduction
For context, in today’s lightning, payment reliability tends to heavily depend on having sufficient
payment volume to determine current liquidity balances of channels, which is how most big nodes can
tell whether a given channel has enough liquidity to forward a given amount. If a node is using HTLC
probing to achieve this payment volume, they use a regular `update_add_htlc` message with a bogus
payment hash, where the error returned informs the sender of whether the payment reached the final
recipient. Note that there is a tradeoff between always routing through nodes that are known to
rebalance their channels vs leaning on probing smaller nodes and “risking” payments through them
based on what’s learned.
Today’s HTLC payment probing can work well, but risks channel liquidity being locked up if a peer
along the route goes offline. On the upside, for just-in-time probes, it works to loosely “reserve”
the channel liquidity along the route for the actual payment.
Onion messages (OMs) present a convenient way to probe without risking locked liquidity along the
route.
## Design Rationale
A naive approach could be to send onion message probes directly to individual nodes along the
desired route, including those to which you don’t have a direct channel. However, this scheme is
problematic because it would enable monitoring the payment flows of arbitrary nodes across the
network without having to have a channel path to them. This would be a significant degradation of
privacy because, for comparison, in HTLC probing it is quite difficult to probe the balances of
far-off nodes. And if you can’t probe a node using HTLCs, you can’t send over it anyway, so there’s
not a lot of benefit (and significant privacy downside).
Therefore, it is probably best to design a scheme that probes along channel paths, like HTLC
probing. This adds more complexity to the case where an intermediate node cannot forward the desired
amount due to the stateless nature of OMs, discussed further down.
## Scheme
Let’s go through the happy path, where Alice is probing Alice > Bob > Carol > Dave for a 100k msat
payment.
She’ll construct an onion message for Bob, the first hop, as such: https://imgur.com/BZg8yt8
Bob receives this OM, sees that he’s able to forward 110k msats to his next-hop Carol, and forwards
Carol’s onion packet to her. Carol sees she can forward 105k msats to Dave, and forwards his onion
packet. Finally, Dave receives his onion packet, sees he can receive 100k msats from Carol, and uses
the provided reply path to send a simple probe success onion message back to Alice:
```
onion_message_probe_result {
data_tlv {
type: 4242,
probe_id: [u8; 32],
can_forward_desired_amt: true,
}
.. regular OM TLVs
}
```
Note that Dave will use this same onion message if he can’t receive; he’ll just set
`can_forward_desired_amt` to false.
As an example of the sad path for an intermediate node, if Carol can’t forward 105k msats to Dave,
she’ll fail the probe back to Bob by sending this onion message: https://imgur.com/a/hqlzw4I
This step justifies why we need to encode a failure onion for each intermediate hop of a probe. If
we hadn’t done that, and Carol responded to Bob with an empty “failed” message, Bob would have no
idea which peer to fail the probe back to, because OMs are stateless. Instead, Bob unwraps his error
onion and sees that he needs to fail back to Alice with her provided error onion. Alice receives the
failure onion and can see that Carol was not able to forward the desired amount corresponding to the
probe id, thus completing the probe.
## Outro
While there is nothing stopping nodes from lying about their ability to forward, they may be
negatively scored if they do so. Further, adopting a protocol like this could help routing nodes
attract more forwarding traffic, which is a nice incentive.
I view this feature as a low priority enhancement, given there are a lot more pressing issues in LN,
but open to feedback. Mostly, I thought it could be useful to spark ideas and highlight the
flexibility of OMs.
Cheers,
Val
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230227/fe72ef42/attachment.html>

2023-06-09 15:07:53

- reply

📅 Original date posted:2023-01-25
📝 Original message:
Hey all,
The research question still stands, but I wanted to issue a correction to this email –
> However, upon further investigation, it turns out that the current PTLCs design wouldn’t solve this problem: the LSP would be able to steal funds the same as before, see [3].
This is not true: if a regular PTLCs-based invoice generated by the receiver was given out multiple times by the receiver’s LSP, said LSP would not be able to steal the payment funds. This is because payers randomly tweak each hop’s point on every payment attempt, so the receiver’s LSP never learns the invoice’s original secret (unlike with HTLCs, where every hop learns the payment preimage). Further, the LSP would also need to know the sum of the aforementioned per-hop tweaks to steal, and they only know the tweak corresponding to their own hop. See this helpful PTLCs diagram from my teammate Arik: https://imgur.com/a/ZpdbYrt
Note that PTLC invoices when reused still do not provide PoP because the same secret would be revealed to every payer on every payment.
Thanks,
Val
------- Original Message -------
On Tuesday, January 10th, 2023 at 2:41 PM, vwallace <vwallace at protonmail.com> wrote:
> Hi list!
>
> This email is a belated Christmas wishlist for interested researchers to solve an open question in lightning.
>
> For context, recently there’s been some discussion about supporting “async payments”[1]. Supporting this feature would mean that e.g. a mobile noncustodial user would be able to receive payments even if they’re regularly offline. See the linked email and preliminary spec PR[2] for details on this scheme.
>
> The open research question relates to how the sender will get an invoice from the receiver, given that they are offline at sending-time. If the receiver trusts their LSP, this is easy – they’ll give their LSP a bunch of invoices ahead of time, and trust the LSP to never provide the same one twice, since doing this would allow the LSP (or some intermediate node on the path) to steal the funds, due to already knowing the preimage.
>
> This trust isn’t ideal, obviously. In the original ML email[1], the solution presented to this problem is PTLCs. However, upon further investigation, it turns out that the current PTLCs design wouldn’t solve this problem: the LSP would be able to steal funds the same as before, see [3].
>
> Note that even if we don’t want to trust LSPs, this problem doesn’t halt async payment progress entirely: the working solution for now is for the receiver’s LSP to provide a reusable keysend[4] invoice to senders. The current thinking is that BOLT12 invoices will add a feature bit to support keysend, and the recipient’s BOLT12 offer will direct senders to its LSP to retrieve the keysend invoice. This isn’t ideal because it loses the proof-of-payment property, but it seems OK as a stopgap.
>
> So more specifically, the research question is: what is a scheme that allows a regularly-offline receiver to create a reusable invoice for their LSP to provide to senders, such that senders have proof-of-payment? This may ideally be built on top of PTLCs. **Note that while the recipient may be offline when the sender initiates the payment, the recipient will come back online some time later to fulfill the incoming payment.**
>
> A possible direction suggested by BlueMatt could be to stick with keysend, but have the sender encode a nonce + the time they sent the payment + the payment amount as a tweak to the keysend PTLC point (as well as in the onion), and make the receiver tweak their point with the same data when fulfilling the payment. Such a scheme may force the receiver to commit to the sender-encoded data[5], which wouldn’t exactly provide proof-of-payment, but would allow the sender to prove “I sent X amount at Y time.” Handwave handwave.
>
> Thoughts welcome!
>
> Cheers,
>
> Val
>
> [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
>
> [2]: https://github.com/lightning/bolts/pull/989
>
> [3]: https://github.com/lightning/bolts/pull/989#issuecomment-1325389542
>
> [4]: https://github.com/lightning/blips/blob/master/blip-0003.md
>
> [5]: https://github.com/lightning/bolts/pull/989#issuecomment-1327881563
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230125/5b96b964/attachment.html>

2023-06-09 15:07:52

- reply

📅 Original date posted:2023-01-12
📝 Original message:
Hi Laolu,
To your point about AMP – yeah, posting an AMP invoice or serving it over LNURL/BOLT12 seems equivalent to the keysend scheme outlined in my email. The current design is based on BOLT12 because it has broader support. I think others have pointed this out, but it would be useful to see a spec PR for the AMP reusable invoice format rather than high-level API docs, otherwise (a) it’s hard to evaluate using it for async payments and (b) it hasn’t gone through a stage of garnering community feedback.
> one of my key takeaways was that: Trampoline payments are a critical part of any sort of async payment scheme.
100% agreed with this point and explanation; async payments are not very interesting without trampoline.
> "invoice tunneling". The idea is that you force the receiver to reveal a unique secret bound to the invoice or payment attempt.
I would be interested to read more about this, it sounds like it’s thinking along similar lines to Matt’s idea mentioned at the end of my email, which is also outlined in the notes from an async payments meeting[1]. Though if it’s HTLCs-based, then I don’t see how it would work without changes to the onchain script format to commit to additional data, since you can’t change the preimage(?).
Whether PoP is necessary or not seems like a separate discussion to me :p the current HTLCs-based async payments plan does not have the PoP property anyway, but it would be nice to have a plan for how we *could* have it in the future, hence the research wishlist.
-Val
[1]: https://docs.google.com/document/d/1X6Hap9Hi5qJ9a-XVXmLILol2cBcpXExutw6-adPLAb0/edit
------- Original Message -------
On Tuesday, January 10th, 2023 at 5:35 PM, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
> Hi Val,
>
> Happy to see ppl continue to work on the problem space after discussions and
> brainstorming we had at the past LN Summit in Oakland.
>
>> The open research question relates to how the sender will get an invoice
>> from the receiver, given that they are offline at sending-time
>
> One existing protocol extension that solves this is AMP [1][2]. The AMP
> invoice is fully reusable (tho it can expire), and can be posted anywhere on
> the internet, enabling a sender to at least _attempt_ the payment without
> the receiver being online. As the sender is the one that generates the
> pre-image, it's easy to prevent payment hash re-use (generate a new root
> hash, just like you do a shared secret when making an onion). The LSP (or
> anyone else) can't steal the funds, as the pre-image shares are in the final
> hop of the onion payload, which can only be decrypted by the receiver.
>
> Each payment can use the payment_addr/payment_secret field in the
> invoice, but then also generate a new set_id for each logical payment. The
> set_id is included in the final hop payload, which lets the receiver
> aggregate the HTLCs until they can finally settle it after recovering the
> root payment pre-image.
>
> Invoice negotiation protocols such as BOLT 12, LN-URL, and Lightning Address
> can also be used to fetch a self-contained AMP invoice.
>
> Here's a testnet AMP invoice that can be paid w/ any amt:
> ```
> lntb1p3murampp56m9m254s7xduktrm7g6j5r7qrpw9kvzc2tpqul7eskhyqfh95lnqdqqcqzpgxq9z0rgqsp5eyam7wajd3mmwk9qmfthzk3t96s0rklv05tc49ak68p8wvks0cmq9q8pqqqssq3jvnkdqn289fd7l3w2weqps89p9zaan4xlqenj3tmclwwkjgudrzn9jvvmkzgemehrdc7dlg4z7sxu0hmeul55keewqk0kdulc6058qpu644f8
> ```
>
>> such that senders have proof-of-payment? This may ideally be built on top
>> of PTLCs
>
> I can't find the original slides (the old LN Conf URL seems to just redirect
> to the Fulmo website now), but back in the day, Conner gave a talk about an
> AMP extension he called "invoice tunneling". The idea is that you force the
> receiver to reveal a unique secret bound to the invoice or payment attempt.
> Rather than having the set_id be a 32-byte value, it would instead be a
> point and mixed in along all the transmitted partial HTLC shares. In order
> to settle the HTLC, both the secret of the point in the original invoice, as
> well as the sender provided root payment pre-image would be required.
>
> As usual though, I'm pretty dubious of any sort of "proof of payment"
> schemes. Particularly given that virtual no wallets today (UI-wise) give you
> direct access to a pre-image, there's no standard that has emerged yet
> (seemingly due to a lack of an actual need) to encode such information, and
> also most schemes would let any 3rd party that learned the pre-image (an
> intermediate node) to claim that they sent the payment (w/o any other
> asymmetric crypto).
>
> Circling back to the discussion in Oakland, one of my key takeaways was
> that: Trampoline payments are a critical part of any sort of async payment
> scheme. Otherwise, you'll require the sender to be online in a synchronous
> manner as _they're_ the ones that need to retry the payment continually.
>
> With Trampoline payments, the sender's "LSP" can retry the payment at will
> w/o needing to fetch a fresh onion each time. With that the entire flow can
> be async:
>
> 1. user tries initial payment
> 2. LSP gets it, can delay the initial try to "phone home" to the receiver
> 3. HTLC eventually gets the penultimate (second to last hop before the
> receiver)
> 4. Receiver comes online eventually to reveal pre-image
> 5. pre-image propagates backwards thru the route
> 6. sender eventually comes back online again to acknowledge receipt
>
> With the way LN works, once step 4 is reached, then the payment has
> effectively been completed from the PoV of the receiver (UI can update,
> etc). With AMP usage, the receiver also doesn't need to be online for the
> sender to even _attempt_ to make a payment.
>
> -- Laolu
>
> [1]: https://github.com/lightning/bolts/pull/658
> [2]: https://docs.lightning.engineering/lightning-network-tools/lnd/amp
>
> On Tue, Jan 10, 2023 at 11:41 AM vwallace via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Hi list!
>>
>> This email is a belated Christmas wishlist for interested researchers to solve an open question in lightning.
>>
>> For context, recently there’s been some discussion about supporting “async payments”[1]. Supporting this feature would mean that e.g. a mobile noncustodial user would be able to receive payments even if they’re regularly offline. See the linked email and preliminary spec PR[2] for details on this scheme.
>>
>> The open research question relates to how the sender will get an invoice from the receiver, given that they are offline at sending-time. If the receiver trusts their LSP, this is easy – they’ll give their LSP a bunch of invoices ahead of time, and trust the LSP to never provide the same one twice, since doing this would allow the LSP (or some intermediate node on the path) to steal the funds, due to already knowing the preimage.
>>
>> This trust isn’t ideal, obviously. In the original ML email[1], the solution presented to this problem is PTLCs. However, upon further investigation, it turns out that the current PTLCs design wouldn’t solve this problem: the LSP would be able to steal funds the same as before, see [3].
>>
>> Note that even if we don’t want to trust LSPs, this problem doesn’t halt async payment progress entirely: the working solution for now is for the receiver’s LSP to provide a reusable keysend[4] invoice to senders. The current thinking is that BOLT12 invoices will add a feature bit to support keysend, and the recipient’s BOLT12 offer will direct senders to its LSP to retrieve the keysend invoice. This isn’t ideal because it loses the proof-of-payment property, but it seems OK as a stopgap.
>>
>> So more specifically, the research question is: what is a scheme that allows a regularly-offline receiver to create a reusable invoice for their LSP to provide to senders, such that senders have proof-of-payment? This may ideally be built on top of PTLCs. **Note that while the recipient may be offline when the sender initiates the payment, the recipient will come back online some time later to fulfill the incoming payment.**
>>
>> A possible direction suggested by BlueMatt could be to stick with keysend, but have the sender encode a nonce + the time they sent the payment + the payment amount as a tweak to the keysend PTLC point (as well as in the onion), and make the receiver tweak their point with the same data when fulfilling the payment. Such a scheme may force the receiver to commit to the sender-encoded data[5], which wouldn’t exactly provide proof-of-payment, but would allow the sender to prove “I sent X amount at Y time.” Handwave handwave.
>>
>> Thoughts welcome!
>>
>> Cheers,
>>
>> Val
>>
>> [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
>>
>> [2]: https://github.com/lightning/bolts/pull/989
>>
>> [3]: https://github.com/lightning/bolts/pull/989#issuecomment-1325389542
>>
>> [4]: https://github.com/lightning/blips/blob/master/blip-0003.md
>>
>> [5]: https://github.com/lightning/bolts/pull/989#issuecomment-1327881563
>> _______________________________________________
>> 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/20230112/22bf5df0/attachment-0001.html>

2023-06-09 15:07:51

- reply

📅 Original date posted:2023-01-10
📝 Original message:
Hi list!
This email is a belated Christmas wishlist for interested researchers to solve an open question in lightning.
For context, recently there’s been some discussion about supporting “async payments”[1]. Supporting this feature would mean that e.g. a mobile noncustodial user would be able to receive payments even if they’re regularly offline. See the linked email and preliminary spec PR[2] for details on this scheme.
The open research question relates to how the sender will get an invoice from the receiver, given that they are offline at sending-time. If the receiver trusts their LSP, this is easy – they’ll give their LSP a bunch of invoices ahead of time, and trust the LSP to never provide the same one twice, since doing this would allow the LSP (or some intermediate node on the path) to steal the funds, due to already knowing the preimage.
This trust isn’t ideal, obviously. In the original ML email[1], the solution presented to this problem is PTLCs. However, upon further investigation, it turns out that the current PTLCs design wouldn’t solve this problem: the LSP would be able to steal funds the same as before, see [3].
Note that even if we don’t want to trust LSPs, this problem doesn’t halt async payment progress entirely: the working solution for now is for the receiver’s LSP to provide a reusable keysend[4] invoice to senders. The current thinking is that BOLT12 invoices will add a feature bit to support keysend, and the recipient’s BOLT12 offer will direct senders to its LSP to retrieve the keysend invoice. This isn’t ideal because it loses the proof-of-payment property, but it seems OK as a stopgap.
So more specifically, the research question is: what is a scheme that allows a regularly-offline receiver to create a reusable invoice for their LSP to provide to senders, such that senders have proof-of-payment? This may ideally be built on top of PTLCs. **Note that while the recipient may be offline when the sender initiates the payment, the recipient will come back online some time later to fulfill the incoming payment.**
A possible direction suggested by BlueMatt could be to stick with keysend, but have the sender encode a nonce + the time they sent the payment + the payment amount as a tweak to the keysend PTLC point (as well as in the onion), and make the receiver tweak their point with the same data when fulfilling the payment. Such a scheme may force the receiver to commit to the sender-encoded data[5], which wouldn’t exactly provide proof-of-payment, but would allow the sender to prove “I sent X amount at Y time.” Handwave handwave.
Thoughts welcome!
Cheers,
Val
[1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
[2]: https://github.com/lightning/bolts/pull/989
[3]: https://github.com/lightning/bolts/pull/989#issuecomment-1325389542
[4]: https://github.com/lightning/blips/blob/master/blip-0003.md
[5]: https://github.com/lightning/bolts/pull/989#issuecomment-1327881563
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230110/8bab4c04/attachment.html>

2023-06-09 15:06:26

- reply

📅 Original date posted:2022-06-29
📝 Original message:
Heya Laolu,
From my PoV, adding prepayments to onion messages is putting the cart before the horse a bit, think there's a good amount of recourse before resorting to that.
Seems there are two cases to address here:
1. People are trying to stream GoT over lightning
In this case, just rate limiting should disrupt their viewing experience such that it becomes unusable. Don’t think LN can be compared to Tor here because they explicitly want to support this case and we don’t.
2. An attacker is trying to flood the network with OMs
In this case, IMO LN also can’t be compared to Tor because you can limit your OMs to channel partners only, and this in itself provides a “proof of work” that an attacker can’t surmount without actually opening channels.
Another huge win of backpressure is that it only needs to happen in DoS situations, meaning it doesn’t have to impact users in the normal case.
Cheers —Val
------- Original Message -------
On Wednesday, June 29th, 2022 at 8:22 PM, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
> Hi t-bast,
>
> Happy to see this finally written up! With this, we have two classes of
> proposals for rate limiting onion messaging:
>
> 1. Back propagation based rate limiting as described here.
>
> 2. Allowing nodes to express a per-message cost for their forwarding
> services, which is described here [1].
>
> I still need to digest everything proposed here, but personally I'm more
> optimistic about the 2nd category than the 1st.
>
> One issue I see w/ the first category is that a single party can flood the
> network and cause nodes to trigger their rate limits, which then affects the
> usability of the onion messages for all other well-behaving parties. An
> example, this might mean I can't fetch invoices, give up after a period of
> time (how long?), then result to a direct connection (perceived payment
> latency accumulated along the way).
>
> With the 2nd route, if an attacker floods the network, they need to directly
> pay for the forwarding usage themselves, though they may also directly cause
> nodes to adjust their forwarding rate accordingly. However in this case, the
> attacker has incurred a concrete cost, and even if the rates rise, then
> those that really need the service (notifying an LSP that a user is online
> or w/e) can continue to pay that new rate. In other words, by _pricing_ the
> resource utilization, demand preferences can be exchanged, leading to more
> efficient long term resource allocation.
>
> W.r.t this topic, one event that imo is worth pointing out is that a very
> popular onion routing system, Tor, has been facing a severe DDoS attack that
> has lasted weeks, and isn't yet fully resolved [2]. The on going flooding
> attack on Tor has actually started to affect LN (iirc over half of all
> public routing nodes w/ an advertised address are tor-only), and other
> related systems like Umbrel that 100% rely on tor for networking traversal.
> Funnily enough, Tor developers have actually suggested adding some PoW to
> attempt to mitigate DDoS attacks [3]. In that same post they throw around
> the idea of using anonymous tokens to allow nodes to give them to "good"
> clients, which is pretty similar to my lofty Forwarding Pass idea as relates
> to onion messaging, and also general HTLC jamming mitigation.
>
> In summary, we're not the first to attempt to tackle the problem of rate
> limiting relayed message spam in an anonymous/pseudonymous network, and we
> can probably learn a lot from what is and isn't working w.r.t how Tor
> handles things. As you note near the end of your post, this might just be
> the first avenue in a long line of research to best figure out how to handle
> the spam concerns introduced by onion messaging. From my PoV, it still seems
> to be an open question if the same network can be _both_ a reliable
> micro-payment system _and_ also a reliable arbitrary message transport
> layer. I guess only time will tell...
>
>> The `shared_secret_hash` field contains a BIP 340 tagged hash
>
> Any reason to use the tagged hash here vs just a plain ol HMAC? Under the
> hood, they have a pretty similar construction [4].
>
> [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003498.html
> [2]: https://status.torproject.org/issues/2022-06-09-network-ddos/
> [3]: https://blog.torproject.org/stop-the-onion-denial/
> [4]: https://datatracker.ietf.org/doc/html/rfc2104
>
> -- Laolu
>
> On Wed, Jun 29, 2022 at 1:28 AM Bastien TEINTURIER <bastien at acinq.fr> wrote:
>
>> During the recent Oakland Dev Summit, some lightning engineers got together to discuss DoS
>> protection for onion messages. Rusty proposed a very simple rate-limiting scheme that
>> statistically propagates back to the correct sender, which we describe in details below.
>>
>> You can also read this in gist format if that works better for you [1].
>>
>> Nodes apply per-peer rate limits on _incoming_ onion messages that should be relayed (e.g.
>> N/seconds with some burst tolerance). It is recommended to allow more onion messages from
>> peers with whom you have channels, for example 10/seconds when you have a channel and 1/second
>> when you don't.
>>
>> When relaying an onion message, nodes keep track of where it came from (by using the `node_id` of
>> the peer who sent that message). Nodes only need the last such `node_id` per outgoing connection,
>> which ensures the memory footprint is very small. Also, this data doesn't need to be persisted.
>>
>> Let's walk through an example to illustrate this mechanism:
>>
>> * Bob receives an onion message from Alice that should be relayed to Carol
>> * After relaying that message, Bob stores Alice's `node_id` in its per-connection state with Carol
>> * Bob receives an onion message from Eve that should be relayed to Carol
>> * After relaying that message, Bob replaces Alice's `node_id` with Eve's `node_id` in its
>> per-connection state with Carol
>> * Bob receives an onion message from Alice that should be relayed to Dave
>> * After relaying that message, Bob stores Alice's `node_id` in its per-connection state with Dave
>> * ...
>>
>> We introduce a new message that will be sent when dropping an incoming onion message because it
>> reached rate limits:
>>
>> 1. type: 515 (`onion_message_drop`)
>> 2. data:
>> * [`rate_limited`:`u8`]
>> * [`shared_secret_hash`:`32*byte`]
>>
>> Whenever an incoming onion message reaches the rate limit, the receiver sends `onion_message_drop`
>> to the sender. The sender looks at its per-connection state to find where the message was coming
>> from and relays `onion_message_drop` to the last sender, halving their rate limits with that peer.
>>
>> If the sender doesn't overflow the rate limit again, the receiver should double the rate limit
>> after 30 seconds, until it reaches the default rate limit again.
>>
>> The flow will look like:
>>
>> Alice Bob Carol
>> | | |
>> | onion_message | |
>> |------------------------>| |
>> | | onion_message |
>> | |------------------------>|
>> | | onion_message_drop |
>> | |<------------------------|
>> | onion_message_drop | |
>> |<------------------------| |
>>
>> The `shared_secret_hash` field contains a BIP 340 tagged hash of the Sphinx shared secret of the
>> rate limiting peer (in the example above, Carol):
>>
>> * `shared_secret_hash = SHA256(SHA256("onion_message_drop") || SHA256("onion_message_drop") || sphinx_shared_secret)`
>>
>> This value is known by the node that created the onion message: if `onion_message_drop` propagates
>> all the way back to them, it lets them know which part of the route is congested, allowing them
>> to retry through a different path.
>>
>> Whenever there is some latency between nodes and many onion messages, `onion_message_drop` may
>> be relayed to the incorrect incoming peer (since we only store the `node_id` of the _last_ incoming
>> peer in our outgoing connection state). The following example highlights this:
>>
>> Eve Bob Carol
>> | onion_message | |
>> |------------------------>| onion_message |
>> | onion_message |------------------------>|
>> |------------------------>| onion_message |
>> | onion_message |------------------------>|
>> |------------------------>| onion_message |
>> |------------------------>|
>> Alice | onion_message_drop |
>> | onion_message | +----|
>> |------------------------>| onion_message | |
>> | |--------------------|--->|
>> | | | |
>> | | | |
>> | | | |
>> | onion_message_drop |<-------------------+ |
>> |<------------------------| |
>>
>> In this example, Eve is spamming but `onion_message_drop` is propagated back to Alice instead.
>> However, this scheme will _statistically_ penalize the right incoming peer (with a probability
>> depending on the volume of onion messages that the spamming peer is generating compared to the
>> volume of legitimate onion messages).
>>
>> It is an interesting research problem to find formulas for those probabilities to evaluate how
>> efficient this will be against various types of spam. We hope researchers on this list will be
>> interested in looking into it and will come up with a good model to evaluate that scheme.
>>
>> To increase the accuracy of attributing `onion_message_drop`, more data could be stored in the
>> future if it becomes necessary. We need more research to quantify how much accuracy would be
>> gained by storing more data and making the protocol more complex.
>>
>> Cheers,
>> Bastien
>>
>> [1]
>> https://gist.github.com/t-bast/e37ee9249d9825e51d260335c94f0fcf
>>
>> _______________________________________________
>> 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/20220630/83ca2be4/attachment-0001.html>