Lightning/Onchain architecture assumptions

[danielnordh]

For a Daily spending wallet, what are good decisions about when and what to support when it comes to lightning and onchain?
Expect new user to have never used a bitcoin wallet before / not have any bitcoin elsewhere.

Some assumptions I am starting with:

• Default to lightning for send and receive, what formats to support?
• Should be able to receive onchain payments (being paid a larger sum for work or selling an item second hand)
• Should MAYBE be able to send onchain (sending to a savings wallet)

How to get channels?
Ideally a user is able to receive on lightning immediately after installing the app.
For this, a channel with receive capacity needs to be available.

• Pay an LSP to open one
• User opens one by funding with onchain bitcoin
• Channel gets opened when receiving onchain bitcoin
• See Breez, opens receive channel on the fly as needed, but from their own routing node. Their fees.
• Use shared node like LNDHub

If an LSP is required, who and how can this be integrated?

• Any channel opened to the user will cost money (this is a huge barrier for either user and/or the developer)
• How much? ($2.50 on LNBig, $4.27 on Bitrefill Thor, $140 with Blocktank for receive only, 1,000,000 sats)
• Can you open channels with LSPs via api's without contracts/signing up etc?

What formats to support?

• Unified Payment Request / BIP21
• Bolt 11 (single use, with expiry time)
• Bolt 12 (ready for use?)
• LNURL?
• LNURL-pay?
• Lightning addresses?
• AMP/SMP?

Other considerations

• If using LDK as node on mobile device, can it receive lightning offline?
• Any way to open channel when receiving on lightning, and pay the fees to LSP out of received amount?
• What happens if an LSP channel closes and the user has funds, goes to user onchain address?

[danielnordh]

From convo on LDK Discord

[danielnordh]

they do not need onchain bitcoin. basically what actually happens is the user generates two invoices for the slightly different amounts with the same preimage.

they give the larger one to the payer to pay and the smaller one (difference is the fee paid to lsp) to the lsp.

when the lsp receives the htlc it opens a 0-conf channel with user then pays the smaller invoice which gives them the preimage and then turns around and uses the preimage to settle the larger invoice
so the lsp earns the difference

[moneyball]

Regarding "What formats to support?" we need to separately discussing send and receive support. The wallet might want to support all of them for sending, so that the user can send to any other wallet. For receive though, since this is a non-custodial mobile wallet, I don't see how LNURL can be used as it needs to be custodial or you'd need to run a web server on the phone. And for receive in general, it is a largely unsolved problem. By far the best solution to that problem is lightning/bolts#989 which is unlikely to be available until 2023.

I'd suggest punting on receiving as a use case. It is after all a "daily spending wallet" use case. So for v1 just focus on "user who wants to pay merchants."

[moneyball]

As for sending support, I'd suggest starting with bip21 (and bolt11) as that covers most situations. Then LNURL.