2018 was a productive year for the bchd project. Not only were we able to fork btcd and update it with the entire Bitcoin Cash ruleset, but we were able to make quite a few improvements well above what btcd had to offer and check off a number of items from our wish list in the process.

In 2019 we plan to build on that progress and make bchd into one of the most feature rich node implementations that Bitcoin Cash has to offer. The following is our plans for both the bchd blockchain server and bchwallet.


Remain in Consensus
Bitcoin Cash will likely do two hardforks again this year and our number one priority is to implement the rule changes in a timely manner so that everyone has plenty of time to upgrade. For May most of the proposed changes look like they will be fairly trivial to implement with the lone exception of Schnorr signatures which will require a native Go implementation that is going to need lots of thorough review.

Compact Blocks / Graphene / XThinner
One of the remaining issues that we inherited from btcd is that there is no block compression implemented. We’ve made some progress implementing compact blocks already but we hope to be able to have Graphene or XThinner (maybe both) implemented this year as well.

The legacy jsonrpc API is a little crufty and annoying to work with. Our plan is to create a much more modern API based on gRPC. Once this is implemented we believe bchd will be the best backend option for applications which need access to blockchain data. This will include the ability to download SPV proofs so that developers can use it to build server-based SPV wallets.

Double Spend Proofs
Once a specification for double spend proofs is finalized and agreed upon we’ll implement it in bchd. This work will include all the functionality necessary to use the proofs in applications including a streaming API, bloom filtering support and support for neutrino based wallets.

QUIC is a new transport protocol created by google to improve on the shortcomings of TCP. Sometime this year we’re going to enable QUIC as a transport option along side TCP and likely make it the default transport used for connecting to other bchd nodes. One of the main benefits to QUIC is we finally get encrypted and authenticated connections using TLS 1.3 so SPV wallets which connect to bchd nodes and use QUIC will receive a nice privacy and security boost.


The following is on our roadmap for the bchwallet wallet software which can either connect to a bchd full node via the API or operate in neutrino SPV mode.

BIP70 Support
We’re going to add support for both paying BIP70 payment requests as well as creating and serving payment requests to other wallets. The goal here is for bchwallet to eventually be a solid choice as a backend for merchant point-of-sale software.

Double Spend Detection
Making use of the double spend proofs described above, we’re going to make the software detect double spends and notify the user. Again, this is critical functionality for any pure BCH point-of-sale solution.

Stealth Addresses
This feature has been one of the most requested features for quite a while so it makes sense to provide it as an option in bchwallet. We recently changed how bchd builds the GCS filters used by neutrino to be more liberal with OP_RETURN so even neutrino wallets will be able to use this feature.

Payment Channels
In a previous post we alluded to some preliminary work that has been done on payment channels. We’re going to need to wait until after the May hardfork to fix malleability before this code will be usable but the goal here is to provide a bi-directional functionality within the software and the necessary APIs to use it.

That’s it. If any of these features interests you enough to want to work on them please get in touch. We appreciate all the help we get!

An alternative full node bitcoin cash implementation written in Go (golang)

An alternative full node bitcoin cash implementation written in Go (golang)