Iterating Bitcoin

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.

Hybridized PoW/PoS

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.

The hybridized PoW/PoS process we propose is based on that of MC2, which is very similar to but developed independently from PoA. Both of these modifications to the consensus process acknowledge that pure PoS has the problem of there being “nothing at stake” and attempt to blend the positive aspects of PoS with PoW. The notable changes proposed in MC2 and our implementation thereof are:

• Instead of PoS participation being limited to signing a block or not based on a currency-wide lottery, as with Proof-of-Activity’s follow-the-satoshi, PoS participation is based on a lottery process where tickets are bought, the corresponding coins used to buy the ticket are locked. After a maturity period, these tickets can be voted “yea” or “nay” on a block. Once tickets have been voted with and included in the main chain, the PoS miners receive a reward for each vote. This lottery process of locking of coins creates an incentive to hold coins for extended periods of time, which can be viewed as creating an effective interest rate on locked coins. In Bitcoin parlance, this is a mechanism to “reward the hodlers”.

• PoS votes included in a given block can affect the previous block’s PoW reward. If the previous block does not have a majority consensus vote from PoS miners in the current block, all non-PoS transactions in the previous block are invalidated and the PoW miner is stripped of their reward. This means that PoS miners have an effective veto over PoW blocks that cannot muster a majority consensus from PoS voters. PoS miners can apply rules to automate whether they will vote yea or nay on the previous block, e.g. “if the last block had too few transactions in it, then vote nay”. This allows PoS miners to act as a check on PoW miners who mine questionable blocks, but still allows the work performed to be included in the blockchain. Blocks with severe PoS disapproval will never be added to the chain by voters abstaining, however this is a less likely event as PoS miners will desire to obtain their reward now instead of later in the future.
• The average time that coins must be locked for a PoS miner to purchase a ticket, wait for it to mature, vote with it and then receive their PoS reward is roughly 30 days. Since the lottery process for selecting PoS voters on a given block is pseudorandom, the coins for a given ticket may be locked for a very long time before they yield a PoS reward. If a PoS miner fails to vote on a block or their ticket expires, they can redeem the original funds with a revocation.
• PoW miners are incentivized to include all the PoS votes they can into their blocks because their PoW reward scales linearly as a function of how many PoS votes are included. Each block has up to 5 PoS votes in it, so for every vote that is missing, the PoW miner loses 20% of their reward. In most circumstances, this means that the only reason for not including all 5 PoS votes is that some of them have not been cast by the PoS miners.

There are further details of this hybridized PoW/PoS system that will be published in a more technical document, but these points suffice to describe the core functionality of the system.

Stratified consensus

The concept of hybridizing PoW and PoS consensus mechanisms creates a stratification of consensus between PoW miners and PoS miners. PoW miners are needed to generate the blocks that build the blockchain and PoS miners are needed to ensure that PoW miners create blocks that are consistent with the desires of the users of the currency. A very rough analogy here would be that PoW is to PoS as banks are to their depositors, so what this hybridization of PoW and PoS has created is analogous to a bank that actually acts according to the will of its depositors. In my opinion, this substantially improves on the system we currently have in Bitcoin, where holders of bitcoin have no say in the consensus process.

Despite PoW/PoS being an improvement over pure PoW or pure PoS, there are important scenarios that are difficult to handle with only 2 levels of stratification, e.g. a maximum block size increase. A quick characterization of the stratification within Bitcoin is that there are only 2 layers, PoW and Proof-of-Developers (PoD), where PoD is taken to mean consensus among the various Bitcoin full-node developers. Since Bitcoin Core is by far the most widely used full-node and is the de facto standard, the BC developers effectively override everyone else in the PoD pool. The current notion of consensus amongst the BC developers is “unanimous” consent and they vote as a block, making the overall notion of PoD consensus very brittle as it is subject to several vetos within the BC developer group. Even in the event of what amounts to PoD consensus on software changes, PoW miners are by no means required to implement those changes and can simply block the software upgrade. Even if PoD consensus is to change the maximum block size, there is no guarantee PoW miners will agree to the changes.

