Async Payments: Getting Paid While Your Node Is Offline

pull down to refresh

Async Payments: Getting Paid While Your Node Is Offline | LDK lightningdevkit.org/blog/async-payments-receiving-while-offline

1072 sats \ 6 comments \ @0xbitcoiner 26 Jun lightning

The Lightning Development Kit (LDK) provides the tools to build a node on the Lightning Network. One practical reality of the network is that a payment requires a degree of coordination: for a payment to settle, the sender and recipient need to be online at roughly the same time. A BOLT 11 invoice partially addresses this by requiring the recipient to hand the sender fresh, interactive data, which assumes the recipient is online and their device is unlocked at the moment of payment.

That assumption breaks down for one of the most common things people want to do with Lightning: accept tips or payments on a phone without keeping an app open and in the foreground. Modern mobile operating systems compound the problem. On both Android and iOS, an application is generally not guaranteed any CPU time in response to a push notification unless it falls into a privileged category such as VoIP. In practice, this means a mobile node often cannot wake up to claim an incoming HTLC on its own.

This post describes the async payments protocol, which LDK implements to allow an often-offline node to receive payments without trusting a third party to custody funds, and without anyone encumbering network capacity with long-lived HTLCs.

...read more at lightningdevkit.org

view all related items

39 sats \ 2 replies \ @justin_shocknet 26 Jun

The stupidity devs will engage in to fake async Lightning payments to phones, that shouldn't run lightning nodes in the first place, knows no bounds.

on behalf of an often-offline recipient. This server hands out reusable invoices that deliberately omit the payment hash

So again, the solution is trust... you trust the LSP to hand out special invoice instead of a normal one... or even just one to themselves.

19 sats \ 1 reply \ @Scoresby 17h

I found your conversation with @supertestnet on X was helpful.

Super:

you can't generate an invoice offline
A reusable invoice is signed by the recipient, which he can post publicly. No need to trust a server.

It's true that the recipient must be online to receive, but the sender does not need to be online at that time if his payment is pending
the 2 levers to pull are therefore either trust, or reattempts
You forgot the lever "make the sender's htlc remain pending until the recipient gets online." That requires neither custodians nor reattempts. It does require a server to stay online, but the server lacks custody.

Justin:

The reusable invoice comes from the LSP not the receiver. Pre-signing to obviate the issuance dilemma may work in theory, but reality this is for unsophisticated users in the first place... because they're running lightning on device that's asleep constantly.

Super:

this is for unsophisticated users in the first place
For unsophisticated users, the equivalent to signing a reusable invoice is posting it on a social media profile or similar. Anyone can do that, even an unsophisticated user, and then their customers can get it from there.
The reusable invoice comes from the LSP not the receiver
I am checking with the devs right now. I suspect the receiver can get a reusable invoice and then give it out to others, and thus bypass the need for an LSP to hand them out to third parties.

Justin:

The docs are pretty sloptastic, so maybe its in error that they show the first step as the sender hitting the offline receivers LSP for an invoice... how are they reaching the receiers LSP in the first place if there was no invoice to begin with?

Super:

I think I am going to test out the software to figure this stuff out. I bet there's a way to bypass the devs' expectation that the sender must talk to the recipient's LSP server who then merely forwards messages to them when they get online. Seems like a needless requirement.

Fundamentally, LN works by having the sender make an htlc that the recipient unlocks with a preimage. There's no reason why the htlc can't stay pending til the recipient gets online. To do his part, the recipient should not need an LSP. So I wanna see if I can hack a simpler flow

Justin:

Eliminating the LSP makes sense if the sender stays online, but then we're back to this just being another re-attempt scheme.

The added complexity is because of mobile-to-mobile delusions.

Super:

My problem with their expected flow is not the part where the sender uses an LSP but the part where the recipient needs one too. All that 2nd one seems to do is store and forward messages to people. I think I know a way to eliminate that second LSP so I wanna see if my idea works

Also, the sender's LSP merely seems to need to understand two things: that the sender's htlcs will have unusually long timelocks, and the recipient will eventually come with a preimage to unlock it. Feels like that can just be a service bit that regular routing nodes advertise.

2 sats \ 0 replies \ @nitter 17h

https://twiiit.com/SuperTestnet/status/2070734888085377233

31 sats \ 0 replies \ @k00b 26 Jun

I had been putting off learning about async payments so this was helpful. They are like keysend with an LSP protocol for holding. Cool.

36 sats \ 0 replies \ @hasherstacker 26 Jun

Getting paid while the node is offline.

If LN works without the node being online, then it sounds to me, like a decoy effect: #1514942

2 sats \ 0 replies \ @1GLENCoop 27 Jun