“Can the Lightning Network rules be changed and
updated easily, unlike [the Bitcoin blockchain],
which requires super-majority consensus (almost
everyone must agree) for simultaneous upgrade?”
“Can groups of users use different variations of
the channel rules and form a separate sub-network,
with or without maintaining compatibility
to the entire Lightning Network?”
That is a really great question.
The Lightning Network rules can be
changed and upgraded quite easily.
Lightning is a peer-to-peer [overlay] network
that does not have a consensus layer of its own.
It uses the Bitcoin consensus layer.
Of course, Lightning Network rules can be changed,
but the transactions used to implement channels…
must be valid Bitcoin transactions,
so they must conform to Bitcoin’s rules.
Lightning can’t get around Bitcoin rules
because its security depends on it.
However you use the Bitcoin rules to form a Lightning
channel and route, how the routes are updated,
all of that is off-chain.
It is not part of the Bitcoin consensus rules [the way an
on-chain transaction is]. Therefore it can be modified.
There are a number of Lightning Network specifications
that have different sets of rules on how they work.
The [standard] most people refer to when
they say “the Lightning Network” is the one…
[made in a] collaboration [between] three
different companies and open-source projects,
under a set of common standardized specifications
called ‘Basics of Lightning Technology’ (BOLT).
You can find that on GitHub in a repository called
‘Lightning-RFC,’ which means “request for comments.”
If I remember correctly, it [currently]
has [eleven] documents, BOLT #1 – 11,
which specify different parts of the Lightning Network
that is running on the Bitcoin and Litecoin blockchains.
That is the mainnet and testnet everybody
is talking about in relation to Bitcoin today.
That is a BOLT-compliant network; all three
implementations use the BOLT specification…
to interoperate: how to establish communication,
how to find peers, how to construct routes
how to create a Hashed Timelock Contract (HTLC)
that is used to forward payments on a channel,
how to link multiple payment channels together
to form a route, what the time-outs should be,
and various other details of the system.
That is not the only specification.
There is another one called ‘Lit.’
Ethereum uses another specification for a network
called Raiden. Within the Lighting [development space],
beyond the BOLT specification, there is a
significant amount of research happening…
by a number of different groups.
I believe that BOLT uses the original payment channel-
Sorry, no, it uses a second-generation
payment channel [design] specification,
called a Poon-Dryja channel, named after the co-authors
of the paper: Joseph Poon and Thaddeus Dryja.
[Most payment channel designs] require nLockTime,
a specific [parameter in] the Bitcoin script.
The current channels [recommended by the
BOLT specifications are the Poon-Dryja design].
[They also use] the CHECKSEQUENCEVERIFY opcode.
There are newer channel [designs] invented by some
other participants in Lightning Network development,
[including Decker-Wattenhofer duplex payment
channels and Decker-Russell-Osuntokun channels].
There are a number of different
ways to make payment channels.
Some of those rules are rather interesting,
with more advanced additional capabilities.
[Some of those designs] might end up being
incorporated into the standard as future BOLTs,
which then allows different clients on the Lightning
Network to support a new type of payment channel,
routing algorithm, node discovery
algorithm, or funding [method].
For example, multi-channel funding, where you send
a single transaction to fund multiple payment channels.
Atomic multi-paths, where you [route] a payment, as a
collection of smaller payments, over multiple channels.
“Atomic” [in this case] means they cannot be divided.
There are other interesting [possible features]
like channel factories, where you can outsource…
the creation of channels to third parties,
and watchtowers, [a dispute mechanism]…
where other people watch your payment channels
without revealing any private information,
so you won’t need to always be online
[to make sure someone doesn’t cheat].
These developments are all happening;
they are not part of the current BOLT specification,
but they may become part of the BOLT specification
in the future to improve the Lightning Network.
The Lightning Network is very basic right now,
still in beta-testing and very far from completion.
There is still a lot that can be done.
The state of the research is probably two years
ahead of the current live network implementation.
There are [a lot of interesting] proposals.
So the Lightning Network can evolve without
[many of] the consensus limitations in Bitcoin.
I have talked about [this before]. Because of consensus,
the development and evolution of Bitcoin and other…
open public blockchains becomes more conservative
over time, so you will have fewer and fewer changes.
This means that, eventually, most of the
innovation must move to layers above.
You will still need to use the consensus layer in
Bitcoin, that won’t change. But on the layers above,
you will have more opportunities for innovation.
That is exactly what has is happening
with Lightning Network [development].
“Why did the developers release the Lightning
Network for mainnet before it was completed?”
They didn’t, [actually]. A whole bunch of people hacked
[together] the testnet clients and started running them…
on the Bitcoin mainnet, to the great consternation and
against the wishes of those who developed the clients.
People rushed it into mainnet before it was complete,
pushing the Lightning developers to finish them faster.
I don’t know if that was a good thing or a bad thing.
I am guilty of participating in mainnet before…
the developers wanted to release it, so there we go.
“What would be the purpose of keeping a statement
secret, then [decrypting] and revealing it later?”
“Why hide and then reveal? What is the benefit?
Please give us an example.”
This particular concept, a pre-commitment, is used
in cryptography for a number of different reasons.
One example is in the Lightning Network, which uses
what is called a Hashed Timelock Contract (HTLC).
which is [a type of] payment channel commitment
based on the SHA-256 hash of a secret number.
You would commit money that can only be redeemed
if this secret, the pre-image, is revealed.
The only way that the person at the end of the channel,
or the sequence of channels, can receive their money…
is if they reveal the secret to the person just before them,
who can then only receive their money if they reveal…
the secret to the person just before them.
The secret to roll backwards through the sequence
of payment channels, and everybody is paid.
It gives you a guarantee that the other party will only
be paid if they reveal a secret [in this sequence].
[By] revealing the secret, you also get paid. They can’t
cheat you. The same concept is used in atomic swaps.
For example, if I commit funds with
another party on two different chains…
— let’s say litecoin and bitcoin — [it is done] in such a way
that I can only [redeem] the litecoin they give me…
by revealing the secret that allows them
to [redeem] the bitcoin I have given them,
then neither of us can cheat.
We first commit funds to a hash, then we
reveal the pre-image in one of the transactions,
which allows the other party to receive the
[funds] on the other side of the atomic swap.
That is a mutual guarantee where no one can cheat.
“In the Lightning Network, what prevents a bad actor
from using the revocation transaction to steal coins?”
“I have been trying to understand the game theory
of commitment and revocation transactions…
in the Lightning Network, but I don’t see
why someone couldn’t proactively use…
the revocation transaction to steal coins.”
“Can you explain how the revocation key is only revealed
if a commitment transaction is broadcast maliciously?”
“What prevents a malicious Lightning node
from intentionally dropping off the network,
prompting an honest node to publish the last
commitment transaction, then coming back online…
to publish the relocation key,
and steal all the coins in the channel?”
Great, let’s talk about this.
It is a bit complicated, I will warn you.
First of all, there is no such thing as a “revocation
transaction,” there are only commitment transactions.
Commitments are complex transactions which have
multiple different spending [conditions or] branches.
There are different conditions on which
you can spend a commitment transaction.
That is first thing you need to understand.
There are revocation keys, which are exchanged
between two parties in the Lightning [channel]…
after they sign the next commitment transaction.
[This occurs] in order to invalidate the previous
commitment, to revoke the prior [channel] state…
now that there is new state, and to ensure the prior state
cannot be unilaterally transmitted by one of the parties.
Here is the really important [part]: there is not just one
commitment, there are always two commitments.
These commitment transactions are
asymmetric bilaterally, which means…
Let’s say I am Bob, and I have a channel with Alice.
I have one commitment transaction signed by Alice,
and Alice has a commitment transaction signed by me.
We [hold them] on standby, where we can [also]
sign them and transmit them to the network…
[in the event that the other person tries to cheat].
The commitment transaction I hold,
which has Alice’s signature,
is different from the commitment transaction
that Alice holds, which has my signature.
The commitment transaction I have will pay
Alice [her share of the channel balance] first,
and delays the payment to me.
That is really important.
Meanwhile, the transaction that Alice holds, which I have
signed, will pay me first and then pay Alice with a delay.
[The share of the refund transaction to ourselves]
will have a timelock on it, whereas [the share of]…
the [refund transaction to the other person] can be
claimed as soon as that transaction is broadcast.
So, I have a [refund] transaction signed by Alice,
that pays Alice immediately [if I broadcast it].
It only has a timelock on the [share
of the] payment that goes to me.
I [would be] creating both of those outputs on the
network, but Alice can claim her output immediately,
whereas my output is delayed.
There is another output that can be claimed,
but that output requires the revocation key…
and consumes all of the [funds in the] channel balance,
which would be my punishment [if I tried to cheat].
Once I have given the revocation key [for an old channel
state] to Alice, if I transmit [the old state / commitment],
then Alice can take that output with the revocation key
and claim the entire channel balance.
Meanwhile, I can’t, because
my output is still timelocked.
This is the interplay: my [cheat] payment is delayed,
and Alice [has the power to stop it] completely.
She can execute that [punishment] immediately,
whereas I must wait. By the time I am done waiting,
she will have already claimed that output
and there is nothing [left] for me to [steal].
Alice has a head-start on the transaction
I hold, and can always claim it before I can.
Meanwhile, I have a head-start on the transaction she is
holding, and she would need to wait [if she broadcast it].
We are always at a [slight] disadvantage
on the [commitments] we hold.
We [cannot] transmit unilaterally. We are on equal
footing [when both parties hold such commitments].
We can [also] close [the channel] cooperatively.
That is the subtle balance in the
game theory of the Lightning Network.