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
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..