LN security

[Husires]

I just finished reading part of the whitepaper of LN. and from the name "Network"  it’s It's like a Twitter network.
I can open 1 channel to connect to the network "just like when signing in into Twitter" and can be sent to all my friends connected to that network. That's almost what I understood
that mean LN wallets will have full access to my private key? " will be less protected than current Bitcoin wallets?.

[DannyHamilton]

I just finished reading part of the whitepaper of LN. and from the name "Network"  it’s It's like a Twitter network.

It is nothing like Twitter at all.  I suggest you try reading more of the whitepaper or wait until you have a better understanding of how it works before you try to create analogies.

I can open 1 channel to connect to the network

Or you can open multiple channels.  The amount of access that you have to the network will depend on the channels that you open, and the channels that are opened by the nodes that you open channels to, and so on.

"just like when signing in into Twitter" and can be sent to all my friends connected to that network.

There is no "signing in" to the Lightning Network.  It is a relay network, not a private entity.

That's almost what I understood that mean LN wallets will have full access to my private key?

Not if you are doing it correctly.  You should never share your private keys with anybody.  That is why they are called "private".

will be less protected than current Bitcoin wallets?.

Lightning Network is just a special way to use bitcoin transactions. Therefore, it is EXACTLY AS PROTECTED as those bitcoin transactions are.

[Husires]

-snip-

OK,Let 's imagine that we' re going to treat using LN.
A: current Balance 1 BTC
B: current Balance 1 BTC
A want to pay 0.5 BTC to B.
we will open a Channel with a current Balance, send it to miners to be confirmed and we need to wait before rebroadcasting our current balance.
so if multi-Channels started at same time how we can protect system from "deadlock problem"?
If there is any problem in synchronization How can we protect the sender and receiver from cheating by using the previous value and not the current value ?
last problem is update the current Balance need access to private key how can protect it from kernel viruses?


 

[buwaytress]

OK,Let 's imagine that we' re going to treat using LN.
A: current Balance 1 BTC
B: current Balance 1 BTC
A want to pay 0.5 BTC to B.
we will open a Channel with a current Balance, send it to miners to be confirmed and we need to wait before rebroadcasting our current balance.
so if multi-Channels started at same time how we can protect system from "deadlock problem"?

Not sure what you mean by deadlock problem. The basic Bitcoin network already means you can't open the channel without txs getting confirmed (although it does make me wonder how many confirmations are needed before LN channel is considered open, if I understood it correctly!). And you if you can't confirm spent inputs then you can't open channels with the same coins. Double spends? The one confirmed will open the channel, the other will be invalid, channel also can never be opened.

If there is any problem in synchronization How can we protect the sender and receiver from cheating by using the previous value and not the current value ?

I think the most basic guidance (http://lightning.network/how-it-works/) already explains this without being too technical. In summary, both participants in the channel must sign off any spending, and only the most recent version of ledger is valid.

[Husires]

Not sure what you mean by deadlock problem.

deadlock problem= waiting for long time.
I thought that after you open the channel, you can not send or use your own Bitcoins until this channel ends. (Semaphore)

[DannyHamilton]

Not sure what you mean by deadlock problem.

deadlock problem= waiting for long time.
I thought that after you open the channel, you can not send or use your own Bitcoins until this channel ends. (Semaphore)

That is not true.

You can keep the channel open for as long as both parties agree to keep it open, and you can handle an unlimited number of transactions with that channel while it is open.

When you decide that you want to close the channel you broadcast the current state.  After that, you can not handle ANY more transactions with that channel.