Implementing full Bitcoin Cash (BCH) support on Coinbase required more work than most would assume, said the company’s leader on that project, Josh Ellithorpe. Speaking at the Satoshi’s Vision conference in Tokyo, Ellithorpe lifted the hood to give some insight into the hours of re-writing and testing that went into adding BCH while keeping billions of dollars in digital assets secure.
Subscribe to the Bitsonline YouTube channel for more great interviews featuring industry insiders & experts
Coinbase, the world’s best known and most popular cryptocurrency exchange, implemented full buy/sell/storage support for Bitcoin Cash in late December 2017. The move was so popular it forced Coinbase to stop trading briefly, but the engineering team managed to keep track of everyone’s balances while things settled down.
Adding a new cryptocurrency to an exchange is more complicated than just opening a wallet and hitting the “go” button. And BCH’s similarities to BTC actually made the task a lot more complicated, rather than simple.
Exchanges may broadcast platitudes about security of users’ funds being the number one priority during times of change, but to engineers it’s a very real issue. Any error leading to a major hack or theft would plunge Coinbase (or any company) into a world of both financial and regulatory pain.
Handling UTXOs Was the Main Task
The most time-consuming task was UTXO management (UTXOs, or unspent transaction outputs, is how the Bitcoin network keeps track of who has the right to spend what funds). Coinbase’s UTXO management code, nicknamed “Wallace” wasn’t built to handle forked coins, and now it needed to find a way to track unspent outputs on two coins with the same history.
Repopulating Wallace with UXTO data from the Bitcoin genesis block to the hard fork that created BCH would have taken over a month, so Coinbase created a two-pronged strategy that synced and rewound the blockchain data to double-check. Ellithorpe said:
“We don’t want to be thrashing around, trying to figure out ‘why did this break?’ We always want to know why it broke … we don’t take risks that puts anyone in any danger of losing their money; we were really happy we were able to do that for our customers.”
Riding the Monorail
The codebase that forms the backbone for Coinbase’s exchange and related services is called “the Monorail” — written in Ruby (Rails) it also provides the APIs that drive Coinbase’s mobile apps and other services.
When Coinbase first launched as a BTC/fiat exchange, that’s all the Monorail needed to support. Adding LTC and ETH later required several new conditional blocks to handle specific rules for each coin, but adding more currencies increased the complexity even further.
Ellithorpe and the engineering team performed a “massive refactor” on the Monorail code to provide objects for separate currencies, which included specific rules for things like address display, number of confirmations, fees and special accounts.
The work means Coinbase will be able to introduce support for new coins in the future with less hassle (though of course neither Ellithorpe nor anyone at the company is able to say what, if any, they’re working on).
The Bitcoin Cash Similar Address Problem
Despite all the engineers’ work to keep funds secure, the nature of the BTC/BCH shared protocol and history means user error can still lead to loss of funds. Sending BCH and/or BTC to the wrong addresses is a very real issue that Coinbase has worked hard to mitigate, Ellithorpe said.
Coinbase uses the newer BCH “CashAddr” format addresses by default, but must also support legacy addresses