Resistance to unpopular changes to the protocol
Bitcoin is the first mainstream open source digital currency.
By having publicly verifiable source code and a decentralized protocol by design, it also offers some resistance to regulatory pressure. For example, if, in country C, a court of law forces Bitcoin core developers living in C to change the rules of the protocol and incorporate them in the next official release, it is likely that the worldwide community will fork the project and reject the tampered version. The same will probably happen if core developers willingly include a rogue change in the protocol, acting as a de facto governance body for the Bitcoin economy.
Then it will be a matter of adoption: will most of the people blindly update the official software or protest against the change and choose to switch? At the very least, Bitcoin gives users choice to carry on under their ruleset of choice.
Resistance to unpopular changes also applies to developers and package maintainers going or being crazy. The most recent sneaky change to Bitcoin happened in Gentoo Linux. Bitcoin Core contributor Luke-Jr decided to silently add hardcoded address blacklists of gambling sites in the default USE flags of bitcoind and bitcoinqt in the popular Linux distribution, on questionable and definitely subjective moral grounds. This risked undermining Bitcoin’s fungibility and Gentoo’s reputation. Finally, Luke-Jr publicly apologized and rolled back the change.
It is interesting to note that everything said above applies only if the general public perceives a change to be malicious and to be boycotted. This means Bitcoin is almost democratic, but the pool of voters is restricted to people operating Bitcoin nodes. There is an evident selection bias by limiting voting rights to people able and/or with enough incentive to run a full Bitcoin node. If and when countries will run their nodes, it is likely that they will employ restrictions similar to the one Luke-Jr tried to push, by for instance blacklisting addresses associated with porn, political activists, dangerous journalists, terrorist groups and so on, to prevent them from receiving economic support. After all, the issue is the same we are facing every day in Internet censorship carried out by governments or by private organizations at the behest of government or regulators. Governments are historically sensitive about money, and will do anything they can to forbid activities that take away power from the State. The difference is that with Bitcoin it is more difficult to enforce such control, even on a local scale, because of the decentralization.
In my opinion, it is not so hard to imagine a future in which countries will fork Bitcoin, rewrite it and try to regulate their newly minted national cryptocurrencies, together with traditional fiat currency. This is perfectly fine: ChinaCoin and USCoin will share the blockchain up to the block in which the fork occurs, and if there will be enough adoption, the fork will survive. Changing the rules means forking Bitcoin, and forking Bitcoin means creating a new currency.
A more realistic alternative for such a scenario would be start a brand new chain, maybe centralized.
A novel aspect of this scenario is that rules will be built in the currency itself, but to actually strictly enforce limitations major changes to Bitcoin will have to be done, such as severely limiting peer-to-peer payments and forcing users, linked with their government-issued digital identity, to spend money through hubs, basically recreating a digital version of the current banking system but keeping the useful aspects of cryptocurrencies.
Will people resist the siren song of a government-backed cryptocurrency or will they trade part of their freedom to be patriotic?
Miners on strike: establishing a cartel to raise transaction fees
Right now, combining the hashing power of the top three mining pools gives us about 60% of the total Bitcoin hashrate.
If one day the owners of those pools and the majority of the miners using them decide that operating costs are too high, electricity is too expensive for the current block reward and transaction fees collected when a block is mined, they might collude and set up the first miners’ strike.
How could such a strike be carried on?
A fun way would be to refuse to include any transaction at all for a short period of time, mining zero-transaction blocks such as block 289791, forfeiting their fees, to disrupt the network and greatly slow down Bitcoin transactions.
After a day, they announce that from that time on they will only accept transactions with transaction fees > F BTC.
Will this work? I don’t think so.
This kind of scenario is well known in game theory. In general, cartels are unstable due to rational members defecting for the economic benefit that comes from doing so. In this case, collecting transaction fees by including them in their blocks vs nothing hoping for a future benefit. This happens in particular if members are anonymous and can’t be personally blamed or punished for defection. Yes, it is a prisoner’s dilemma in which the reward of defection strictly dominates mutual cooperation.
Freeze! The Bitcoin Freeze on Transaction Attack (FRONT)
Sergio Lerner published last month an hypothetical attack to the Bitcoin protocol called FRONT which I find very interesting from a game theory point of view.
In Sergio’s words, the freeze problem occurs if someone publishes a transaction with fees much higher than the block subsidy.
Think of a transaction T that includes a 100 BTC fee for miners. The transaction is included in the block chain in a block at height n by a lucky miner. If the other top miners act rationally, have enough hashing power, are greedy and prepared, the best choice for them is to try to mine a competing block at the same height n including the high-fee transaction, to collect the fee for themselves. Other rational smaller miners will actually have an incentive to just follow the longest chain, since the chance of successfully orphaning an already mined block is very slim for them. When top miners eventually solve their own block at height n, they will ignore other branches and try to extend their own as long as possible. They won’t choose each other’s branches until one branch is sufficiently longer so that it is more convenient to switch to it and abandon their own branch rather than try to keep the block with the high fee. The incentive to switch grows exponentially with the branch length difference.
Sergio has run a simulation for this scenario and has come to the conclusion that this can freeze the Bitcoin network for several hours.
A proposed mitigation to this attack requires Bitcoin users to use nLocktime on transactions spiecifying a block height, say, of 10 blocks forward. This means that transactions, together with their increasing cumulative fees, will not be included in blocks unless we reach that height, creating an incentive to move forward.
Miners will change when they will live out of fees
The day in the future when the block reward will be negligible or none, the only incentive for miners to work will be collecting transaction fees.
I predict this will greatly change their behavior when selecting which transactions to include in the block, since including the right transactions will be critical to their survival.
Currently, the block reward that comes with just generating a block is much higher than the fees that miners collect. For this reason, transactions to be included in a block are simply taken from the memory pool, sorted using a heuristic priority formula and then highest-priority-first added to the 50,000 bytes in the block which are set aside for the highest-priority transactions, regardless of transaction fee. Then transactions that pay a fee of at least 0.00001 BTC/KB are added to the block, highest-fee-per-kilobyte transactions first, until the block is not more than 750,000 bytes big. The remaining transactions remain in the miner's memory pool, and may be included in later blocks if their priority or fee is large enough.
I think in the future this will change. The problem of carefully selecting from the set of outstanding transactions which have been relayed to the Bitcoin network but not yet included in any block, and doing this fast and accurately will be treated as an optimization problem.
Since transactions have different sizes and offer different transaction fees, miners need to solve the problem of selecting the set of transactions with the highest total transaction fee but still below the block size limit. This is equivalent to the classic 0-1 knapsack problem in which you want to fill a knapsack having limited weight capacity with the most valuable subset of items with varying weight and value. Choosing which transactions to include in a Bitcoin block is just a knapsack problem with weight being the size of each transaction, value being the transaction fee, and the total capacity as the 1 MB block size limit.
The solution will likely take inspiration from that well known algorithm, but it will have to take into account also dependencies between transactions, queueing theory, and other miners competing in real time. Being scooped by a competing miner just before coming up with a valid block will be disastrous: with no block reward, we live out of fees only, and there will be none left in the memory pool!
The algorithm should be fast enough to avoid this.
Furthermore, some transactions depend on others, and the algorithm has to decide each time whether it’s worth including small dependency chains or not. This will require significant optimizations to come up with a good solution reasonably fast.
Fascinating times ahead!