Skip to content

Commit 294bdc1

Browse files
Update OM blog for latest async payments parlance (#202)
1 parent 85074b9 commit 294bdc1

File tree

1 file changed

+3
-2
lines changed

1 file changed

+3
-2
lines changed

docs/_blog/onion-messages-demystified.md

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -53,9 +53,10 @@ While offers were the original point of onion messages, their flexible format un
5353

5454
For context, a significant problem facing the Lightning Network is that users running noncustodial Lightning wallets on phones must have their wallet app in the foreground to receive payments. This is a big departure from the Cash App-like UX that users want and even expect.
5555

56-
A key part of the solution here is that all mobile wallets are likely to be using Lightning Service Providers (LSPs), which manage channel liquidity and stay online on behalf of end users.
56+
A key part of the solution here is for mobile wallets to have always-online channel counterparties. These counterparties are likely to be Lightning Service Providers (LSPs), which manage channel liquidity and stay online on behalf of end users, but they may be any always-online node.
5757

58-
Enter asynchronous Lightning payments. Async payments utilize LSPs on both ends, sender and receiver. The sender’s LSP will hold onto a payment until it receives an onion message from the recipient's LSP indicating the recipient is online and ready to receive funds. At this point, the sender’s LSP releases the payment.
58+
Enter asynchronous Lightning payments. Async payments utilize always-online channel counterparties on both ends, sender and receiver. The sender’s counterparty will hold onto a payment until it receives an onion message from the recipient's counterparty indicating the recipient is online and ready to receive funds. At this point, the sender’s counterparty releases the payment. Note that the sender's "counterparty" may be the sender themselves, if they are always online and sending to an
59+
often-offline receiver.
5960

6061
While it may sound like it, this does not tie up network liquidity via long CLTV timeouts like today's "async payments" because the only locked liquidity is the sender's, and the sender has already bid farewell to those funds.
6162

0 commit comments

Comments
 (0)