 JJ asked, can the Lightning Network rules be changed and updated easily, unlike on-chain transactions? Which require a supermajority consensus, where almost everyone has to agree for a simultaneous upgrade? Also, can different groups of users use different variations of the channel rules and form a separate subnetwork? Without maintaining compatibility with the entire Lightning Network? That is a really great question, JJ. In fact, the Lightning Network rules can be changed and upgraded quite easily. The Lightning Network is a peer-to-peer network. It does not have a consensus layer of its own. The consensus layer it uses is the Bitcoin consensus layer. So, Lightning Network rules can be changed. The transactions that are used to implement Lightning routed channels, of course, have to be valid Bitcoin transactions. They have to conform to Bitcoin's rules. Lightning can't get around Bitcoin rules, because its security depends on it. However, how you use the Bitcoin rules to form a Lightning Network channel or a route, how the routes are updated... All of that is off-chain. It is not part of the Bitcoin consensus rules, and therefore it can be modified. In fact, there are a number of different Lightning Network specifications that use different sets of rules... on how they work, essentially different standards. Most people refer to the Lightning Network as a collaboration of three different companies... with three different open-source projects under a set of common standardized specifications called BOLT. BOLT stands for Basics of Lightning Technology. You can find that on GitHub. It is a repository called lightning-rfc, which means Request for Comments. It has, if I remember correctly, 12 documents, BOLT1 through BOLT12. These specify different parts of the current Lightning Network that is running between the Bitcoin and Litecoin blockchains. That is the one that everybody is talking about in relation to Bitcoin today. That is the main and test-net-running Lightning Network we have today. That is a BOLT-compliant network, which means that all three implementations use the BOLT standard... and the specification to interoperate, so they know how to establish communications with each other, how to find their peers, how to construct a route, how to create a hash-time-locked contract... that is used to forward a payment on a payment channel, how to link together multiple payment channels... to form a route, and various other details of the system, what the time-outs should be for routes, etc. That is not the only one. There is another specification called LIT. Ethereum uses yet another specification for a network called Raiden. Within Lightning Network, beyond the BOLT specifications, there is a significant amount of research happening by a number of different groups. BOLT today uses a second-generation payment channel specification. The original payment specification was called Poon Dryja, named after the two co-authors of the paper, Joseph Poon and Thaddeus Dryja, who wrote the original specification, which required n-lock-time channels using a specific feature of the Bitcoin script. I believe the current channels are a slightly different specification that uses a check-sequence verify. There are also newer channels, written or specified, if you like, or invented, by some of the other participants in the Lightning Network protocol design, who have given it various names that are the names of the authors of those specifications. There are a number of different ways to make payment channels, and some of those rules are rather interesting. There are more advanced, additional capabilities. There are some additional specifications for doing channels that might end up becoming future BOLTs, meaning they become incorporated into the BOLT standard, which would then allow different clients on the Lightning Network to upgrade to support a new BOLT specification, for a new type of payment channel, routing algorithm, for new node discovery algorithms, for example, multi-channel funding. That is where you do a single transaction to fund multiple payment channels, for doing atomic multi-paths, which is where you send a single payment over multiple channels as a collection of smaller payments, which are atomic, which means they cannot be divided, or various other interesting things. There are Lightning Channel factories, where you can outsource the creation of channels to third parties, watchtowers, and specifications for other people watching your payment channels, without you revealing any information that is private, so you don't have to always be online. All of these are developments that are happening, and they are not part of the current BOLT specification, but may become part of the BOLT specification in the future, to improve Lightning Network. Effectively, Lightning Network right now is a very basic beta-test network, and is very far from complete. There is a lot that can be done, and a lot of interesting research. The state of research is probably two years ahead of the implementation of the live network. There are all of these proposals for doing interesting things. So, Lightning Network can evolve without the consensus-hard fork limitations in the evolution of Bitcoin, which is one of the interesting things. I had talked originally about how, because of consensus, the network development and evolution of Bitcoin itself, and other open public blockchains, over time becomes more and more conservative, and you have fewer and fewer changes that can be pushed through, which means that most of the innovation has to move to layers above. You still have to use the consensus layer in Bitcoin, but that won't change. But on the layer above, you have more opportunities for innovation, and that's exactly what's happening with the Lightning Network. Crypto S17 asks, why did the developers release Lightning Network to mainnet before completion? Crypto S17, they didn't. Basically, a whole bunch of people hacked the testnet clients and started running them on mainnet to the great consternation and complaints against the wishes of those involved in developing those clients. People rushed it into mainnet before it was complete, pushing the devs to finish it faster. I don't know if that was a good thing or a bad thing. I'm guilty of participating in mainnet before the devs wanted to release it, so there we go. Susanna asks, what would be the purpose of keeping a statement secret and later decommitting it and revealing it? Why hide and then reveal what's the benefit and give us an example? This particular concept, Susanna, which is a pre-image commitment, is used in cryptography for a number of different reasons. One example is used, for example, in Lightning Network. So, Lightning uses a concept called a hash-time-locked contract, and an HTLC or hash-time-locked contract is basically a payment channel commitment based on the hash of a secret number. You commit money that can only be redeemed if the secret, the pre-image, is revealed. The only way that the person who is at the end of the channel, or 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, causing the secret to roll backwards through the sequence of payment channels and getting everybody paid. It gives you a guarantee that the other party only gets paid if they reveal the secret. And if they reveal the secret, you also get paid, so they can't cheat you. The same concept exactly is used in atomic swaps. For example, if I commit with another party funds on two different blockchains, let's say Litecoin and Bitcoin, in such a way that we're trying to do an atomic swap, but the only way I can cash the Litecoin they're giving me is to reveal the secret that allows them to cash the Bitcoin I'm giving them, then neither of us can cheat. That's exactly how we first commit funds to a hash, then we reveal the pre-image, and we reveal the pre-image in one of the transactions, which allows the other party to receive the other side of that atomic swap. That's a mutual guarantee that no one can cheat. On the Lightning Network, what prevents a bad actor from using the revocation transaction to steal coins? Jesse says, I've been trying to understand the game theory of the commitment transactions 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, and then popping back on to publish the revocation key and steal all the coins in the channel? Right, great. Let's talk about this. It's a bit complicated. I'm going to warn you. But first of all, there is no such thing as a revocation transaction. There are only commitment transactions. And commitment transactions are complex transactions which have multiple different spending branches, meaning that there are different conditions on which you can spend a commitment transaction. That's the first thing you have to understand. There are revocation keys. And the revocation keys are exchanged between the two parties in the Lightning connection after they sign the next commitment transaction. And in order to invalidate the previous commitment transaction, essentially to revoke the prior state, now that there is new state, and to ensure that the prior state cannot be unilaterally transmitted by one of the two parties. And here's the really important thing. It's not like there is one commitment transaction. There are always two commitment transactions, and these commitment transactions are asymmetric bilaterally. What that means is, let's say I'm Bob, and I have a channel with Alice. I have a commitment transaction signed by Alice, and Alice has a commitment transaction signed by me. And we have these on standby where we can counter sign them, transmit them to the network, and activate them effectively. But the commitment transaction I'm holding, which has Alice's signature, is different from the commitment transaction Alice holds that has my signature. And the reason it's different is because the commitment transaction that I have, that has Alice's signature on it, pays Alice first, and then delays the payment to me. And that's really, really important. Meanwhile, the other transaction that Alice holds that I have signed pays me first, and pays Alice with a delay. So the payment to Alice has a time lock on it, whereas the payment to me is instant. I can claim it as soon as that transaction is broadcast. So I have a transaction, it's signed by Alice, it pays Alice immediately, but it only has a time lock on the payment that goes to me. If I choose to counter sign that and broadcast that transaction, I'm creating both of those outputs on the network, but Alice's output can be claimed immediately, and my output is delayed. There's another output that can be claimed by Alice, but that requires the revocation key, and that one consumes all of the channel balance, and that's my punishment output, if you like. And once I've given the revocation key to Alice, if I transmit the commitment transaction, then Alice can take that one output and claim the entire channel balance with the revocation key, meanwhile I can't, because my output is still time locked. So there's this fundamental interplay where my payment is delayed by a bit, but I've given the ammunition to Alice to burn the payment completely if I try to cheat, and she can execute that immediately, whereas I have to wait. And by the time I'm done waiting, she's already executed, claimed that output, and there's nothing for me to claim, so Alice has a head start on the transaction I'm holding and can always claim it before I can. Meanwhile, I have a head start on the transaction I signed that she's holding, and she has to wait on that one, so we're always at a slight disadvantage on the transactions we hold that we can transmit unilaterally, but we're on an equal footing on the transaction the other person holds, which we can close cooperatively. That's the subtle balance in game theory in the Lightning Network.