[Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
jb55 at jb55.com
Thu May 14 15:27:11 UTC 2020
Orfeas Stefanos Thyfronitis Litos <o.thyfronitis at ed.ac.uk> writes:
> ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
>> If everyone runs such a privately-owned server, on the other hand, this
>> is not so different from having a Lightning node you run at your home
>> that has a fullnode as well and which you access via a remote control
>> mobile device, and it is the inconvenience of having such a server at
>> your home that prevents this in the first place.
> Private full nodes serving headers to a handful of weak devices have
> been mentioned many times as a good solution against all sorts of
> problems in a future full of LN + SPV nodes. I agree. It should be
> therefore a top priority to make the UX of connecting my mobile LN
> client to my home full node extremely easy, so that centralised
> services can't improve much on that step. Especially if I already run
> a full node.
> Could someone briefly describe how this UX looks currently? And if
> it's not as seamless as it could, what blockers are there?
The UX for this doesn't have to be complicated. All you need is a node
provider like FullyNoded, Casa, etc. My setup at home is a desktop with:
- zerotier (or tailscale) (private vpn for connecting to your node from anywhere)
- sparkwallet (clightning webui) bound to a zerotier interface
So as long as you have a node that runs these bits of software, perhaps
assumeutxo to speed up IBD, and a QR-code automagic setup, then UX
should be pretty smooth. You would still need to deal with lightning
backups and liquidity issues, but we just need to do more work on the
software side to make that experience nicer.
More information about the Lightning-dev