9

I'm thinking of a scenario where users on mobile devices using a LN client will rarely be online.

Let's say Alice opens a channel with Bob and they make 10 LN transactions. After Alice has received the 10th, she goes offline for longer than the channel's lifetime.

So if the channel was setup to last for 3 days, she'll be offline for say, 5 days.

My question is, when Alice comes back online, how does she know whether Bob commited to the blockchain the 10th and not an earlier transaction (which is in favor of Bob).

I understand that if Alice was online she could check this behavior herself, and readily commit the 10th to get her money. But the key point here is that she's offline longer than the channel's lifetime.

Is there a solution to this in LN? Because frankly, most users will not have a node that is online 24/7. And also, I don't want to trust a third-party to commit the 10th transaction at the right time -- what if they don't? Who's to say they will also act honestly and not commit an earlier transaction from the channel?

8

The lightning network is comprised of bi-directional payment channels between two nodes. This means that either one of those nodes should be able to initialize a transaction at any time. These transactions require both parties to be actively participating in updating the smart contracts that keep the channel alive. If one party fails to respond, they are essentially in violation of the smart contract, and are forfeiting their claim to any of the funds in the channel.

Non-responsive clients are a liability to anyone opening up a channel. It means that their bitcoin may be tied up in the channel until the timeout period. That bitcoin was typically put there either to make a payment (which now is delayed), or to earn network fees for being a hub of other people's transactions. An unresponsive node means the channel is wasted. It's similar to a denial of service attack, except it's tying up bitcoin rather than bandwidth.

To illustrate how this works, consider that Alice and Bob have each contributed 1BTC to a shared channel. The entire channel now has a total of 2BTC in it, but it has a cap in each direction. Because Alice only put in 1BTC, the most that will ever flow from Alice to Bob is 1BTC. This is the same for total transactions from Bob to Alice.

Let's say that more money has flowed from Alice to Bob during the lifetime of the channel, so that if it were closed right now, Alice would get 0.5BTC, and Bob would get 1.5BTC (excluding fees for simplicity). Now let's say Bob all of a sudden went offline, leaving the channel useless.

Due to how the smart contracts work, Alice will have a valid bitcoin transaction from earlier, that was signed by Bob, and could close the channel leaving Alice with more than the 0.5BTC she is owed. Alice can broadcast this transaction to the Bitcoin network, and after a timeout period, will get Bob's rightful money. The only thing that prevents this, is that Bob will see the transaction propagate on the network, and can submit the final transaction that he has (already signed by Alice) to get his full payment before Alice's transaction is valid. If Bob isn't paying attention, then Alice can steal what is rightfully his.

Penalizing unresponsive nodes is a feature of the lightning network, intended to keep it functional. By leaving the channel unattended, Bob is doing Alice a disservice. Making that behavior financially disastrous is what makes the system work in the first place.

  • Thanks for the well explained answer. What are your thoughts on how everyday users will use the LN network? As I mentioned in the question, I envision LN clients as mobile apps with sporadic connectivity. Would they have to rely on third-parties to commit for them when they're offline - and how much would you have to trust them? I'm thinking users would at least have to trust them to commit transactions in a timely manner to invalidate past transactions, right? This to me seems an awful lot of trust put onto third-parties. – Luca Matteis Jul 6 '17 at 21:33
  • 3
    My guess is that online services will be popular, although there are other options. Users who just want to pay, and never be paid, can connect to a special bridge node with a one directional channel. This node would be a third party that forwards payments on to the actual lightning network. This could still be trustless, yet much safer when it comes to going offline. Also the timeouts and gaps between timeouts can greatly effect how frequently you have to go online. All these problems have solutions and mitigations. – Jestin Jul 6 '17 at 22:04
  • Ok but my main concern is: do you still have to trust these third-parties, or is there a way to mitigate that? And if so, how? – Luca Matteis Jul 7 '17 at 8:47
  • With services, you always have to trust them with as much money as they are managing on your behalf. It's like keeping money on an exchange. If you choose to have the convenience of going offline with open channels, then the 3rd party risk is the price you pay. This is the same as with any web wallet. You are trading trustlessness for convenience. – Jestin Jul 7 '17 at 12:22
0

Yes, you must be online. The solution is for Alice to have a server of her own (no need to trust a third-party), either at home or in the cloud (aws, azure), that would keep a record of all her channel transactions and monitor the btc network 24/7 in case the other party closes the channel. This way she can go offline and not worry because the server will do the monitoring for her. No way she can do that only with her cell (IMHO).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.