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