Lots of outlets have covered the recent controversy over bitcoin block size, but none of them have really given me much detail on it. So here's my attempt to make sense of it. My single biggest source generally is the bitcoin wiki, and based on my remaining open tabs more specific sources are here, here, here, here, here, here, and here. Also, just for fun, you can monitor new bitcoin transactions in real time here.

I've discussed before how the bitcoin protocol works, but in that discussion I focused on how bitcoin uses cryptography to validate individual transactions. The current debate is about something related but slightly different: how those individually validated transactions propagate into the public ledger when there is no central command to secure that ledger.

When you purchase something with bitcoin, your bitcoin wallet creates a record of that transaction, consisting of to and from addresses along with cryptographic signatures. You upload this record to a payment processor, who is really just some random guy with a computer that is hosting a bitcoin node using the open-source bitcoin software.

Anyone can host a node, provided they have adequate hardware (just an ordinary computer with at least 50GB of hard drive space) and internet connection (ordinary, cable internet service will work). A node consists mostly of a copy of the complete bitcoin block chain, which is the public ledger containing a record of every single bitcoin transaction that has ever happened, which currently is about 40GB worth of data. It's called a block chain because the ledger's contents are broken up into a sequential chain of blocks, where each block contains a hash of the previous block along with records of some transactions. A hash is just a number produced by applying a hash function to some text, where two identical texts always produce the same hash number, and two identical hash numbers had to have been produced by identical text. This allows validation of the block chain: for each block you just apply the hash function to the previous block and compare the result to the hash contained in the current block; if they match, you do the same for the previous block, and so one all the way down the chain until you arrive at the original, first-ever bitcoin block.

So when you send your transaction file to be verified, the node host (ie, a miner) will add it to a block it is currently building. When the node is finished building that block, it pushes it to the bitcoin network, where others also validate it's contents and add it to their block chains. Others can validate the block's place in the block chain by following the chain of hashes described in the paragraph above. If the block's contents are validated (see previous), and the chain of hashes is valid, you are half way to completing the transaction.

There is no minimum number of transactions that the miner can include in the block--the block can be considered complete once the miner has solved a time-consuming proof of work algorithm, which basically prevents spam from being entered into the block chain. That said, there's an incentive to include as many transactions in a block as possible, since you get fees on each transaction, but only solve the difficult problem once. But there's a limit: blocks are limited to at most 1MB, or roughly 2,400 transactions.

So once this is pushed to the network, other nodes all check to see that it is valid by checking that the solution to the proof of work is correct, checking that the hash chain goes all the way back to the original block, and finally checking that that hash chain is the longest of all possible hash chains (by convention, they all agree to honor only transactions along the longest chain--this prevents double-spending). But an issue can arise here. If two miners are building blocks at the same time, and try to push them to the network, chances are that they'll both contain a hashed reference to the same parent block since the other has not yet been published--the block chain is forked. So at most one of these can become part of the longest chain, and the other is invalidated--all of the transactions that the other one contained must be added to another block and the whole process must be tried again, until those transactions become part of the longest chain. Only after enough nodes have recognized that a transaction is part of the longest chain does it finally become valid.

Note that we have two constraints: first, the network limits how fast blocks can be added both by rejecting simultaneous additions and by adjusting the difficulty of the proof of work algorithm so that a block can be added only about once every 10 minutes. Meanwhile, each block can contain only about 2,400 transactions because of the 1MB limit. Thus there exists an effective upper bound on how fast transactions can be added to the block chain at about 4 transactions per second, perhaps considerably less when other factors are considered. And that's where the block size debate comes into play. According to this guy's calculations, we'll probably reach that upper bound in 2016 or 2017, probably causing transaction fees to spike as the market rations bitcoin transactions. One way to increase the capacity of the network is simply to increase block size and with it, the number of transactions that can be added per block. This would mean that the block chain file would grow more quickly, perhaps increasing hardware and network requirements for hosting a full node. On the other hand, it would also mean more revenue from mining, without necessarily increasing transaction fees.

But that is not the only way the network can expand capacity. In my view, the likely outcome of failing to increase block size is increased centralization and the emergence of Bitcoin Banking. In fact, you don't need a formal transaction entered on the block chain for control of a bitcoin to change hands. The way a Bitcoin Bank would work is this: you have bitcoins and deposit them at a bank (or, more cheaply, you buy bitcoins through the bank). Then the bank would maintain an off-network block chain as you spend those bitcoins, and at the end of each day would merge it's off-network chain with the official block chain. But if it is sufficiently large, it can consolidate considerably. For example, instead of a separate transaction every time one of the bank's customers spend coin at Kroger, it could simply have one transaction for the full amount all its customers spent at Kroger. This would represent a massive consolidation in the number of transactions, number of blocks required, and therefore the amount in transaction fees. In a world where transaction fees are high (and most bitcoin transactions are legal/legitimate), I think this kind of centralization is inevitable.

But then, centralization might be inevitable anyway. A centralized off-network block chain administered by a trustworthy bank doesn't require all of the resource-consuming proof-of-work and decentralized network verification, and thus is inherently lower cost regardless of the maximum block size of the main bitcoin block chain. To the extent that people want to use bitcoin at all, there is an arbitrage opportunity for any trust worthy institution to centralize it. Economics tells me that arbitrage moves markets.