Revisit "On-chain" and "Lightning" distinction in payments

[GBKS]

We have had a lot of discussion around how to differentiate (or not to differentiate) on-chain and Lightning in UI. A prime example is the "network selector" in the Requesting entry points screen slider.

Let's list out all the problems, solutions, concepts, etc and systematically work through this so we can have clear guidance.

Some thoughts:

• The philosophy of Blixt is that it's a Lightning wallet and all funds should always be on Lightning. There is a UI for on-chain, but it really should never be used. Incoming on-chain funds are automatically moved to Lightning.
• Muun instead shows a single balance. Funds are always on-chain, which is not revealed to the user. Users can send and receive Lightning, which is done behind the scenes via submarine swaps, which the user is also not made aware of.
• For wallets that hide on-chain and strictly prioritize Lighting, how should fallbacks be handled in case something goes wrong?
• Could Lightning (a technical term) be replaced with something like "Instant payments" (describes a user benefit)? If so, what do we call the non-instant payments... regular payments?

[Bosch-0]

The philosophy of Blixt is that it's a Lightning wallet and all funds should always be on Lightning. There is a UI for on-chain, but it really should never be used. Incoming on-chain funds are automatically moved to Lightning.

We should follow a similar path - though what I don't like with Blixt is that you can't somehow generate an address from the receive pane. I get it's Lightning first but this should still be accessible somewhere from the receive flow imo. Phoenix has a toggle which isn't so bad but probably better to hide it even more.

For wallets that hide on-chain and strictly prioritize Lighting, how should fallbacks be handled in case something goes wrong?

Definitely need to explore this more.

Could Lightning (a technical term) be replaced with something like "Instant payments" (describes a user benefit)? If so, what do we call the non-instant payments... regular payments?

This was my issue with the term instant payments. A Lightning payment should be a regular payment and on-chain have a distinction imo.

[moneyball]

This was my issue with the term instant payments. A Lightning payment should be a regular payment and on-chain have a distinction imo.

Agreed.

[moneyball]

I've been spending more time recently thinking about this and discussing with many folks. Here are some ideas to consider.

For deposits, the design guide should recommend a single QR code. This would be BIP21 + BOLT11 (transitioning to BOLT12 once available). A single QR code is clearly the best UX in terms of simplicity. The user does not need to understand various payment protocols and details and make a choice. They just scan that QR code and it "just works." What happens for the sending wallet? If it is an on-chain only wallet, it uses the on-chain address. If it is a LN-only wallet it uses the LN invoice. If it is a wallet that supports both, it could default to using LN invoice and prompt user if they'd like to pay on-chain (with associated fees) if LN payment fails.

BOLT12 QR codes are relatively small compared to BOLT11, so the combination of BIP21+BOLT12 would hopefully be adequate for older/cheaper phones, and this can be tested.