I am pleased to announce that Decred testnet is going live today, Wednesday, January 27th. Decred testnet is intended to be used as a sandbox for testing the various features and behavior of Decred. Interested parties are now free to experiment on testnet with:
- Sending and receiving transactions
- PoW mining software, e.g. cgminer
- PoS mining with dcrwallet
- Writing or porting software for Decred
We are releasing the following binaries:
- dcrd – the chain daemon
- dcrwallet – the wallet daemon
- dcrctl – the command line RPC tool
- cgminer – mining software
The dcrd, dcrwallet and dcrctl binaries are provided for both 32 and 64-bit versions of the following OSes: Windows, OS X, Linux, DragonflyBSD, FreeBSD, NetBSD and OpenBSD. CGminer is provided as a binary for 32 and 64-bit Windows and Linux.
We are excited to announce a new digital currency, Decred. The main technical features of Decred and the motivation for including them are discussed in my previous blog entry.
Decred is an open, progressive, and self-funding cryptocurrency with a system of community-based governance integrated into its blockchain. At its core is a hybridized proof-of-work proof-of-stake (PoW/PoS) consensus system that aims to strike a balance between PoW miners and PoS voters to create a more robust notion of consensus. The project is a result of the theoretical proposals brought by proof-of-activity (PoA) and MC2 in 2013. Decred development started in April, 2014 with a single developer and expanded to include the btcsuite developers shortly thereafter.
Decred is built in the spirit of open participation and we have provided below a full disclosure of the technical features of the system, wallets and mining, initial funding and distribution, project governance and development, and a group contribution timeline. We hope to launch mainnet on January 18th, 2016, and will provide additional details in this thread. Everyone is welcome to participate, and you are certainly welcome to join the development and project groups if you have interest in contributing to our efforts!
After spending more than 2.5 years financing and overseeing the development of an alternative full-node Bitcoin implementation, btcsuite, it has become clear that Bitcoin has several serious organizational problems. In my previous blog entry, I characterized these problems and their various facets. The main problems are governance, funding development and proof-of-work (PoW) miners having too much power. Over the past 1.5 years I and several developers have been working to propose, code, test and evaluate modifications to Bitcoin that would address these issues. The most fundamental of the changes we have made are based on proposals for hybridized PoW/PoS (proof-of-stake) systems, such as MC2 and proof-of-activity (PoA) by Iddo Bentov, Charles Lee, Alex Mizrahi and Meni Rosenfeld. In order to create a sustainable system of governance, we have created a project Constitution and extended the notion of consensus hybridization to apply more generally as one of several layers in a stratified consensus system. This stratification allows various groups of stakeholders to have representation at various consensus layers. Beyond a layered hybridized consensus system, we have added a consensus rule that allocates 10% of each block reward to a development fund that will be used to pay for ongoing development and related activities. By allocating 10% of each block subsidy to the development fund, continuous development and improvement of the software is possible without the conflicts of interest present in current Bitcoin Core (BC) development process.
The notion of hybridized PoW/PoS is fundamental to what follows, so a bit of an overview is warranted. A consensus system that uses pure PoW is subject to a number of issues: denial-of-service via mining empty or artificially small blocks, censorship by not including certain transactions in blocks and miners having the ability to block or force consensus changes. One way of looking at this situation is to view PoW as providing a single authentication factor to the consensus system, where the PoW is typically performed by one of a small number of entities that do not necessarily represent the rest of the participants in the system. While this process is fundamentally decentralized, practical considerations lead to the PoW mining process becoming very centralized, similar to trusted 3rd party systems, e.g. banks. Hybridizing PoW and PoS creates a second authentication factor for consensus, wherein PoS miners can vote for or against the previous block generated by a PoW miner. If enough PoS miners vote against the previous block, the PoW reward from that block can either be reduced or eliminated entirely, meaning that PoS miners act as a check on the behavior of PoW miners. In the scenarios described above, PoS miners can vote against PoW blocks that they disapprove of, providing a clear incentive for PoW miners to not engage in what most of us would agree is questionable behavior.
I have been participating in the Bitcoin ecosystem for the past 2.5 years, and it has become clear to me that there are several persistent and serious issues with Bitcoin from an organizational perspective. While many people are not familiar with who I am, they may be familiar with the btcsuite project, which I finance entirely by myself and contribute to via the developers I work with. In early 2013, after one of my developers had a less-than-pleasant interaction with the Core developers regarding porting bitcoind to OpenBSD, I decided that making an alternative from-scratch implementation of Bitcoin would be an interesting project and benefit the Bitcoin community by offering an alternative to the Bitcoin Core (BC) monoculture. Having rebuilt the Bitcoin infrastructure from the ground up on my own dime, I have a rather unique perspective on Bitcoin despite being late to the game. I have identified what I consider to be several persistent and severe problem areas with Bitcoin: project governance, funding development and proof-of-work miners having too much power.
As many of you are well aware, Bitcoin has been suffering from a long-running clash of views about whether to increase the maximum block size or not. Informal surveys and content on twitter indicate the majority of businesses and miners support increasing the block size, but a majority of BC developers oppose this increase. There are at least 2 less-than-ideal resolutions to this argument:
- Allow BC developers to force the maximum block size to stay at 1 MB, effectively vetoing the community.
- Create a fork of BC that allows larger blocks, and have enough miners and businesses switch to force the block size increase, effectively vetoing the BC developers.
Neither of these options are very appealing, and more importantly than any resolution that is eventually reached, it reflects a very real crisis in governance. In order to better understand the current crisis, it is worthwhile to quickly recap the history of Bitcoin governance since it was introduced in 2009.
What we don’t want our websites to look like
We are currently looking to fill 2 new (remote) developer roles at Company 0:
- a UI/UX developer that will focus on building native Windows and OSX GUIs on top of btcwallet
Bitcoin has redefined what it means to possess and transfer value, in that the value is no longer entrusted to a 3rd party, e.g. a financial institution, and is instead based solely on the cryptographic keys (“keys”) possessed by the owner or controller of that value. While it is substantially liberating to not require 3rd parties to effect transfers of value, this liberty comes with a substantial increase in personal or organizational responsibility on part of the party that controls the keys that correspond to that value. In order to spend bitcoins, one must create a transaction signed with one or more of these keys on some kind of computer hardware, whether it’s a desktop computer or a calculator-like device. Compromise of the hardware or software that handles these keys could lead to immediate irrevocable theft of the funds they correspond to, which is a much worse failure mode than what could happen with funds stored at a typical financial institution.
Put bluntly, this means “if you get hacked, your funds are gone”, a rather serious and hopefully avoidable failure scenario. Taking a note from military and intelligence services, I felt that it made sense to electromagnetically isolate hardware used to handle Bitcoin keys from their surroundings to reduce their attack surface. Conveniently enough, this problem has already been addressed for the past several decades by a number of companies, so I contacted LBA Group about making a customized version of an existing Faraday cage they manufacture, the EMFaraCage FC-10S. The customized cage has filtered 110V power, an internal power strip, intake and exhaust fans and can hold 2 desktop computers.
EMFaraCage front (open)