From anton.kumaigorodskiy at outlook.com Tue Nov 1 11:53:12 2016 From: anton.kumaigorodskiy at outlook.com (Anton Kumaigorodskiy) Date: Tue, 1 Nov 2016 11:53:12 +0000 Subject: [Lightning-dev] Single channel on mobile clients Message-ID: In general you are definitely right, having a single channel has it's drawbacks: relying on a single peer indeed makes a single point of failure and a possibility of earning some funds just by keeping an app running is attractive (although how large these fees will be is an open question, an anticipation is they will be extremely low, maybe won't even cover a channel opening costs for a long time if you're not a specialized relay node with a high throughput?). But I'm afraid there will be a lot of annoying details and edge cases: > I don't see a direct connection between UX and the fact that there are > multiple channels I'd argue if there are many channels on a phone which can relay 3rd party payments then user has to be made conscious of the following: - app should run at all times or else we risk the following scenario to happen: user opens an app, sends it to a background, while hanging in there it starts relaying another HTLC and system kills it in a few seconds or the battery foes down or system crashes (does happen rather often on Android). The next day user opens it and finds out a channel has been unilaterally closed because of HTLC expiration. - how many channels should be opened and what the fee per channel should be? - how many funds can be relayed at max? (to not interfere with user's payments as you have suggested) These are a kind of questions a lot of users would not want to be asked, as a wallet developer I've had a fair amount of conversation with end users and I can confidently say most of them don't want to know how things specifically work, they just want an app to do it's job and get out of their way (which is totally fine but should be taken into account as we develop end user apps). > Combining multiple channels is trivial, and only the two endpoints > need to know how to do it After giving it some thought I see this is trivial, but also there seems to be an asymmetry: payee, when asked for payment, can generate multiple routes (and then an app can wait for all the requests to be fulfilled before it shows payment as "done" or we can have a notion of "partial payment" which becomes "fully paid" in the end), but payer, once received a single route, can't pay if no channel's capacity is sufficient. Payer has to somehow communicate beforehand that he needs multiple routes for a given sum which breaks simple scenarios like QR scanning. > The underlying connections do not actually have to > show up in the UX interface at all Let's assume we abstract all the underlying mechanics away: wallet automatically creates multiple channels and they are not displayed; user only sees a total balance across all channels. Let's also assume user can "refill a balance" which is done by opening an additional channel. Now here's a bad situation: Bob/Alice have a 2/15 SAT channel and Bob wants to conduct a 10 SAT transaction. He knows he has 2 SAT so he "refills" his "account" with 9 SAT and indeed sees 11 SAT as his new balance. He then scans Carol's QR and gets a single 10 SAT route but he can't pay because he only has 9 SAT and 2 SAT channels. Possible "fixes" are: 1. Don't hide multiple balances, user have to understand that a balance is in fact multidimensional which alone may be too much for a lot a of people. 2. Bilaterally close existing channels before creating new ones and recombine their balances which is no better than a single channel re-anchoring as described here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-May/000535.html > So if you find it easier to build the app assuming a single > channel, then that's perfectly fine Thanks, I really do. Single channel does not solve all of these issues but at least makes them obvious to user: the balance is truly one-dimensional, no 3rd party HTLC can break channel if wallet is closed at a wrong time, etc. On the other hand, I do tend to make up problems sometimes and I'd be glad if I'm wrong about all of this. -------------- next part -------------- An HTML attachment was scrubbed... URL: