Forking Bitcoin, the first existential milestone
The news recently is all abuzz about the Gavin Andresen and Mike Hearn’s fork of Bitcoin called Bitcoin XT. For the first time in the history of Bitcoin, its very existence has been put into peril by way of what is termed a ‘Hard Fork’ of the protocol. I have watched the situation develop, and I feel that I must comment on this topic as the amount of FUD coming from both sides of the camps is reaching alarming levels, and frankly I think this is hurting Bitcoin. (the price as well as the community). This is a long post, apologies. Normally I would have split it out into several, but I wanted the message to be complete, and atomic. If you want the executive brief, jump to the summary at the end. Go on, I won’t mind. (but don’t come back to me with questions later!)
Priorities of Bitcoin
Bitcoin, as a vision conceived by Satoshi Nakamoto is a decentralized cash payment system. For such a system to work, you need a decentralized solution to the Byzantine General’s problem, which is something that I have detailed in the past and is succinctly defined here. The reason Bitcoin is such a brilliant invention, was that it solved the consensus problem in a decentralized way. The solution isn’t a perfect one, in fact, it cannot be formally shown to hold in all cases, (which is a source of consternation for many folks like Vitalik Buterin and likely drove him to develop Ethereum in response to the desire to have a formally provably secure solution), but it is shown in practice to work, in most real world situations so far. For this solution to work, Bitcoin holds the following priorities in descending order of importance: Consensus, decentralization, store of value, and payment system. It would seem that the goals of the Bitcoin project have since diverged, under the leadership of Gavin, to focus more on the payment system use case for Bitcoin, at the expense of consensus and decentralization. I would argue that sacrificing consensus, threatens all the other aspects of Bitcoin, not the least of which is its use as a stable store of value. In fact, I believe such a consensus breach is an existential risk to Bitcoin itself.
Compounding the problem, is that the XT camp (and to a lesser extent the Core camp) is increasingly using populist and alarmist strategies to scare the public onto their side, betting on ( and rightly so ) that most people do not know enough about the inner workings of Bitcoin and thus will be drawn to believe what they say based on their reputation alone. From the perspective of an interested 3rd party, I can no longer watch the partisan media campaign war that is taking place, using carefully misleading language and omitting of facts to steer public to their causes. I could cite actual examples of such disingenuous wording and statements, but I will chose to leave it up to the reader with a critical mind to identify such examples on their own. (See appendix) Morally, I refuse to join the ad hominem smearing, and instead choose to focus on discussing the pros and cons of the debate from a purely scientific standpoint ( in hopefully, language that will make sense to the non-technical )
The block limit debate in a Nutshell
So what is the big debate about anyway? Block limit. I won’t go into the nitty gritty details of how the blockchain is put together, but suffice it to say that the current limit of the size of each block on the blockchain is 1mb. (1000000 bytes actually, but who is counting?) And one block is mined about every 10min on average. That works out to be a theoretical limit of a paltry 7 txn/s (tps). Not stellar, as payment systems go. That is precisely why Gavin and Mike Hearn have been pushing for increased block sizes, in principle. For comparison, VISA can supports on average about 2000 tps, PayPal about 115 tps. VISA’s theoretical limit is an astonishing 50k tps. So why is Bitcoin artificially limiting itself to something so low? Because Bitcoin being a decentralized system with no one central point of processing, it is susceptible to denial of serivice (DoS) attacks. What that means is that bad actors on the network can collude to attack the network stability itself, if it becomes profitable for them to do so. Making it unprofitable for them to do so is the key innovation of the Nakamoto consensus solution. Satoshi put in the 1mb limit himself, in anticipation of having some limiter to the size which would prevent bad actors from breaking the system before it was widely adopted enough to be resilient. He did himself foresee a time when the limit could be relaxed, but wasn’t sure at what point that may be, due to the fact it depends on a lot of variables. We still don’t know what the limit should be, but the general consensus is that 2mb is okay, 8mb unknown, 20mb definitely risky. Why? Read on.
Mine mine all mine!
Selfish miners
Selfish mining, is one such attack which was clearly explained in Satoshi’s paper as a possible weakness of Bitcoin. This entails a miner, who has a significant amount of hashing power, mining blocks but not publishing them, thereby creating a secret longer chain that the rest of the network does not know about, with the intent of broadcasting it later, and in doing so will reverse some transactions that may have already been confirmed on the public (but shorter) chain. This is the infamous double spend attack. Normally this can only be accomplished reliably when one possesses over 51% of the hashing power of the network. What most people don’t know is that network propagation is also a factor here. Satoshi admitted that his calculations on the percentage of hashing power in order to be able to pull off a 51% attack reliably assumes no significant network propagation delays. Indeed the danger of allowing block size to increase to the point where the expected delays in block propagation through the network has been discussed ad infinitum in the past, and the reason why the block debate has been ongoing since at least 2011.
In this regard, I can understand why Gavin feels that he must do something drastic to force the issue. The attack goes as follows: If blocks were allowed to be ‘too big’ (big enough to add plausible delays to propagate to all nodes) then a miner would be incentivized to stuff the block they are mining full of txns that pay himself (or a cohort), up to the allowable block limit. They do not broadcast these transactions to the network unless they solve the block themselves, removing the possibility of paying miner fees to some other miner. If they manage to solve the block, they immediately broadcast all their spam txns and block solution. The other miners would have to drop what they are mining, and start downloading the new (very large) block (which may take some time) and verify it, which involves checking the validity of all contained transactions (which will take some more time). All this results in a appreciable head start that the attacking miner can enjoy in mining the next block. So what he has successfully done is increased his ‘effective’ hashing power giving him a slight edge over his competitors. Of course this is a game-theoretic problem, so we can assume that once one miner starts doing this, then either all miners will start doing this, as well (and make orphan blocks and double spends a lot more common) or band together to share high bandwidth connections/nodes (and push the system more towards a centralized one) both situations are bad for Bitcoin. So everyone can agree that too big of a block size would open up bitcoin to a certain type of fragility that has up until now, not been a problem.
So how big is too big?
So unlimited block limit is clearly bad, and 20Mb is generally agreed upon as pretty risky (up to 8sec propagation delays). What’s wrong with just 8Mb? Frankly, it’s probably ok. Probably. The problem is that nobody knows. Because nobody has finished researching the issue to a satisfactory level yet. This is why some core developers are calling for more time to analyze what the ‘safe’ limit would be given the current bandwidth limitations of the present internet. Others have proposed counter solutions to increase block limits that take a much more conservative approach. XT proposes to start with 8Mb limit and scale up automatically 2x every 2 years until it reaches 8Gb. Gigabytes. That will certainly make bitcoin able to compete with VISA. But, can we be certain that network bandwidth growth will continue trending up monotonically without fail? What happens if a global downturn occurs and we see a slowdown in technology development? What happens to the people who bought Bitcoin as a hedge against a fiat money collapse? But for me the scariest part is that once XT block limit increase schedule is triggered, there is no turning back! (see Appendix)
What we are really arguing about here
That brings me to the crux of matter. What we have here is an ideological schism in Bitcoin. Most people fail to realize that this is what the block debate is really about. On one hand you have folks who believe Bitcoin should be the new VISA system. They believe that Bitcoin should be able to handle all the transactions on planet earth, from everyone’s daily coffee purchase, to everyone’s house purchase, to how Google cars should be paid for their services. On the other hand, you have those who believe Bitcoin’s core value is the fact that it is a hedge against fiat currencies, and by extension, governments (in the case they decide to infringe upon your liberties). Bitcoin CANNOT be both. It’s just not possible. For a system to be able to support the proposed 53k tps it will need to be massively centralized (like VISA). If such a system existed (like VISA), it would no longer be immune to government coercion or control. The opponents of XT will argue that it is inevitable, and nay, necessary that sub-domains riding on top of the Bitcoin network be setup to handle local payments between local parties, thus keeping the required number of txns on the main net of Bitcoin manageable. A current project under development, Lightning Network, is exactly one such solution.
Risks of not raising the Limit
The biggest argument against doing nothing (or doing nothing urgently — because I believe mostly all the devs agree the limit should be raised eventually) is that if the limit is hit due to real transactions in the network, then confirmation times will be variable, and delayed. This is a valid point. What will happen is that due to transactions piling up, people will no longer be able to reliably assume that they will get a confirmation in around 10min. The simple rebuttal to this is that for customers of payment processors like Coinbase and BitPay, it doesn’t matter, as they will give you a confirmation without waiting for a block anyway. What it does mean is that there is a chance that your txn could be double spent (and the payment processor would have to cover it). I personally don’t consider this a major concern to current users. Most people who don’t use a payment processor aren’t really that sensitive to confirmation times. If you were sensitive to confirmation times then you are likely already happy waiting an hour to confirm anyway. Another valid concern is that txns piling up unprocessed will put memory pressure on nodes running on small memory capacity hardware. But the biggest rebuttal to this is that transaction traffic (natural traffic, not a contrived ‘stress test’) will not happen suddenly. If it seems like the limit is getting hit persistently, and confirmation times are becoming a problem, an emergency limit increase is something that the core devs can patch very simply and quickly. They can execute such an emergency block size “QE” if you will, at a moments notice. They have demonstratively done this kind of deployment before, during the one previous hard fork, and with the F2Pool bug. So what is the rush?
Fee (free) markets
On the other side of the fence core devs want to let the limit be reached, in order to force wallet apps to implement the necessary protocols/interfaces for developing a fee market. What this means is that they see that Bitcoin can never be ‘free for everyone’, if it were, it would have to be centralized (see above). So although I believe everyone wants Bitcoin to be cheap enough (cheaper than any present centralized alternative), the core folks want to encourage a free market mechanism where if the network transaction load is high, you will need to pay more fees to get your txn processed on time. Currently that is technically possible, but due to most wallet software’s inability to estimate the likely charge that is required, or lacking the ability to pay more to raise the priority of your txn that is already broadcast, it is not implemented in practice. Part of the reason they want the block limit to be hit (gently) is so wallets are forced to upgrade to be able to make this experience better for their users, and thus be ready when the real limit (the unknown one where bandwidth creates the significant DoS attack concern) is hit, because core will not be able to raise it any further beyond that without compromising the integrity of the network.
What is a Hard Fork, and why is it dangerous?
Okay, thank you for bearing with me. If you soaked in all the above you have a pretty good grounding on what the debate is about. Now onto the process by which XT is going about the fork, and why it is irresponsible. A hard fork means that the blockchain will split, with each side having a common ancestry, but be irrevocably non-reconcilable with each other.
I will spare you most of the details of the XT forking rules as I am sure you can find info elsewhere (see the Appendix below for link to Gavin’s BIP 101), but generally after Jan 2016, if 75% of the last (consecutive) 1000 blocks are mined by XT miners, then XT miners will be able to accept up to an 8mb block as valid. Sometime after that, once this first big block is mined, –let’s call this the “Judas” block (see diagram), then it will be rejected by the remaining 25% of the network. They will drop it and continue mining the block on top of block “Jesus”, and when mined let’s call it “John”.
Bitcoin XT hard fork worst case scenario
The XT miners cannot accept “John” as it builds on top of an invalid parent block (they need it built on top of “Judas”) and so goes on to mine “Pontius”, meanwhile, the core loyalists will mine “Paul” block which builds on top of “John”. Any subsequent block mined by either side will be dropped as invalid by the other. Effectively we now have 2 Bitcoin networks, with respectively 25% and 75% of the pre-hashing power before the Judas block. It is untrue that the 25% will be compelled to join the majority. They may go on happily mining on the John chain in perpetuity. Their block rewards (mining income) will not be diminished (in fact, they will make MORE mining rewards, due to a smaller mining pool). What will end up happening is that the hash power distribution will have changed. The previous owner of 10% hash power pre-Judas block now will find themselves with ~45% of the hash power of the new John chain, and similarly miners on the Judas chain will have increased effective (relative) hashing power. In truth, both chains are now less secure than the combined chain, pre-Judas. Most importantly fungibility of bitcoins are now broken.
Both chains will still get transactions from the whole network. Indeed txns of coins that were mined before the Judas block are valid on both chains and thus will be attempted to be mined on both, than is, unless the txn include any coins minted from a block after Jesus (in either fork), in which case it cannot be spent on the opposing chain from whence it came.
So what?
Why is this situation really bad? Because of the exact reason why Hard Forks are dangerous. If they have a consensus, they are resolved quite quickly with one fork winning over the other. (and it doesn’t matter which is longer!) That’s how it was resolved in the past, by unanimous endorsement by core to choose one over the other (and upgrade or downgrade accordingly). IF there is no clear winner, because each side wants to stick by their guns due to ideological reasons, then we have a problem. Why? Consider Alice, who uses wallet A, and Bob, who uses wallet software B. Wallets need to communicate with nodes to get their block confirmations. If wallet A is connected to a Bitcoin (John) chain node, and Bob’s wallet B is connected to a node running the XT (Judas) chain then they are no longer going to see the same block confirmations, and they won’t know about it! Alice will send bitcoins to Bob, she sees a confirm, but Bob will never see a confirm, if the coins are originally minted from a post-Judas block. If it is from Jesus block or less, then her transaction with Bob will work and be seen by both of them, BUT then Alice can re-spend those same coins with a counterparty on the John chain! (and this goes both ways). This breaks the fungibility of bitcoins, and will likely cause a massive loss of confidence of Bitcoin as payments will no longer be able to be reliably confirmed. Because both are operating on the same network (IP ports, QR codes, URI etc) there is no way to detect a-priory if your payment is being made to a receiver who can receive it, until after you try (or unless they are really tech savy and you both know which side of the fork you are on). This bad situation can happen as early as 100 blocks after Judas block. (about 16 hours). Much of the chatter in the social channels portraying the XT upgrade as perfectly safe seems to be deliberately ignoring this fact. And for understandable reasons. IF (and only IF) everyone does upgrade to XT, then we will have no problem. But if they don’t and it turns out to be a game of chicken, then we all will suffer.
Help me Satoshi Nakamoto, you’re our only hope!
Where is Satoshi?
So with all these scary uncertainties, you may ask why hasn’t Satoshi come out to speak on the behalf of one side or the other in order to settle the dispute? Indeed it would be akin to him coming out to act as a 3rd party mediator, such as when a parent comes in to break up a fight among siblings. There has in fact been a post by someone claiming to be Satoshi, from a valid known Satoshi email address, claiming pretty much that the XT fork is unnecessarily dangerous, see here: Satoshi? Despite the many allegations that if this was really Satoshi, he would have signed his message with a known PGP key or perhaps moved some of his coins to prove that it was him, he has not done so. I for one do not believe that he would. If you read the message, (ignoring for a second who it is from) he is saying that Bitcoin’s vision is not one where it is subject to the egos of charismatic leaders, including Satoshi Nakamoto. People who harp on the fact that Satoshi has not made a provably authenticated statement is clearly missing the whole point of this message. If he were to do so, rest assured the whole of the community will rally with him, but that is exactly what he doesn’t want to happen, a whole community blindly following authority! Consistently so, the author points out that if it takes a benevolent dictator to pull us out of this mess “deux ex machina” then Bitcoin, as a project in decentralized money resistant to authority, has failed. That tautological statement, is provably true if you can wrap your head around it. Therefore, if Satoshi wants it to succeed, he won’t use his ‘God card’ and settle disputes. If Bitcoin continually needs Satoshi to keep us from going astray, then Bitcoin isn’t worth saving. Considering that Satoshi has likely the most coins at risk than anyone else, and him coming forward to break the impasse would likely save us (and the value of his own coins) it is truly commendable that he has not done so. The fact that he hasn’t tells me that he (where ever he or she is) is truly acting in an altruistic manner. He is more willing to let Bitcoin die, than to let it continue on as a system that does not value consensus as its first and foremost priority.
Summary
(yeah you can skip to this if the above is more than you can digest in one sitting)
There is no spoon [danger] in a Hard Fork, but only if we ALL *believe*
Gavin and Hearn are trying to force consensus in an “Inception” like manner, betting on the fact that if 75% agree with him (whether they are well informed actors or not) then the 25% remaining will be forced to fall in line otherwise risk breaking Bitcoin for everyone. Why are they doing this? One can only imagine they feel that Bitcoin needs to grow otherwise risk being overtaken by a competing cryptocurrency. Although current transaction volumes are not hitting the limit yet, they believe that adding capacity will stimulate growth. That sounds more like strategy that Ben Bernanke or Janet Yellen might believe. What they may end up doing is that they will cause the end of Bitcoin themselves if the 25% minority believe it is better to continue running a reduced (hash power) version of Bitcoin that values consensus, over one that is run by a charismatic leader who is willing to force changes onto the network, or split it off into separate sects if he doesn’t get his way. If we choose
that to be the overriding model of Bitcoin, then Bitcoin as Satoshi envisioned it, as far as an experiment in “collective consensus building money, free from authority”, has failed. So just ask yourself one question, given all the unknowns and potential existential risks to Bitcoin, — What is the rush? Why the urgency?
On the other hand, the appeal of XT’s ideology is that block limits (in fact the consensus rules themselves), shouldn’t be something that is left for us humans to decide. Once set, the code itself, in an Inception-like manner should be the only one that guides the future path of Bitcoin.
One thing is for sure, if we make it out of this without blowing ourselves up we will see a big jump in BTC price.
If you liked this post, please consider dropping me some satoshis
Tip me with ChangeTip!
Onward and forward!
Post Scriptum:
So you decide*, was Satoshi’s vision to have consensus rely on a group of humans who need to always maintain internal consensus before a change? Or was his vision to leave consensus of the protocol, even at this meta-level, mostly in the hands of the code itself, once triggered? That is the choice that we all need to make now. *And if you really want to throw your mind into a self-referential loop, consider if Satoshi himself, would have wanted the public to have to be making this choice?
Appendix: (for you geeks)
I) Misleading media coverage (one example)
Incorrect misinterpretation by media: Cryptocoinsnews.com
The blocksize increase activates, at fixed dates,
if a super-majority of 75% of miners have
opted for the new block size by indicating
their preference in their submitted blocks.
Without 75% miner consensus no block
size increase activates.
The misinterpretation is that once XT is activated, at times during the increase periods it can be stopped by another supermajority vote. That is, you get a chance to vote again every 2 years. That is incorrect, as the code specification clearly states (below link). Once started, we are on a linearly increasing block limit doubling schedule that cannot be stopped until 8Gb is reached. Furthermore, the increase is not a step function that occurs once every 2 years, the limit increases with each block linearly. (They each bump up 1/730 of a step)
II) Useful background references
BIP 102 The simplest solution – Jeff GarzikBIP 100 An increase schedule with voting – Jeff Garzik
Bitcoin XT BIP 101 specification – Gavin Andresen
Hard Forks vs Soft Forks and why Hard Forks are supposed to be Hard
III) Once XT is triggered there is no turning back! Why? Because forks are voted upon my miners choosing to run one version of bitcoin over the other. And while theoretically if we were all on XT and something like a global downturn did necessitate a pause or scale back on the continuously increasing block sizes (due to bandwidth tech not keeping up) we would be hard pressed to convince the miners to cap or scale back their big blocks as bigger blocks means more fees collected by mining and there would be economic incentives to favour them.
