Jeff asks, "What projects are most needed in the space right now?" That is a great question.
I'm afraid the answer is rather boring. You might think that what we really need right now...
is some kind of artificially intelligent neural network, 3D printed drones, and a Mars expedition.
The truth is, the most important projects at this stage are basic infrastructure projects,
projects that are not very exciting, with the "latest ICO for prediction markets," "run by an AI."
The projects that are most important in this industry are basic infrastructure:
exchanges, wallets, ATMs, and education systems.
Let's go through those one by one.
You might think we already have enough exchanges,
but exchanges [can be] very much attached to a local culture, language, and set of regulations,
especially when it comes to exchanging the national currency for cryptocurrency and [vice versa].
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 [yet].
I think one day it will be, but not yet.
Exchanges are necessary and you can't build an exchange that covers every country.
Almost all exchanges are very specific to one country.
From that perspective, [each of the] 194 countries needs three or four exchanges to have healthy competition.
That is about eight hundred exchanges worldwide for specific countries, not counting specialist exchanges...
and various other permutations on that idea.
We are still quite far from that goal. I remember the days when there was [only] one exchange: Mt. Gox.
We were all having difficulties with latency and security in trading. Fortunately, we now have a wide open space.
Next, wallets. Wallets are the frontend of this industry, the part that interacts directly with [most] users.
Users who are new. Their first experience with cryptocurrencies will be through a wallet interface.
If that interface is intuitive to use securely, they can more easily use this technology.
But if the user interface sucks, is confusing, lacks certain features, and causes security problems,
then users will have difficulty with cryptocurrencies.
Wallets are really important and really difficult. They require [knowledge of] user design and experience,
they require the latest cutting-edge [features].
For example, we have new [capabilities available] in Bitcoin, [like Segregated Witness].
In Ethereum, you have ERC-20 tokens.
The state-of-the-art moves very fast.
Let's look at Bitcoin: [the] Segregated Witness [soft fork] was activated on August 1st.
At the moment, only a handful of Android, iOS, and desktop wallets support...
sending and receiving with SegWit addresses; even those are still using addresses wrapped in P2SH,
the ones that start with a '3,' not the native SegWit 'Bech32' addresses that start with 'bc1.'
That is a matter of adopting the new [features].
Not many wallets have adopted [features] to handle fees gracefully, [like] replace-by-fee, child-pays-for-parent,
and other fee estimation [algorithms and options], all of which happens at the wallet level.
If those things are easy to use in a wallet, then users can take advantage of [discounts].
If your wallet doesn't support them, [your users] can't use them.
Finally, infrastructure like ATMs, for the ability to buy cryptocurrency with cash, are quite important.
If you have ever used an ATM for bitcoin or another cryptocurrency, you know that they often don't work.
When you use one, [many times] the system is out of service, or has problems handling fees.
These are matters of maturity.
Or you might be shocked at the premiums [ATMs charge] for the convenience of [exchanging] with cash.
ATMs are still an evolving [business].
Drew asks the next question: "What is the next big upgrade in Bitcoin development?"
"Will we see Schnorr [signatures] and MAST in 2018? What is Bitcoin Core focusing on next?"
We will see MAST first, and Schnorr [signatures] will come second.
Merklized Abstract Syntax Trees (MAST) is similar to pay-to-script-hash (P2SH), [using merkle root hashes].
[This] construct of [hiding unexecuted script branches] allows you to have [complicated redemption conditions],
where each of the [spending / redemption] conditions is a leaf on a Merkle tree.
What you store in the transaction is only the root of that tree [of conditions].
When you [use one of the spending conditions],
you [only need to present] a branch, plus a proof that it was part of the tree,
without [needing to] show any of the other branches.
It has two major benefits.
It allows us to [reduce the size of redemption stack to O(log n), where 'n' is the number of branches],
that go into inputs [when spending].
That is a big optimization which will allow for more efficient, useful multi-sig and more complex scripts,
without making the transaction size massive.
The second big advantage is that it enables more privacy.
Today, if there are a complex set of conditions for how you can redeem [an output],
you [must] show all of those conditions any time you spend from that address.
With MAST, you only show the condition that you are using to spend; other [unexecuted] conditions may exist,
but they are invisible [until you use them]; no one [else] knows how many or how complex those conditions are,
or what kind of keys they require, so that increases privacy.
We see also the possibility of implementing MAST in complex, multi-clause scripts of the Lightning Network.
I think MAST could be used [there] fairly [soon], even to optimise the size of Lightning payments.
MAST was finalized after a series of three Bitcoin improvement proposals (BIPs):
BIP-98, which defines a [more efficient Merkle hash-tree construct], slightly different from the one Satoshi uses.
which is fast and has some security considerations that are particularly interesting in the cast of MAST;
[BIP-114], the specification of MAST; [and BIP-9], the upgrade mechanism, signalling [via the version field].
Long story short: the MAST specification is ready, the implementation has a pull request to Bitcoin Core,
including its soft fork activation, as of last week.
This is now not just a specification, but implementation code which is ready to go for testnet in the first stage.
[That will happen] in early 2018. Schnorr signatures and signature aggregation [will] most likely come after,
because of the optimization capabilities they have.
The other possibility is some kind of sidechain or drivechain change for two-way pegs by evaluating...
an SPV proof within the script.
We will see [what happens]. MAST also implements tail call semantics [by Mark Friedenbach],
a very interesting development which I'm going to explain it at a later point.
That might also be helpful for doing SPV proofs.
Yes, I do think the block size will go over one megabyte. The block size is over one megabyte right now.
SegWit was a block size increase. We [may] see additional block size increases, including ones...
implemented with a hard fork.
That is part of the Core roadmap [research], as well as other development organisations working in this space.
I think, eventually, we will achieve [enough] consensus to do a reasonable base block size increase,
in order to [better] leverage the second or third layers.
[The] next question is [about] the Bitcoin roadmap, asked by Troels.
"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."
"Where and how does the Core development team suggest new features? How do we see if they...
will go into an update, soft fork or hard fork?"
There are two places where you can keep up-to-date -- at least from my perspective...
[in terms of] where I keep [myself] up-to-date.
One is the Bitcoin developers' mailing list, hosted by the Linux Foundation. It is open to anyone.
You can subscribe and watch the conversations. There is some conversation on there that is relevant,
where you see developers [working] on new features and capabilities, making proposals, and discussing them.
Those discussions happen by email.
There is also quite a bit of noise, as various people come [to] introduce crazy ideas that don't have much traction.
The other place to follow [updates] is the Github repository for Bitcoin Core.
If you follow pull-requests and issues there, you can see the short-term roadmap of [software updates].
[The GitHub repository has] a lot of activity, so that is the advice I would give [for places to receive updates].
There is a software roadmap, developed by consensus, [through] a lot of discussion with a lot of people.
[In the mailing list and repository], you can gradually see how something starts as a suggestion...
For example, the interesting ideas being discussed at the moment are called Taproot and Graftroot.
which combine MAST with a kind of default script that looks like a public key payment, in such a way that...
you can't differentiate between transactions [with] complex scripts and simple public key payments.
It is [further] privacy enhancement.
Very interesting, with a lot of conversation happening on the Bitcoin developers' mailing list.
But that [update] is [still] very far from code and a pull request. It might be years before we see code.