If the maximum block size issue were raised in the context of a hybridized PoW/PoS system, PoS voters can force PoW miners to support whatever changes were agreed on. In the context of contentious issues like maximum block size changes, this gives a clear resolution to the dispute via the PoS voters. The PoS miners can force consensus changes by invalidating PoW blocks that go against the new consensus rules, removing the incentive for PoW miners to behave without regard for PoS miners. Even though the dispute is resolved, it does beg the question of whether or not those changes were actually a good idea. After launch, we will work with the community to create additional layers of stratification that give representation to contributors to the ecosystem and the developers.

Project Constitution

It is natural to consider creation of a Constitution or similar for the project when one of its main aims is sound governance. Initially, we had a lot of disagreements internally about whether to have a very brief mission statement, similar to the Federal Reserve Bank, or to have a longer more detailed document, similar to the US Constitution. Ultimately, we decided that a Constitution document was more appropriate since such a document more clearly manages the expectations of the participants. As an open source project, a more detailed document fits well with the notion of transparency, which is often sorely lacking in organizations with a less verbose mission statement.

The Constitution contains a description of consensus rules, how disputes are resolved, the overall structure of the governance model, and what users of the currency can expect from the project. I have already summarized the first 3 parts of the content of the Constitution in earlier sections of this article. What users can expect from the project will be encoded as Amendments and they will provide straightforward rules that the project will abide by. Similar to Bitcoin, the concept of a fixed maximum number of coins is considered fundamental to the system. There will be several additional Amendments included beyond this finiteness of supply constraint. By making the principles under which the project operates clear, users have a much better idea of what they are signing up for when they obtain coins.

Funding development

As we have seen with Bitcoin and pretty much every other open source software project to date, it is difficult to build software of substance when unfunded or funded by donations. There are, of course, notable counterexamples that have managed to deliver impressive software despite being underfunded. However, as a project that aims to create a more sound notion of money, it would make sense for such a project to fund itself instead of being beholden to external sources of funding. Per my previous blog entry, the question of “where does the money come from?” whether it is me, Blockstream or MIT Media Lab does matter and it creates both real and perceived conflicts of interest with developers and the projects they work on.

Instead of expecting benevolent donors to appear and fund this project, we will be adding a consensus rule that sends 10% of each block subsidy to a development organization (dev org) that is responsible for funding and overseeing development and related work. The dev org will be responsible for contracting with developers and other groups to perform work on software related to the project. Initially, Company 0 has performed much of this work in private and will continue to maintain and extend the software, but we are keen to include and pay other developers and organizations for this work. The dev org will have open financials, published biannually, and maintain a list of requests for proposal (RFPs) that interested parties can submit proposals for. Individuals or organizations that are interested in submitting proposals are encouraged to perform some smaller development tasks before submitting proposals, e.g. fixes for issues listed on GitHub, so they can get familiar with what we consider proper development practices. In some cases, the RFP will include a non-software deliverable, and in those cases, the requirements for the deliverable will be included in the RFP. If multiple proposals are submitted for a given RFP, one proposal will be selected. The selection criteria will depend on a number of factors, one of which is estimated cost, and having a proposal accepted does not mean it is the lowest bidder. The hope with such a system is that it allows multiple parties to cooperate in the development process and be paid for their work.

Conclusions

I have outlined a broad set of changes that I and my developers believe will substantially improve upon Bitcoin by providing infrastructure to handle its biggest weaknesses. Since this list of changes is both substantial and affects consensus, it is very likely that most of these changes will never make it into Bitcoin. The changes we have implemented are made with the goal of making project-level consensus and development sustainable and efficient.

This new project will be publicly announced in 1 week’s time on Monday, December 14th, 2015. Additionally, we will be conducting an “airdrop” of 4% of all coins as part of a small premine to spread the network effect as far and wide as possible. Airdrop participation will be merit-based and open to anyone interested in joining the project and its community. More information about the airdrop will be released on December 14th.

Thanks for reading!