Re: [Lightning-dev] Onion messages rate-limiting

2022-06-29 Thread vwallace via Lightning-dev
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 limi

[Lightning-dev] Async payments proof-of-payment: a wishlist for researchers

2023-01-10 Thread vwallace via Lightning-dev
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

Re: [Lightning-dev] Async payments proof-of-payment: a wishlist for researchers

2023-01-12 Thread vwallace via Lightning-dev
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&

Re: [Lightning-dev] Async payments proof-of-payment: a wishlist for researchers

2023-01-25 Thread vwallace via Lightning-dev
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

[Lightning-dev] Onion messages for probing scheme

2023-02-27 Thread vwallace via Lightning-dev
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/valenti