“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.