 Jeff asks, what projects are most needed in the space right now? That's a great question. I'm afraid that the answer is rather boring. You might think that what we really need in the space right now is some kind of artificially intelligent neural network-based... 3D printing drone-based Mars expedition. The truth is that the most important projects at this stage are really basic infrastructure projects. Projects that are not very exciting, they're not about the latest ICO for prediction markets on isolated tokens that are run by AI. Really, the projects that are most important at this stage in this industry are basic infrastructure. For example, exchanges, wallets, ATMs, and education systems. Let's go through those one by one. You might think that we already have enough exchanges, but one of the interesting things about exchanges... is that they are very much attached to a local culture, a local language, and a local set of regulations. Especially when it comes to exchanging national currency for cryptocurrency and back. We really need on-ramps and off-ramps in order to have enough liquidity and activity. This economy is not yet self-sustaining. It can't operate entirely within the cryptocurrency domain. I think one day it will be, but not yet. Exchanges are necessary, and you can't build an exchange that covers every country. In fact, almost all exchanges are very specific to one country. If you think about it from that perspective, there are 194 countries. Every country needs three or maybe four exchanges to have a healthy dose of competition. That is about 800 exchanges worldwide for specific countries, not counting specialist exchanges, virtual currency exchanges, and various other permutations on that idea. We are still quite far from that goal. I remember the days when, in fact, there was one exchange, and that was MT Gox. We all were having difficulties with latency, lag time, trading, and security, and all kinds of other problems. Fortunately, nowadays we have a wide open space. Next exchange is wallets. Wallets are the front end of this industry. This is the part that interacts directly with users. Users who are new, their first experience with cryptocurrencies will be through a wallet. This is the first interface they will know. If that interface is easy to use securely, if it is intuitive and easy to understand, then they will be able to more easily use this new technology. If the user interface sucks, if it is confusing, if it causes security problems, if it has problems with certain features, if it is not using the latest technology, users will have difficulty using cryptocurrency. Wallets are really important and really difficult. They require a lot of user design and user experience. They require the latest cutting-edge technology. Right now, for example, we have all of these new technologies that are enabled, for example, in Bitcoin. Or in Ethereum, you have all of these ERC-20 tokens, and the state-of-the-art moves very fast. Let's look at Bitcoin. Segwit was activated August 1st, at the moment probably only a handful of wallets on Android, iOS, and desktop support, sending and receiving from Segwit-capable addresses. Even those are still using addresses wrapped in P2SH, the ones that start with the three, not using the new Segwit-native Batch32 addresses, which start with BC1. That, again, is a matter of adopting the new technology. Not many wallets adopt technology to handle fees gracefully, replaced by fee, child-pace for parent, bumping fees, and things like that, fee estimation technology. All of that really happens at the wallet level. If those things are easy to use in a wallet, then users can take advantage of these new technologies. If your wallet doesn't support them, you can't really use them. Finally, other forms of infrastructure. ATMs are quite important, the ability to buy cryptocurrency for cash. If you've ever used a Bitcoin ATM or another cryptocurrency ATM, you'll know that often they don't work. You go up there and the system is out of service, or it has problems handling fees. Again, these are matters of maturity. Or you might be shocked at how big the premium is for the convenience of being able to pay with cash, and instantly transact with cryptocurrencies. So ATMs are still an evolving space. Drew asks the next question, what is the next big upgrade in Bitcoin development? Will we see Schnorr and Mast in 2018? What is Core focusing on next? We will see Mast first, and Schnorr will come, I believe, second. Mast is a form of pay-to-script hash, but it is a pay-to-mercle-root hash. A pay-to-mercle-root type construct in a script allows you to have a complex set of conditions implemented in a script. Each of the conditions is a leaf on a tree, and what you store in the transaction is only the root of the tree. When you try to spend it, you can present just the branch that you are spending, plus a proof that shows that it was part of the tree without showing any of the other information. It has two major benefits. One is that it allows us to do log-to-end improvements on the size of the redeem scripts... that go into inputs and spend transactions. That is a big optimization, which will allow for more efficient use for multi-stake, as well as the possibility of doing much more complex scripts without making the actual transaction size massive. The second big advantage is that it enables you to have a lot more privacy, because if there are a complex set of conditions in how you can redeem a transaction today, then at the moment you have to show all of those conditions as one redeem script anytime you spend from that address. With Mast, you only show the condition that you are using to spend, and the other conditions that may exist are invisible. No one knows how many conditions exist, no one knows how complex those conditions are, or what kind of keys they require. That increases privacy. In fact, we can also see the possibility of implementation of Mast in somewhat more complex multi-clause scripts like Lightning Network. The Mast could be used fairly quickly to optimize the size of Lightning transactions. Mast was finalized as a series of three Bitcoin improvement proposals. Maybe about a month or two ago, the three Bitcoin improvement proposals are exactly the same. I think 98 was the first one, which defines a new type of Merkle tree, slightly different from the one Satoshi uses in blocks. It is a fast Merkle tree that has some security considerations that are particularly interesting in the case of Mast. It is an improvement on the Merkle tree data structure. The second one is the specification of Mast itself. I think the third one is the upgrade mechanism, which is to use a BIP-8 signaling on a previously unutilized opcode. Long story short, Mast specification is ready. The first implementation as a pull request to Bitcoin Core for this new Mast specification, including its soft fork activation, has already been submitted to Bitcoin Core last week. This is now not just specification, but also implemented code, which is ready to go in, probably for testing on TASnet in the first stage. It is going to be in early 2018, I believe. Snore signatures and signature aggregation are the most likely things to come immediately after that, because of the optimization capabilities they have. Although the other possibility is some kind of side-chain, drive-chain change that allows you to do two-way pegs, by evaluating an SBB proof in the script. Mast also implements tail-call semantics, which is a very interesting development, which I am going to explain at a later point. I think that might be also helpful for doing SBB proofs. Yes, I do think the block size will go for 1 megabyte. In fact, the block size is over 1 megabyte. Segwit was a block size increase. I expect we will see additional block size increases, including ones implemented with a hard fork. That is part of the roadmap of Core, as well as other development organizations that are working in this space. Eventually, we will achieve a point where we have consensus to do a reasonable base block size increase, in order to leverage that in the second or third layer. The next one up is Bitcoin Roadmap, asked by Trolls. That is how I pronounce the name here. It is T-R-O-E-L-S, pronounced Trolls. I find it very hard to get an overview of the Bitcoin roadmap. As Bitcoin is decentralized, I guess it is harder to make a roadmap. But where and how do the core dev team suggest new features? And how to see if they will go into an update, or a soft fork, or a hard fork? There are two places where you can keep up-to-date, at least from my perspective. Those are the two places where I keep up-to-date. One is the Bitcoin developers mailing list. That mailing list is hosted on the Linux Foundation, and it is open to anyone who can subscribe and watch the conversations. There is some conversation on there that is relevant, where you see some of the developers who are developing new features and capabilities. They make proposals, they have discussions, and those discussions happen by email. There is also quite a bit of noise as various people come in and, let's say, introduce various crazy ideas that don't really have much traction. The other place to follow is the GitHub repository. The GitHub repository for Bitcoin Core, if you follow the pull requests, the issues, and the conversations there, then you can see the immediate short-term roadmap of what is happening in terms of updates to the software. There is a lot of activity going on, so that is the advice I would give. There is a software roadmap, it is developed by consensus. There are a lot of people who have a lot of opinions and a lot of discussion going on. You can see how gradually something starts off as an idea or suggestion. For example, at the moment one of the interesting ideas being discussed is a system called taproot and graftroot, which are systems for combining massed, mercilized, abstract syntax trees with a default script that looks like a public key payment. In such a way that you can differentiate between transactions that are complex scripts and simple public key payments. It is a new privacy enhancement, very interesting. A lot of conversation happening on the Bitcoin developers mailing list, but that kind of thing is very far from code and a pull request. It might be a year before we actually see code around that. Who knows?