From decker.christian at gmail.com Sun Oct 30 15:46:53 2016 From: decker.christian at gmail.com (Christian Decker) Date: Sun, 30 Oct 2016 16:46:53 +0100 Subject: [Lightning-dev] Single channel on mobile clients In-Reply-To: References: Message-ID: <20161030154653.GA10652@nex> On Sat, Oct 29, 2016 at 06:08:27PM +0000, Anton Kumaigorodskiy wrote: > It seems to me there are substantial reasons for a mobile LN wallet to only support a single payment channel: If at all possible I'd like to enable even mobile users to open multiple channels and increase the connectivity in the network. I think users are likely to want to open multiple channels, to earn some fees, offsetting their own payments, or just to support the network. And on the other side, I don't think they'd be too upset if wallets went ahead and just created a number of channels by default. > - Typical usage scenario on phones and tablets will be "open an app" - "conduct a micropayment" - "send an app to background to be automatically shut down by OS in a few minutes". So it's safe to say that majority of LN nodes on such devices will be offline 99% of time and as such won't be of much use in relaying payments. Also often it might not be in user's interest if a portion of funds suddenly becomes locked in HTLC (especially if the lock lasts for hours). Running a lightning daemon should be relatively lightweight, so I think it would be reasonable for people to have a wallet running, even only when the phone is plugged in. Even having the app run only a few minutes like you said, it can be used to forward a decent amount of transfers over channels that are already established. The locking up of funds is indeed problematic, but we can limit the maximum amount that can be locked in at any point in time, and would only impact if the user is attempting to make a transfer that is larger than the reserve. > - One channel with 1 BTC is better than two 0.5 BTC channels for an end user in a way that he can receive and send larger amounts: two 0.5 BTC channels will never let me receive 0.51 BTC (AFAIK combining multiple channel capacities for a single transaction is possible in theory but won't be implemented in initial LN release). I'd argue the opposite: two channels with 50% each are better, since the user is not relying on a single peer being available when she intends to make a payment. Opening a single channel is a classical single point of failure, a costly one too, since you'd have to tear down the channel, and create a new one. Combining multiple channels is trivial, and only the two endpoints need to know how to do it. The sender simply generates multiple routes, avoiding exhausted channels, and the recipient has to know that he should wait for the entirety of the funds to be secure before triggering the clearing. So even if the 1.0 protocol does not support it, we can add signaling between the endpoints. > - Last but not least, having a single payment channel improves UX and simplifies UI and thus lowers the barrier for adoption. Also it is my understanding that mobile users won't care much about relaying payments (and for those of them who will using a phone for this purpose is a bad idea anyway). I don't see a direct connection between UX and the fact that there are multiple channels, just like Bitcoin wallets don't just chose a single TCP connection. The underlying connections do not actually have to show up in the UX interface at all, especially if we allow for multi-path routes as above. It's true that users won't care too much about relaying other people's transactions, but if the message is that they can offset their own fees or earn something by being a nice neighbor, I think people will want to do that :-) > My current plan as I continue working on an Android LN wallet is to design UI and UX in a way that only supports a single payment channel but it's quite possible I've missed something important here so once again I'd like to hear if you think this is a viable approach. I am speculating on what users might want, and I might very well be wrong. So if you find it easier to build the app assuming a single channel, then that's perfectly fine. But maybe it is possible not to bind the single channel and the UX too tightly :-) > Anton Cheers, Christian > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev