 Mark asks, what is L2 ELTOO? Can you explain what the new proposal L2 ELTOO by a number of lightning network developers entails? What does it solve? Are there trade-offs? What are the barriers to its implementation? You remember previously, in one of my other answers, I was talking about how lightning network isn't a single protocol. It is a whole stack of protocols, and these can be interchangeable. You have some flexibility to use different protocols at different layers within the system. There is the basic one, which is node discovery and negotiation of capabilities between nodes. That is the fundamental peer-to-peer network. On top of that, you have the payment channel protocol. It is important to understand that we already have at least three different payment channel protocols. The first payment channel protocol, which is sometimes called L2 penalty, is the protocol invented and written by... in the original lightning network white paper by Joseph Boone and Taddeus Dragia. That type of payment channel, which is a unidirectional payment channel where the state is updated... by enforcing a penalty if someone tries to cheat and close the payment channel with an earlier state. That formulation is more accurately called a Boone-Dragia payment channel, named after the original authors. There is another formulation of payment channels, which are bi-directional payment channels that have some more flexibility. Those were invented by Decker and Walter Hoffman. Christian Decker is one of the developers at Blockstream, who is working on lightning network technologies. Together with a few others at Blockstream, who are working on that. Walter Hoffman was the other author of the paper on bi-directional payment channels. The most recent specification for payment channels is L2. It is spelled E-L-T-O-O, but it is pronounced L2 to sound like Layer 2. The acronym for Layer 2 Networks. L2 was put together by Christian Decker, Rusty Russell, and Laulu Ossentokun, who is known as Roast Beef and the developer from the lightning labs. These three developers wrote a paper recently called L2. These payment channels are now known as Decker, Russell, Ossentokun payment channels. What L2 does is a very neat improvement on the basic Boone-Dragia channels for Layer 2 Penalty, which makes the network much more efficient by removing the need to have a penalty implementation for transmitting intermediate states in the payment channel and trying to close the payment channel by cheating. That is going to make the setup and implementation of payment channels much more efficient, but removes some of the complexities in maintaining a lightning network node as an end user. Now, L2 requires a slight modification to the Bitcoin scripting language. Right now, you may have heard of a thing called a SIG hash. A SIG hash is a type of signature or modifier for signatures. When you sign a transaction in Bitcoin, you can sign it in a number of different ways. The most common signature is called a SIG hash all, which is where the hash that is being signed by the signature represents the hash of all inputs and all outputs in a transaction. There are a few others, such as SIG hash single, SIG hash none, etc. These allow you to sign just one pair of inputs and outputs in a big transaction, allowing multiple parties to join in and sign a transaction collaboratively. This is often used in CoinJoin. SIG hash none, where you are not signing any part of the transaction, can be modified, etc. One of the formulations that doesn't exist today is a proposed change called SIG hash no input, which is a way to sign a transaction such as to bind its outputs, but not its inputs, allowing the transaction to effectively be a floating transaction, where it can be bound to any compatible input. L2 uses this in order to create these very flexible payment channels, where you don't need to have a penalty mechanism. As each new state is broadcast within the payment channel, it invalidates the previous state by binding to its predecessor. You can read that paper online. If you search for ELTOO, you will find the original specification, as well as quite a few different explanations on what L2 does. A new protocol for payment channels, one of three proposed so far. The current Lightning network runs on the earliest form of payment channels called L2 penalty, or Poon Dryja payment channels, but there are some new possible payment channel protocols. These could run in the future in parallel. You could have a Lightning network where multiple different types of payment channels are available to nodes, and nodes can negotiate which type of payment channel they want to implement between themselves, while still routing across them in a way that is consistent. This is a very interesting possibility to have innovation within these protocols. In order for L2 to be implemented, it requires a small change to the Bitcoin scripting language. This change can be implemented as a soft fork, as an increment in the script version, which is possible on their Segwit, and will open the door to some very flexible and efficient payment channels. Not yet. We are still quite far from seeing that in production. Of course, as I said, we would need a change in the Bitcoin script language first. Enrico has a question about Lightning network routing algorithms. Lightning network bolt specifications leave the choice of the routing algorithm open to the implementation, and currently all nodes are using a very trivial source routing algorithm. Surely interesting metrics could be used for deciding the routing, such as maximization of privacy, minimization of hops, etc., but they are all just variations on the same theme. Is there a qualitative improvement that can be taken at some point, such as letting the intermediate hops decide the route, as generally TCP-IP routers do, or are there intrinsic limitations inside the Lightning network that prevent such flexible approaches to be implemented successfully? Great question, Enrico. One of the important considerations when building a multi-layer network is separation of concerns between the layers, meaning that you shouldn't try to do everything in a single layer. If you have separation and abstraction between layers, that means that you can plug and play different algorithms at different layers, and mix and match them to the things you want to do. There is no reason why the Lightning network runs one routing algorithm for everyone. In fact, like the internet, you can have multiple different competing routing algorithms, and a node can choose to use different algorithms in different parts of the protocol stack. The Lightning network isn't just one layer. We talk of it as a layer, too, but within the Lightning network. There are a number of layers. There is a peer-to-peer propagation network that uses a gossip protocol to propagate things like routes and information about nodes. Above that, there is essentially a protocol layer that has to do with how channels are implemented. We will talk about that in answer to one of the subsequent questions, because it has come up again and again. For example, the L2 penalty or Pundraja protocol, which is used in the traditional Bolt Lightning network we have today, and some future protocols like L2 and Decker-Waterhofer payment channels, which we will also talk about in a second. That is a second layer. Above that, you have a protocol layer that communicates hash-time-lock contracts, which are essentially the transport mechanism for payments within the Lightning network. Above that, you might have another layer for various types of interesting applications that use metadata within the HTLCs to do other things on Lightning. For example, Lightning channel factories, watchtowers, things like that, the application layer of labs. Routing is simply one layer within a broad protocol stack in the Lightning network. It is useful to have the flexibility to implement any type of routing algorithm independently of how you implement payment channels, where you might implement any number of payment channel algorithms or protocols, independent of how you do the underlying peer-to-peer negotiation of capabilities, node discovery, etc., where you may also have multiple different independent protocols. This type of abstraction between layers opens up the ability to do innovation at the edge, where each node can have a number of capabilities, negotiate those capabilities with other nodes, and you can evolve the network without having it stuck in a specific choice. The answer to your question is right now we have source-based routing, and the reason for that is really simple. It is the simplest algorithm. It provides great privacy, because only the source node knows the complete route. At the same time, it protects from leaking information to intermediate nodes. It works well enough for the current scale of Lightning network, so why fix it when it isn't broken? That is the mentality of this, which is engineer for what the problems are today. Today, the routing protocol scales well enough for the current scale of the Lightning network, and it achieves the goals of privacy, route discovery, and payment propagation. Therefore, why fix it? It works for now. Does that mean we can do routing other ways? Absolutely not. We can do routing. In fact, it is fairly easy to do the kind of intermediary routing that you describe, such as the routing mechanisms that are used in TCPIP. You can use a system of neighborhood and gateway routers, such as the protocols that are used in TCPIP, for example, BGP. You can use other routing protocols, which use intermediary nodes. Even very simple things like shortest path and hot potato routing algorithms, and all of these various approaches. For every one of these routing algorithms, you have to think of it as a set of trade-offs. Maybe it is easier to discover more routes and route things more efficiently. But what if you do that at the expense of privacy? If intermediary nodes know where the payment is going, then they can also block certain recipients. They can also start blacklisting certain channels. They can prevent you from using certain routes. If you achieve better routing, but at the expense of privacy and decentralization, that is not a good trade-off. The question is, can you do intermediate node routing without sacrificing privacy? That is a question that is still to be resolved. There is a lot of research going on in that. It is a very rapidly evolving sphere, and I think there will be a lot more new things happening there. But Lightning Network, as a set of specifications, does not prevent you from using any routing algorithm you want for your node, or multiple routing algorithms where you can choose which one you want to use for any single payment, or you could even mix and match and find routes for your payments through different algorithms simultaneously, and choose the best result. Nothing prevents you from doing that because of the abstraction between layers. That is a good thing. Johnny asks, from what I first heard about Lightning Network last year until now, it seems to be ahead of schedule. I was not expecting a live network at this point of the year. Am I way off? What is next for Lightning Network? Is there anything non-technical but enthusiastic users can do to support and participate, besides downloading a wallet and buying a few stickers? Johnny, you are not wrong. It is really funny how in this space people are eager and frustrated with the slow pace of development, when we have this amazing pace of development, where these technologies are rolling out, and the rate of innovation is increasing itself at an exponential pace. Lightning Network did progress much faster. This was just a paper in 2014, the first white paper that was written. To go from a paper to a full implementation of a network within just under four years is really fast. In the area of cryptography, we have never seen this before. The only time we started seeing that rate of development in cryptography was because of cryptocurrencies. This is not an easy space in which to make advancements and innovation, because you have money on the table. If you get it wrong, people will lose money. You are not the only one who is surprised to see a live network at this stage of development. Most of the developers in the Lightning Network were surprised to see a live network. It mostly happened against their direct advice and wishes, because they didn't feel it was ready for mainstream production use. They were dragged reluctantly, kicking and screaming into supporting a main network. In the end, I think that is probably a good thing. Some people who are willing to take extra risk and to risk money and know that they could lose it by messing up... the configuration of their Lightning node or because of inadvertent problems and bugs that hadn't been discovered, or basically be able to do nothing with it because it didn't quite work, those people were able to push the state of the network much further and do a lot of interoperability testing under real-world scenarios. What can a new user do? Setting up a wallet and buying stickers is amazing right now. It is incredibly helpful, because you are going to run into problems. When you run into problems, if you document these and help others, you write about them and maybe even submit an issue bug report to the software developers who are working on these systems. I have submitted two or three issues so far and done a couple of pull requests on both L&D and C Lightning, in order to uncover small bugs and problems with interoperability. Why? Because I started using these technologies to buy stickers as silly as that may sound. I have an even sillier one for you. How about spending one Satoshi to change one pixel on this graffiti wall? Again, it is like a pointless application right now, but it is getting people engaged by the hundreds who are testing all kinds of combinations. They are stress testing the system, they are testing interoperability between the various clients and servers. They are testing the routing of payment channels, the layout of the network, and its connectivity. In the process, they are discovering bugs, lots of bugs, and these bugs are getting fixed. This is great. In fact, it is a great contribution. Yes, just download the wallet and start trying to use it. You will run into problems. You will figure out that some things are not named correctly, they are not displayed correctly, they are confusing to new users. You might find some problems with the protocol in making your payments. Submit a bug report, help the developers make this better, and give them your fresh perspective. You are seeing this stuff for the first time. If you see something and it is confusing, that is because it is written in a language by developers, who have been so deeply enmeshed in this that they cannot even see that it is confusing. Your fresh perspective, telling them, this is confusing, I don't understand why this is happening, is going to help them make better user interfaces. It is going to help them figure out bugs that they may not have anticipated or found until now. Trust me, the area is rich for bug reports. There is a lot happening there. Yes, it is moving very fast. Things are getting better every day. You can all participate and help make it better.