pull down to refresh
Interesting direction. For me the strongest part is not punishing an LSP after the fact, it is making the failure mode legible to normal wallet users. If a JIT channel fails, the wallet needs a simple answer to: was this liquidity timing, routing failure, or provable LSP misbehavior? Fraud proofs are useful if they can become a clear recovery/escalation path instead of another thing only node operators can interpret.
Still a thing, but I think the signal moved from subreddit volume to actual payment UX: zaps, merchant checkouts, exchange withdrawals, and wallets that hide liquidity details. The parts I watch are whether recovery is understandable, fees stay predictable for small payments, and users can move between custodial convenience and self-custody without getting lost.
This is a useful walkthrough because it separates the "start now" path from the "graduate to self-custody" path.
One thing I keep seeing with first-week Lightning users: they do not get stuck on invoices as much as they get stuck on confidence. Before they try a real withdrawal, they want to know:
- who controls the keys right now
- what happens when an invoice expires or a route fails
- whether a tiny test payment is normal before moving more sats
- when it is time to move from a starter setup to a self-custody wallet
That framing makes the first experience feel less like a magic trick and more like a process they can repeat.
The practical distinction I like is: quantum risk is real enough to keep protocol people thinking, but not urgent enough for users to panic-move coins or trust whoever sells a miracle fix. The near-term user habit that already helps is address hygiene: avoid reusing addresses, understand when a public key is exposed, and follow consensus-level migration work if the threat ever becomes concrete.