Async Payments 非同步支付

Existing Solutions and Their Problems:

1. Custodial Wallets
   + Simple, can receive anytime
   - Funds controlled by third party
   - Privacy risk
   - Counterparty risk

2. LSP Proxy Receiving
   + Funds eventually reach user
   + Better user experience
   - LSP needs to temporarily hold funds
   - Still requires trust
   - LSP may censor payments

3. HODL Invoices
   + Payment can wait
   - Occupies sender's liquidity
   - Increases jamming risk
   - Has time limit

Ideal Solution:
• Receiver can "commit" to receive while offline
• Settle trustlessly when online
• Don't occupy others' liquidity

Async Payment Design Goals:

Flow:
  Sender (Alice)
       |
       | Initiates payment
       v
  LSP / Intermediate Node
       |
       | Holds payment intent, waits for receiver
       | (doesn't hold actual funds)
       v
  Receiver comes online
       |
       v
  Receiver (Bob) - Completes settlement

Key Features:
• No liquidity occupied while receiver offline
• Complete actual HTLC exchange when online
• No need to trust intermediate node with funds

Trampoline Routing + Async Payments:

Concept:
• Sender delegates payment to Trampoline node
• Trampoline node finds the receiver
• If receiver offline, Trampoline can wait

Flow:
1. Alice creates payment, specifies Bob's static ID
2. Alice sends to Trampoline node T
3. T discovers Bob is offline
4. T saves "payment intent" (not actual funds)
5. Bob comes online, connects to T
6. T routes payment to Bob
7. Bob reveals preimage
8. Payment complete

Advantages:
• No on-chain transaction needed
• Alice's funds not locked when Bob offline
• Based on existing Trampoline proposal

Limitations:
• Requires Trampoline node support
• Still some trust requirement (T might not forward)

PTLC-based Async Payments:

Advantages of adaptor signatures:

Traditional HTLC:
• Receiver must be online to generate preimage
• Cannot create "reusable" payment method in advance

PTLC:
• Receiver can publish public point P = p*G in advance
• Sender uses P to create payment
• Receiver unlocks with p when online

Flow:
1. Bob publishes static payment point P (like static address)
2. Alice creates PTLC locked to P
3. Alice sends payment to Bob's LSP
4. LSP holds payment (in PTLC form)
5. Bob comes online, unlocks PTLC with p
6. Payment complete

Challenges:
• Requires widespread PTLC deployment
• Depends on Taproot channels

BOLT 12 Offers for Static Invoices:

Traditional BOLT 11:
• Need to generate new invoice each time
• Invoice has expiry time
• Receiver must be online

BOLT 12 Offers:
  Offer: lno1...
  • Static payment "offer"
  • Reusable
  • No need to be online for each invoice

Flow:
1. Bob creates and publishes Offer
2. Alice uses Offer to request invoice
3. Invoice request via onion routing
4. Bob's node/LSP returns invoice
5. Alice pays

Async scenario:
• When Bob offline, LSP can proxy
• Use Bob's pre-authorized keys
• Or wait for Bob to come online

Async Payments Roadmap:

Near-term (implemented):
• LSP proxy receiving
• HODL invoices
• Push notification wakeup

Mid-term (in development):
• BOLT 12 Offers
• Trampoline routing
• Better LSP standards

Long-term (research):
• PTLC-based async
• Fully trustless solution
• Cross-LSP interoperability

Ideal Goals:
• Receiver can be fully offline
• Don't occupy network liquidity
• Minimize trust requirements
• Protect privacy