Bitcoin’s blockchain has a hard-coded limit of 1 MB per block. Satoshi instituted the limit to keep chain size manageable during the early days of Bitcoin, when every user was required to download the whole chain. According to developer Mike Hearn, Satoshi correctly anticipated that eventually lightweight “SPV” wallets would exist, and he assumed that then the block size limit would be raised.

Some Bitcoin developers believe the time has now come to do that. Bitcoin’s average block size is now in the 400 KB range, which means that individual blocks may run up against the 1 MB limit. When a block gets full, some transactions will not be processed. In theory, users bid for inclusion in the block with transaction fees, but existing clients aren’t made for such bidding wars. This is uncharted territory. If the result were that users had to wait several blocks to get their transactions accepted, it could harm the network.

There are several arguments against raising the block limit. It would require a hard fork of the Bitcoin network. Also at issue is the nature of Bitcoin itself — should it be a transaction ledger capable of directly competing with Visa, or should it be a settlement mechanism between various off-chain systems for processing payments? Gavin Andresen, a proponent of the change, has curated a list of objections at his blog, and is responding to each.

Importantly, Bitcoin’s block size can also affect the security of the network. Miners do not calculate cryptographic hashes for fun but for profit. They earn a block reward plus transaction fees for discovering a block. As the block reward decreases over the next several decades, transaction fees will become a more important source of miner revenue. Increasing the block size will enable more transactions to be included per block, but it will also reduce the fee necessary for a transaction to be included. The direction of the net effect of block size on total transaction fees is ambiguous, depending on the elasticity of demand for transactions. If total fees go down, other things equal, so will the hash rate of the network.

As Gavin notes in another post, the amount that miners will invest in hashing also depends on the value of Bitcoin. Miners will unambiguously spend more on mining when bitcoins are worth more. He suggests we focus on adopting those changes that maximize the value of Bitcoin.

I agree. But how do we know what changes will maximize the value of Bitcoin? We can do all the simulations we want of the effect of block size on network functionality, but as the security and ultimately the utility of the network depend on economic variables, the accuracy of those simulations will be highly sensitive to the parameters we choose to represent the underlying economics.

One way to resolve uncertainty around complex phenomena is to boil them down to a single metric and let markets sort them out. We have a metric that we can probably all agree is at least somewhat useful: the price of Bitcoin. What we need are futures markets that can help us to determine the expected price of Bitcoin under various scenarios.

A futures market can forecast the price of Bitcoin at some future date. A cleverly-designed futures market can forecast the price of Bitcoin conditional on some event. For example, it would be possible to forecast the price of Bitcoin in the event that the maximum block size is increased and in the event that the maximum block size is not increased.

If the Bitcoin community wanted to know whether increasing or not increasing the maximum block size was more likely to increase the price of Bitcoin, it could look at the prices in these two conditional futures markets. If increasing the maximum block size yielded a higher expected price of Bitcoin, then that would be evidence in favor of increasing the size. If not increasing it yielded a higher expected price, then that would be evidence in favor of the status quo.

More generally, the Bitcoin community could use these markets to resolve difficult issues around core development. For example, Peter Todd has proposed modifying the reference client so that it rejects the lowest-fee of two incompatible transactions rather than the one that simply occurs second. This replace by fee (RBF) system might help alleviate block congestion, but is opposed by a number of other core developers. A conditional futures market would help to inform the debate.

I am not advocating full Futarchy. There may be reasons to make decisions that do not lead to the maximization of the value of Bitcoin. Bitcoin’s core developers have been excellent stewards of the project, and I continue to favor giving them discretion. But ultimately, decisions about core development will be made by users adopting or not adopting various changes to the protocol. These users should have the best information available to them as they decide what core development decisions to ratify through their adoption.

To that end, as a first step, my colleague Andrea Castillo and I are setting up some crowdsourced forecasting questions about Bitcoin core development on the SciCast platform. These will allow us to infer how various proposed changes to the Bitcoin protocol or reference client will affect the price of Bitcoin. SciCast is not a real-money prediction market, but it is a useful platform to which we already have access.

The community should explore additional ways to develop decentralized and unbiased forecasts to aid core development decisions. A real-money combinatorial prediction market might be best. A relatively simple conditional futures market might be easiest. Ideally, the market would be highly liquid, which would probably require compliance with the Commodity Exchange Act and CFTC regulations. I hope everyone will join me in mulling this over further.