Few people understand the key technical issues currently facing the worlds 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 Cores source code. The code review is critical to ensuring no buggy code gets merged.

Chow is a gamer at heart, and only got into Bitcoin in high school to pay for video games he couldnt otherwise afford. His parents wouldnt 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 Cores 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. Heres 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 purse.io, 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. Id 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 whats 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 its 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 Ill burn out because it's no longer enjoyable.

So you have to find some balance between writing code and reviewing code. Its 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.

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

The rest is here:

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