Reviewing Code Is Mind-Numbing: Q&A With Bitcoin Maintainer Andrew Chow

He stumbled upon Bitcoin in high school while looking for ways to pay for his favorite video games. He now reviews and improves Bitcoin’s code for a living. Sometimes it's boring and mind-numbing but he does it anyway. Somebody has to.

AccessTimeIconMar 10, 2023 at 3:35 p.m. UTC
Updated Mar 10, 2023 at 5:56 p.m. UTC

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” for 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 fellow Bitcoin developers – as “pull requests” or “PRs.” Chow and other maintainers then approve or “merge” those changes into Core’s source code. The “code review” is critical to ensuring no buggy code gets merged.

The process is transparent, and as Chow combs through commits he livestreams the process on Twitch.

Chow is a gamer at heart, and only 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's now in his mid-20s, gets paid as an engineer at the 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 Bitcoin faces today. Most Core developers are keen on writing code for new features, but few enjoy the more mundane task of reviewing code submitted by their peers. Chow says more contributors need to focus on code review to tackle the 300-plus 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 over op_vault and Speedy Trial. Here’s a partial transcript of that 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 supervised credit card – and I didn't have an allowance. But Steam was selling games for bitcoin. If you do PC gaming, you can download Steam and it has basically all the PC games.

Also, on, you could sell bitcoin for stuff. Well, I wanted to play games. I wanted to buy them. I mean, I'm okay with pirating but, you know, pirating things is kind of sketchy. You don't know what you're downloading. It could be complete malware.

So I was, like, this bitcoin thing is fully electronic. Maybe I can use that to buy games – but how do I get bitcoin? Maybe I can do some work and get paid in bitcoin.

I know a few people who did that. So that's how I learned programming. I’d go on BitcoinTalk and people would say, “I will pay you however much 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 was definitely buying drugs with bitcoin.

So that's how I got into Bitcoin. And eventually I was like, “Well, I'm using this wallet and I'm running into these issues. I clearly know how to write a program. Maybe I can fix this wallet.” That's how I got into doing development.

I was running this thing called Armory. Which was basically not maintained. I mean, it's still kind of maintained by one guy, so barely.

By the time I was using it, it was kind of a mess and it didn't always work. I was finding that some of the problems that were happening in Armory were caused by things that Bitcoin Core was doing. So I started going into Bitcoin Core and asking what’s Bitcoin Core doing? Oh, Bitcoin Core has this bug that's causing us to have a bug.

Armory was doing something not recommended, which was to read the block files directly from Bitcoin Core – you're not supposed to do that. When they changed the format, it broke everything.

I was trying to reconcile the two, and then Armory just 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 ratio of Bitcoin contributors who review code versus contributors who write code. Can you share your thoughts on that?

Our main bottleneck in Bitcoin Core has been review. We have 300-plus 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 one person usually writes it, but we need multiple people to review it, give an approval or leave comments. Therefore, we must have more reviewers than people writing, but that's just not how it works.

Personally, I find code review to be a little bit boring. It's a little annoying and it can be kind of mind-numbing. But I still do it. I guess it's like a necessary evil and it's because I don't find it fun. If I do it enoug I start feeling like I’ll burn out because it's no longer enjoyable.

So you have to find some balance between writing code and reviewing code. It’s a bit of a catch-22. We have to have more reviewers than coders, but how do you become competent enough to review code if you're not writing code? It's a conundrum.

We're in a bear market and organizations like Brink that fund Bitcoin development are saying funding is down by about 50%. Why do we need to pay Bitcoin contributors and developers?

Fundamentally, every piece of software has bugs. There will always be bugs to find and bugs to fix. That's just general software maintenance that must 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 might just stop running. And so, there needs to be constant work just to keep it up to date.

So there are always things to update, even without new features. But there are new features and we do want to improve Bitcoin. Not just the consensus rules, but also how we relay transactions, what kind of transactions we accept into the mempool and the peer-to-peer protocol.

There can be DoS vectors we want to fix or change that maybe haven't been discovered yet. There's always something.

If I'm a new Core contributor, what are some of the big issues I would need to know about?

There are currently a number of issues that exist, like pinning attacks, that are pretty well documented. It seems to be that no one exploits them, but that's not a good reason to not fix them.

There's been a lot of work on the mempool – how and what transactions are accepted into the mempool, what methods there are for fee bumping, and things like that. It's relevant to Lightning and other [layer 2] networks.

What’s a “pinning attack?”

If both of us open a Lightning channel together, I can make it so that you can never bump the fee on that transaction. So I can make it perpetually low-fee and it never gets mined, then try to double-spend it later.

There's a bunch of attacks you can do with the existing mempool policy rules. These are documented on the mailing list and they're 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 on making improvements so that we don't have these pinning attacks, or at least, if you want to pin a transaction, it'll be really expensive.

We also discussed op_vault and Speed Trial yesterday. There have been some tensions around James O’Beirne’s recommendation to deploy op_vault using Speedy Trial. Any comments?

With a new proposal like that, deployment should be the last thing to think about.

Some ideas on how to deploy things are, for some reason, contentious. If you want to have a discussion about the proposal, having deployment in there kind of causes it to be derailed.

So I do think James putting that in there was probably a mistake. The Taproot deployment section wasn't 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 deal with deployment after we figure out what we want the code changes to be.

Speedy Trial was an experiment for Taproot. We've tried different deployment methods over the years with varying degrees of success.


Please note that our privacy policy, terms of use, cookies, and do not sell my personal information has been updated.

CoinDesk is an award-winning media outlet that covers the cryptocurrency industry. Its journalists abide by a strict set of editorial policies. In November 2023, CoinDesk was acquired by the Bullish group, owner of Bullish, a regulated, digital assets exchange. The Bullish group is majority-owned by; both companies have interests in a variety of blockchain and digital asset businesses and significant holdings of digital assets, including bitcoin. CoinDesk operates as an independent subsidiary with an editorial committee to protect journalistic independence. CoinDesk employees, including journalists, may receive options in the Bullish group as part of their compensation.

Frederick  Munawa

Frederick Munawa was a Technology Reporter for Coindesk. He covered blockchain protocols with a specific focus on bitcoin and bitcoin-adjacent networks.