Q&A with Bitcoin Maintainer Andrew Chow

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 thought 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 said, “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 numbing. 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 want to burn out because it’s no longer enjoyable.

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 taking advantage of them, but that’s not a good reason not to

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 for Lightning and other L2 networks.

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.