Beta
Today is a good day! Btcd, our alternative, full-node Bitcoin client written in Go, has now officially entered Beta (Release Notes). To our knowledge, btcd is the most complete alternative full-node daemon available. We have made it a priority to be as close of a drop-in alternative to Bitcoin Core as possible while making several improvements along the way.
It has certainly been a fun ride implementing nearly all facets of the original Satoshi client with a proper modular design and improved to better meet the demands of business users. We’d like to thank the countless alpha testers who provided invaluable feedback and even code in several instances.
Although there are still 3 major features I’ll discuss later in this post that we want to implement prior to moving to a full, non-Beta, release, we decided that it’s time to move to Beta test for the following reasons:
- Btcd has been running in production on mainnet for over 6 months on the Coinvoice servers with no unexpected downtime and no issues.
EDIT: As pointed out on reddit, there was one chain fork on the 4th of February that I overlooked. This issue was fixed within 3 hours and had no effect on the Coinvoice service. - At this point, it is theoretically possible for the entire Bitcoin network to run only on btcd including mining via cgminer. Please note that we firmly believe there needs to be multiple implementations, so we wouldn’t want this situation to occur at all, but it serves to illustrate the current completeness of btcd.
What’s Left Before Full Launch
As previously mentioned, there are 3 main features we plan to implement and rigorously test prior to moving to a full launch (non-Beta) release:
- Add support for getblocktemplate mining. As previously mentioned, btcd supports getwork, but that is deprecated by Bitcoin Core and will eventually be removed.
- Full support for SPV clients. Our wire protocol package, btcwire, already supports the network messages necessary for SPV clients, however btcd does not yet handle bloom filters.
- Support for protocol version 70002. Just as the previous point, btcwire already supports the network messages necessary for full protocol version 70002 support, however btcd does not yet make use of that infrastructure and therefore negotiates to a maximum protocol version of 70001.
Congrats! Hope to see a 1.0 very soon.
Thanks Jimmy.
Great stuff! Might use it on my server. How is the performance vs bitcoind?
Hey Kris,
Here is a link to a reddit thread in which Josh and I answer this question: http://www.reddit.com/r/Bitcoin/comments/26h3o8/btcd_beta_announcement/chr7p37
Hope that answers it satisfactorily for you!
Hmm. Thank you. However i have refined my question. I’m not so sure i care too much about the speed differences(if any), i more worry about CPU-usage when a new address is created and send and move commands are used. I suppose i could just test it, but then i might have to download a new blockchain? I only have room for one blockchain on my server so 😛
Kris,
From your question, it sounds like you’re after wallet commands. Btcd intentionally separates the wallet bits out into a separate process, so getnewaddress/send/move and such aren’t exposed by btcd. We are working on a separate process named btcwallet which exposes that functionality. Unlike btcd, it’s still alpha. I’ve asked Josh to elaborate more on support/speed of those as he’s more familiar with that side than I am.
Creating addresses (which involves creating a random 32-byte private key and the associated public key) will be more CPU intensive for btcwallet than for Bitcoin Core wallet. This is because the creation of the private key relies on a deterministic algorithm to “chain” the next address based on the previous, which allows for the recovery of future generated private keys from an earlier backup. Bitcoin Core does not support deterministic wallets, and only needs a random number generator to create new private key bytes. Without deterministic address chaining the CPU usage is lower, but the downside to this design is that previous backups may not include all addresses you created at a later time.
Proper account support does not work yet, due to how our wallet file (originally a copy of Armory’s wallet) only has one deterministic address chain. I plan on tackling this issue once we implement and switch to a bip32 wallet, where multiple accounts can be implemented using multiple bip32 keypair chains.