"In the Lightning Network, when we create a payment channel, is it secure like the blockchain?"
"Do channels have the same security and authentication operations like the blockchain?"
Yes, it's really important to understand that a transaction on Lightning,
if you have a bitcoin channel, is still a bitcoin transaction.
Imagine if I created a transaction, signed it, and gave it to you, instead of broadcasting to the Bitcoin [network].
You could broadcast that whenever you wanted to, or just hold on to it.
Anytime you broadcast that signed transaction, you will get the outcome of that transaction.
We have exchanged a signed transaction, we just haven't broadcasted it yet. That is how Lightning works.
Lightning payment channels are parties exchanging signed bitcoin transactions.
It has the same [underlying] security guarantee, authentication and authorization qualities...
as the Bitcoin blockchain.
In fact, that is why Lightning works. It requires the security of the underlying Bitcoin blockchain.
Lightning is routing smart contracts, pre-signed bitcoin transactions,
which need to be secure and valid on the underlying blockchain.
Why do you Lightning Network participants need to be online to execute transactions?
Well, it is not entirely true that Lightning Network participants need to be online to execute transactions.
They need to be online to start a transaction, to create an invoice, to be paid,
and under some circumstances to monitor the channels.
But they can also outsource the monitoring of their channels to third parties.
Keep in mind, the Lightning Network is intended to be a live, small payment, fast network.
It is not intended to be a batched, big transaction, long-term payments network.
That [kind of activity] is best done on-chain.
"In a Lightning channel, what happens...
in a three-person scenario, if the third person does not send the reimbursement?"
In any Lightning Network scenario, if one of the parties fails to finish the commitment to a channel,
does not update their state, or does not close the channel when asked,
then the other party can close the channel by transmitting one of the prior states.
The only way that balance can be pushed forward through the channel,
is if the parties share a hash pre-image, which is the secret for unlocking hash timelocked commitments.
In that case, the party who sent that balance can also receive the same balance...
from the previous channel endpoint with the same secret.
You don't have to trust that any parties participating in Lightning are going to behave as expected.
The whole point of this is [doing] transactions with people not expected to behave in any particular way.
They may disappear, stop responding to channel requests, refuse to close a channel, or refuse to...
to forward a hash time-locked contract.
They may do whatever they want to do. It doesn't matter. You don't need to trust them.
At every step, you have a signed bitcoin transaction that is valid and allows you to recover your funds.
This network itself does not require trust between participants.
Stephen asks, "How will the Lightning Network handle distributed denial-of-service attacks?"
That really depends on what kind of distributed denial-of-service attack we're talking about.
In order to create a Lightning Network payment channel, you [must] commit funds.
That makes it difficult for someone to simply create payment channels and not use [them].
Secondly, in order to propagate payments across payment channels, there is usually a small fee.
We will see how that plays out and whether it will lead to distributed denial-of-service attacks.
Also, Lightning Network nodes, just like Bitcoin nodes, monitor the type of information they are receiving...
from adjacent nodes, from their peers.
If they see the information they are receiving is incorrect or invalid,
they will limit connections or potentially even ban the nodes which are misbehaving.
All peer-to-peer networks [must] have some mechanism for protecting against misbehaving peers.
The most common way to do that is to either throttle or ban (for a short or long period of time).
The Lightning Network will handle distributed denial-of-service attacks in the same way...
that every peer-to-peer network handles them: an ongoing process.
As each type of attack is handled, attackers come up with new ways to attack the network.
That forces the network to adapt, which forces the attackers to adapt, and the network adapts [again].
Gradually, you evolve the system to become more and more resilient to denial-of-service attacks.
Bitcoin itself is under denial-of-service attack all the time; it evolved to be quite strong and resilient...
against attacks, which doesn't mean they're impossible but they're not very effective [anymore].
They cost a lot of money to execute and don't do much.
It is the same with TCP/IP, DNS, HTTP, many other protocols and infrastructure on the internet.
They have gradually evolved to handle bigger and bigger distributed denial-of-service attacks.
A follow-up question from Susanna, "Who bans a node? How does banning work?"
This is a peer-to-peer, decentralized network, which means your own Lightning Network node [does].
[It] connects to ten or fifteen other nodes, creating a mesh network.
Your node decides what nodes to connect to, or whether it [should] ban one of its neighbors for misbehaving.
Who bans nodes? Everyone is able to ban nodes [from their perspective].
If they start misbehaving, everyone who experienced that misbehaviour will ban those nodes;
and [if they misbehave badly enough] they will not be able to connect to the network at all.
That's how it works in Bitcoin. That's how it works in the Lightning Network.
There is no centralized authority here. Each node decides whether to ban its neighbors or not.