 Rohit asks, in Lightning Network, when we create a payment channel, is it secure like the blockchain? Does this channel have the same security and authentication operations like the blockchain? Yes, so it's really important to understand that a transaction on Lightning Network, if you're doing a Bitcoin channel, is a Bitcoin transaction. Imagine if I created a transaction, and instead of broadcasting it on the blockchain, I signed the transaction and then gave it to you. You can broadcast it whenever you want, or you can just hold on to it. Anytime you take that signed transaction and broadcast it, you get the outcome of that transaction. We've exchanged the signed transaction, we just haven't broadcast it. That's how Lightning works. So, Lightning payment channels are parties exchanging signed Bitcoin transactions, and it has the exact same security, authentication, and authorization qualities, the same security guarantees as the Bitcoin blockchain. In fact, that's why Lightning works, because it requires the security of the underlying Bitcoin blockchain. Lightning is routing smart contracts, pre-signed Bitcoin transactions, and it needs those smart contracts, those pre-signed Bitcoin transactions, to be secure, to be valid on the underlying blockchain. Why do Lightning network participants need to be online to execute transactions? Well, it's not entirely true that the Lightning network participants need to be online to execute transactions. They need to be online to start a transaction. For example, in order to create an invoice to be paid, they need to be online. Under some circumstances, they need to be online to monitor the channels, but they can also outsource the monitoring of channels to third parties. Keep in mind, Lightning network is intended to be a live, small payment, fast network. It's not intended to be a batch, big transaction, long-term payment network. That is best done on chain. In the Lightning channel, what happens in a three-person scenario if the third person does not send the reimbursement? Well, 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-time-locked commitment. In that case, the party who has 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 of the other parties participating in Lightning are going to behave as expected. In fact, the whole point of this is that you do transactions with people who are not expected to behave in any particular way. They may disappear. They may stop responding to channel requests. They may refuse to close a channel. They may refuse 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. Because at every step of the way, you have a signed Bitcoin transaction that is valid, that allows you to recover your funds. That is the whole point. The whole point is that the network itself does not require trust between participants. Stephen asks, how will the Lightning network handle distributed denial-of-service attacks? Well, Stephen, that really depends on what kind of distributed denial-of-service attacks we are talking about. In order to create a Lightning network payment channel, you have to commit funds. That makes it difficult for someone to simply create payment channels and not use those payment channels. Secondly, in order to propagate payments across payment channels, there usually is a small fee. We will see how that plays out, and whether that will lead to distributed denial-of-service attacks. Also, just like Bitcoin nodes monitor the type of information they are receiving from adjacent nodes from their peers. If they see that the information they are receiving is incorrect or invalid, they will limit the connection, or potentially even ban, the nodes that are misbehaving. All peer-to-peer networks have to have some mechanism for protecting against misbehaving peers. The most common way to do that is to either throttle or ban for a short period of time, or potentially ban for a 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. That is an ongoing process, because 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, which forces the network to adapt. 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, and it gradually evolved to become quite strong and resilient against denial-of-service attacks. That doesn't mean they are impossible, it just means they are not very effective. They cost a lot of money to execute, and they don't really do much. The same thing with the Internet. TCPIP, DNS, HTTP, many other protocols and infrastructures on the Internet have gradually evolved to handle bigger and bigger distributed denial-of-service attacks and become resilient. A follow-up question from Susanna, who bans a node, and how does banning a node work? This is a peer-to-peer decentralized network, which means that your own lightning network node connects to 10 or 15 other nodes and uses that to create a mesh network. Your node decides what nodes to connect to, and it decides whether it needs to ban one of its neighbors from misbehaving. Who bans nodes? Everyone bans nodes. If they start misbehaving, everyone who experiences that misbehavior will ban those nodes, and eventually 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 lightning network. There is no centralized authority here. Each node decides whether to ban its neighbors or not.