Q&A with Bitcoin Maintainer Andrew Chow
Join the most important conversation in crypto and web3! Secure your place today
Few people understand the key technical issues currently facing the world’s dominant cryptocurrency. Andrew Chow is one of them.
Chow is one of four “maintainers” of Bitcoin Core (or just Core), the most popular software for connecting to the Bitcoin network.
Maintainers review changes to Bitcoin Core known as “commits”, which are submitted – by other Bitcoin developers – as “pull requests” or “PRs”. Chow and other maintainers approve or “merge” these changes into Core’s source code. The “code review” is crucial to ensure that no buggy code is merged.
The process is transparent, and as Chow goes through commitments, he livestreams the process on Twitch.
A gamer at heart, Chow first got into Bitcoin in high school to pay for video games he couldn’t otherwise afford. His parents wouldn’t give him a credit card, open a bank account for him or even give him an allowance. He resorted to freelancing on the BitcoinTalk forum and began writing code in exchange for bitcoin (BTC).
Chow, who says he is now in his mid-20s, is paid as an engineer at Bitcoin infrastructure firm Blockstream, where aside from a few corporate tasks, his main priority is working on Bitcoin Core.
He says code review is one of the biggest challenges facing Bitcoin today. Most core developers are eager to write code for new features, but few enjoy the more mundane task of reviewing code submitted by peers. Chow says more contributors need to focus on code review to tackle the 300+ PRs in Core’s GitHub repository. The community has a Bitcoin Core PR Review Club that meets weekly to help newer contributors learn about the review process.
Chow agreed to an interview with CoinDesk at the Advancing Bitcoin conference in London. He elaborated on why code review is so critical, explained what Bitcoin Core contributors do every day, and weighed in on the current debate about op_vault and the Speedy Trial. Here is a partial transcript of the interview.
CoinDesk: How did you discover Bitcoin?
Andrew Chow: When I was younger, in high school, I didn’t have a bank account because I was under 18. My parents didn’t open one for me. I didn’t have a credit card—even a monitored credit card—and I didn’t have an allowance. But Steam sold games for bitcoin. If you are into PC gaming, you can download Steam and it has pretty much all the PC games.
On purse.io you can also sell bitcoin for things. Well, I wanted to play games. I wanted to buy them. I mean, I’m okay with piracy, but you know, piracy is kind of sketchy. You don’t know what you’re downloading. It could be completely malware.
So I was, like, this bitcoin thing is all electronic. Maybe I can use it to buy games – but how do I get bitcoin? Maybe I can do some work and get paid in bitcoin.
I know someone who did. So that’s how I learned programming. I’d go on BitcoinTalk and people would say, “I’ll pay you any amount to write me a script that does this.”
Well, that seemed simple enough. I also had a friend in high school. He was, like, “Hey, have you heard about this bitcoin thing? I think you might like it.” He definitely bought drugs with bitcoin.
So that’s how I got into Bitcoin. And finally I thought, “Well, I’m using this wallet, and I’m running into these problems. I obviously know how to write a program. Maybe I can fix this wallet.” That’s how I got into development.
I ran this thing called the Armory. Which was basically not maintained. I mean, it’s still kind of maintained by a guy, so barely.
When I used it, it was a bit of a mess and it didn’t always work. I found that some of the problems that happened in Armory were caused by things that Bitcoin Core did. So I started going into Bitcoin Core and asking what does Bitcoin Core do? Oh, Bitcoin Core has this bug that causes us to have an error.
Armory did something that was not recommended, which was reading the block files directly from Bitcoin Core – you shouldn’t do that. When they changed the format, it ruined everything.
I tried to reconcile the two and then Armory kind of fell off my map. That’s how I transitioned to Bitcoin Core. I eventually stopped working on Armory because I got more done on Core.
Yesterday we talked about the relationship between Bitcoin contributors who review code versus contributors who write code. Can you share your thoughts on it?
Our main bottleneck in Bitcoin Core has been reviewed. We have over 300 PRs open and they need to be reviewed. Whether it’s just to make sure the code is good or just conceptually like “Do we even want this change?”
The problem with every PR is that usually one person writes it, but we need several people to review it, give an approval or leave comments. That’s why we need to have more reviewers than people who write, but that’s just not how it works.
Personally, I find code review a bit boring. It’s a little annoying, and it can be a little unnerving. But I still do it. I guess it’s like a necessary evil and it’s because I don’t think it’s fun. If I do it enough, I start to feel like I’m burning out because it’s not fun anymore.
So you have to strike a balance between writing code and reviewing code. It’s a bit of a catch-22. We need to have more reviewers than coders, but how do you get competent enough to review code if you don’t write code? It is an enigma.
We are in a bear market and organizations like Brink that fund Bitcoin development say funding is down by about 50%. Why do we have to pay Bitcoin contributors and developers?
Basically, every piece of software has bugs. There will always be bugs to find and bugs to fix. There is only general software maintenance that needs to happen.
And even then, the software that exists now cannot last forever. Operating systems will evolve and libraries will evolve and change. Eventually, the software will just stop compiling on a computer; it may just stop running. And therefore constant work must be done to keep it up to date.
So there are always things to update, even without new features. But there are new features and we want to improve Bitcoin. Not only the consensus rules, but also how we forward transactions, what kind of transactions we accept into the mempool and the peer-to-peer protocol.
There may be DoS vectors we want to fix or change that may not have been discovered yet. There is always something.
If I’m a new core contributor, what are some of the big issues I need to know about?
There are currently a number of problems that exist, such as pinning attacks, that are fairly well documented. No one seems to be exploiting them, but that’s not a good reason not to fix them.
There has been a lot of work with the mempool – how and which transactions are accepted in the mempool, what methods exist for fee bumping and things like that. It is relevant to Lightning and other things [layer 2] network.
What is a “party attack?”
If we both open a Lightning channel together, I can make it so that you can never increase the fee on that transaction. So I can make it forever low and it never gets mined, then try to double use it later.
There are a bunch of attacks you can do with the existing mempool policy rules. These are documented on the mailing list and they are definitely problems. If someone tried to exploit them it would be annoying, but I don’t think we’ve seen anyone try to exploit them.
We still want to fix them, and there’s been a lot of work to make improvements so that we don’t have these pinning attacks, or at least, if you want to pin a transaction, it’s going to be very expensive.
We also discussed op_vault and Speed Trial yesterday. There has been some tension surrounding James O’Beirne’s recommendation to deploy op_vault using Speedy Trial. Some comments?
With a new proposal like that, deployment should be the last thing on your mind.
Some ideas about how to distribute things are controversial for some reason. If you want to have a discussion about the proposal, having deployment there will kind of derail it.
So I think James putting it in was probably a mistake. The Taproot distribution part was not defined until after Taproot. The code changes themselves were merged into Bitcoin Core, but not active. It’s not unusual to just say we’ll handle deployment after we figure out what we want the code changes to be.
Speedy Trial was an experiment for Taproot. We have tried different distribution methods over the years with varying degrees of success.
