Lightning network and lightweight clients How will the lightning network handle lightweight clients?

Do I understand it correctly that opening a payment channel require writing on the blockchain to protect against double-spend? The integrity being protected by the penalty of losing all bitcoin in the channel if writing a older transaction to the blockchain than what the counterparty do. 

If I have a friend I trust and open a payment channel to him/her, I can afford having my bitcoin invested in the channel being locked while he/she is offline. 

If I lose connection to an "anonymous" node I automatically found on the network, I won't know if it ever will return online. Therefore I would like to reclaim my bitcoins invested into that channel. Thereby taxing the blockchain and incurring transaction fees. (In the worst case scenario a group of people want to mess with me and anonymously create a lot of dead payment channels. Sure they will only bind as much bitcoin for me as they collectively bind themselves. But unless someone already have found a way to mitigate this, you might not want to be a merchant selling burnable flags in a world with the Lightning network.)

If I understand this correctly, won't this result in centralization? If I want to pay with the lightning network from my cellphone, I would need to use a full lightning network node (always online) or have pre-existing payment channels to nodes that trust me. (friends, my bank, full node in my cellar etc.)

Is this a real problem? Has someone found a way to mitigate it?
How will the lightning network handle lightweight clients?


Most steps during the payment process in an LN channel don't actually require full knowledge of the blockchain or even the unconfirmed (mempool) transactions. This is because the transactions involved deal with 2-of-2 multisig scripts, where both parties have to sign off on each transaction to make it valid, so they both can stay aware of all transactions made relevant to the channel they share without monitoring the blockchain.

The exception is for dispute mediation. If Alice tries to broadcast an older version of a commitment transaction, someone needs to see that transaction to take Alice's portion of the funds from it. This is an aspect that can be trustless-ly outsourced, though. It can even be incentivized with a small fee. 


  Do I understand it correctly that opening a payment channel require writing on the blockchain to protect against double-spend? 


First you establish a refund from the funding transaction, then you broadcast the funding transaction which needs to be mined into the blockchain before payments can be made in the channel securely. 


  The integrity being protected by the penalty of losing all bitcoin in the channel if writing a older transaction to the blockchain than what the counterparty do.


Exactly, the payment channel is crafted in such a way that previous states of the channel cannot be broadcasted. Technically they can be broadcasted, the penalty for doing so is just losing all of your portion of the funds in the channel, so neither party will broadcast previous states of the channel. 


  If I have a friend I trust and open a payment channel to him/her, I can afford having my bitcoin invested in the channel being locked while he/she is offline.


A lot hasn't been figured out in this area, but my guess is typical consumers wouldn't open a lot of channels with people who may be offline frequently. A consumer might open a channel with a business they frequent, and who has servers set up to be running with negligible downtime. Then consumers can pay each other through those businesses or other dependable nodes.


  If I lose connection to an "anonymous" node I automatically found on the network, I won't know if it ever will return online. Therefore I would like to reclaim my bitcoins invested into that channel. Thereby taxing the blockchain and incurring transaction fees. (In the worst case scenario a group of people want to mess with me and anonymously create a lot of dead payment channels. Sure they will only bind as much bitcoin for me as they collectively bind themselves. But unless someone already have found a way to mitigate this, you might not want to be a merchant selling burnable flags in a world with the Lightning network.)


I think you've essentially hit the reason that you don't want to just open up a bunch of channels with various anonymous nodes. They can become unresponsive, and you might have to wait a day or at least a few hours to get your funds out of the channel, plus paying transaction fees. Merchants still wouldn't mind connecting to many consumers, they just probably wouldn't be trying to route payments through consumers.

I should note that payment channels don't have to be funded from both parties. A channel you open with a merchant might have you putting 1 bitcoin into it and them putting 0 bitcoins. Then only you can pay the merchant, but the merchant probably isn't going to be trying to route payments through you (a consumer who would likely be offline 99% of the time), so that's okay with them. 


  If I understand this correctly, won't this result in centralization? If I want to pay with the lightning network from my cellphone, I would need to use a full lightning network node (always online) or have pre-existing payment channels to nodes that trust me. (friends, my bank, full node in my cellar etc.)


The difficulty of running an always-online node would be so low, that there would probably be a lot of competition. Merchants would definitely be at an advantage. That is how I predict channels would form, through merchants, and merchants would act as the intermediaries. 


  Is this a real problem? Has someone found a way to mitigate it?


Even if the network does become fully centralized around a small minority of nodes, those nodes still can't really do much harm. If one or two becomes unresponsive, payments will just route through other nodes. Like I said before, the barrier to entry for running a lightning node should be pretty low, so there will likely be a fair amount of competition.