 Drew asks, Lightning Network and Bitcoin Core. It has become clear that the Lightning Network is the winning choice for scaling the Bitcoin network. As such, do the developers for the base protocol and the developers for the second layer communicate with each other? Are they actively working together? That is a great question, Drew. I think Lightning Network is one of the choices for scaling. I don't know if it's the winning choice other than in popularity terms, but there are many possibilities for scaling, and scaling will be addressed by many different factors being scaled over time. In terms of your question, the developers of the base protocol and developers for the second layer communicate with each other. In fact, there are a number of things that can be done in the base protocol to make Lightning better, and there have been a number of Bitcoin improvement proposals for that. Probably the most important development in that space, which has implications not just for Lightning, but for a certain class of smart contracts in general, is the implementation of a new signature hashing type called SICK-HASH NO INPUT. Traditionally, with signatures, you can define by the signature type, whether you are signing all of the inputs and outputs in a transaction, whether you are signing just one input and one output, one input only, and no outputs. There wasn't a way to do it so that you could sign just the outputs and no inputs. Part of the reason for that is because that is a dangerous mechanism. You don't want to use that if you have a single signer address, because that creates dangerous conditions. In the case of Lightning, however, that kind of functionality becomes very useful for the implementation of a protocol called L2ELTOO. An L2ELTOO is a new type of payment channel, and it is more efficient and requires less work in the client than the payment channels we have today, which we would probably call Pundraja traditional payment channels, where you have to have a penalty mechanism in order to ensure that a previous state cannot be broadcast. For that reason, you need to be online and have watchtowers that watch for your channels, to make sure that the other party didn't try to broadcast a prior state. L2ELTOO actually does away with all of that, because it makes it impossible to broadcast a prior state, therefore you don't need a penalty, therefore you don't need watchtowers. It is a big improvement, but it does require this change in the core protocol. SIGCASH NO INPUT is one of the features that is being considered for the next big soft fork, which is the upgrade of Segwit to the scripting version, V1. We are currently running Segwit V0. There is an upgrade being planned for V1, which includes things like taproot, graftroot, mast, schnore signatures, and SIGCASH NO INPUT. SIGCASH NO INPUT is a feature specifically being introduced in order to facilitate better implementations of the Lightning Network payment channels. So yes, there is collaboration between core and Lightning. Milan asks, the locking and unlocking Bitcoin script for Bitcoin Lightning. I have found great high-level descriptions of how the Bitcoin Lightning network functions. However, none where how it looks like on the Bitcoin script level. So the question here is, how does the script inside the Lightning transaction look like? For unlocking, there are a number of different scenarios. The sender could close the channel and release the funds, the receiver could close the channel and release the funds, and the channel could get closed through some kind of uncooperative or timeout close. Let me see if I can very quickly find the specific bolt. The answer you are looking for is straightforward. There is a specification for Lightning called Basics of Lightning Technology, or BOLT. BOLT is a specification of how the various parts of the interoperable Lightning network that is currently deployed works. We are currently at the first version of BOLT. There are a number of additional versions that are being worked on to progress this specification. BOLT 1.1, etc. The BOLT standard consists of, I believe, eleven different sub-documents. BOLT 1, BOLT 2, BOLT 3, BOLT 4. Each one specifies a different part of the protocol. Some describe how the peer-to-peer network works, how routing works, how invoices are formatted, how DNS is bootstrapped, how channel discovery happens, etc. The one you are looking for is called BOLT 3. BOLT 3 is the script format within the transactions. You can find this at github.com, lightningnetwork.com, lightning-rfc.com, BOLT 3. BOLT 3 is titled Bitcoin Transaction and Script Formats, which details the exact format of on-chain transactions, which both sides need to agree on to ensure signatures are valid. It has the scripts that are used inside the commitment transaction outputs, for all of the cases you are talking about, and how the closing transactions work. That is where you will find that script. Enjoy some fun reading. You will learn a lot about the scripting language. It is not easy to read. I can warn you about that. It has been optimized to reduce the amount of data being used. Essentially, the script itself has been gradually refined, optimized, and polished. It is compressed, so it does the thing we want to do, but not in a way that is very verbose, so that it cuts down on the space used on the blockchain. It is a bit difficult to read, but enjoy that. Taurus asks, is custodial lightning wallet safe? Hi, Andreas. I recently came across a blue wallet and was elated with the co-founder's motivation behind it. I believe this could really push the adoption of lightning transaction usage. The user experience just works for common people. The only downside is that it is a custodial wallet. However, user experience is everything. I want to understand how safe is custodial wallet to be used for day-to-day expenses. Here is the thing. For the vast majority of users, this is a fundamental user experience choice. People often compare the practical choice to some kind of unachievable ideal. I hear a lot of people making comments like, the only way you should ever have a wallet is if you have your own wallet, that controls the keys connected to your own node, over-tore that is back-top using the cold storage, whatever. If you go into that kind of conversation, what people will do is switch off. The vast majority of users cannot handle that level of complexity. What are they going to do? They are either not going to use cryptocurrencies, which is a possibility if they don't need it, or worse. They are going to go to a custodial wallet that is stored on an exchange, which is worse than this example. I would say that a custodial wallet is a bit better than a custodial exchange wallet. The reason it is a bit better is because it allows people to experience the speed and security of lightning. It has the fundamental downside of being custodial, which means you have this massive counterparty risk. The massive counterparty risk is that either the vendor or the developers are compromised, and you lose the money that is in the custodial wallet. As a bridge between now and the future, where more people want to experience lightning wallets and use it, but they don't have the availability of good wallets, they don't yet have the infrastructure to build their own, or use their own node, or do any of these other things. It is better than nothing, honestly. I think it is important to realize that this is the same fundamental conundrum we have with lightning. The alternative to lightning is not on-chain. The alternative to lightning is payments between custodial wallets on the provider's network using a SQL database. The alternative to lightning for most users is not to go on-chain and control their own keys and run their own nodes. It is in fact to use a coin-based wallet to pay another coin-based wallet, at which point they are not using crypto anymore. They are using a SQL database. From that perspective, I think it is an acceptable compromise for small amounts of money for experimentation for now. Long-term, if you really want to get the most benefit out of using lightning wallets, the same rule applies as applies to bitcoin. Your keys, your coins, not your keys, not your coins.