Bitcoin XT vs Core, Blocksize limit, the schism that divides us all.

Forking Bitcoin, the first existential milestone

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!

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

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 us Satoshi Nakamoto, you're our only hope!

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.


(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!

Please donate!

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:

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.

76 thoughts on “Bitcoin XT vs Core, Blocksize limit, the schism that divides us all.

  1. Reblogged this on Lợi Béo and commented:
    I’ve lost so much of money because of this war. Anw, the main point is that the quoted article is worth reading if you have been following the Bitcoin mess recently.

  2. Impressive coverage of both the technical issues and the socio-political and ethical considerations. Written with balance and fairness, and humour, (“The Judas Block”, yes, inspired and meme worthy aphorism), but still not afraid to ‘call a spade a spade’ in the end. – well done

  3. > Their block rewards (mining income) will not be diminished (in fact, they will make MORE mining rewards, due to a smaller mining pool).

    Not *quite*. A miner’s revenue for a certain amount of hashing is determined by the current difficulty level. At the point of the hardfork, difficulty is identical on both sides of the fork. So the miner’s revenue will be the same mining either side … 25 coins per block, plus transaction fees. Now the difference will be the exchange rate. If bitcoins mined on the original chain sell at $100, for example, and coins mined on the XTCoin (big blocks / Bitcoin-XT chain) sell at $120, then the miner earns 20% more mining the XTCoin side. Though once difficulty adjusts things change and mining one side will be more profitable than mining the other.

    • Yes, I was speaking about after the difficulty adjusts in 2 weeks. Though, I left out the point that confirms would be 4x as slow on the original chain, and 1.33x slower on the XTchain. Though I suspect in this case core devs may just push an emergency difficulty change (setting the difficulty to be 1/4th what it was at Jesus block). In the interim though, I don’t see why the exchange rate would change in the manner that you outlined. As coins mined on either side are not fungible, it’s probably not going to result in the value of each sides coins being reflective of the relative market that they can reach. Given the lack of transparency in wallet apps in identifying which side of the chain your coin may have come from, the mass confusion that would cause would likely drive both sides prices to almost nothing. Without fungibility, (both) bitcoins, as a common medium of exchange, is worth almost nothing.

  4. Sometime need to have the balls to move forward. Nobody knows the future and predict everything. Problems can and will be fixed when arise. Who knew bitcoin could take off to this point when Satoshi first launched the software?

    • Well, I will give Gavin the credit for forcing the issue to the top priority, and really made everyone pay attention. I really wish now that we have largely the whole world involved, with everyone talking about the matter, that Gavin would just go back and rejoin the dialog with the rest of the core devs. Together they can work it out democratically amongst themselves which BIP they support, instead of resorting to a contentious hard fork where users decide (which makes it political, as users cannot be assumed to be perfectly informed actors). The power of the hard fork is in the threat of it. It’s like WMDs, they work as a deterrent. Nobody really wants mutually assured destruction. Adam Back tried to ask Gavin to return to the table in this post in June. It is worth the read for those interested. The core side have been pretty reasonable I believe.
      Adam Back asks Gavin, please come back and work together on this

  5. Your article says that people who think Bitcoin should be “hedge against fiat currencies, and by extension, governments” are opposed to Bitcoin XT, but I’ve seen people like Roger Ver & Erik Voorhees in favour of Bitcoin XT. Major companies such as Coinbase and BitPay are also supporting BIP 101.

    A competing chain using the same hashing algorithm with only 25% support is always at risk of double spending. I don’t think anyone would use that. It’s more likely that a few developers are going to other projects.

    “the general consensus is that 2mb is okay, 8mb unknown, 20mb definitely risky”

    Where did you get the information about the general consensus? I have not seen Intel or any respectable company or university doing research on Bitcoin block sizes / scaling so I’m curious.

    • That depends Highly on the hash rate distribution of the pools. It’s not clear cut because it’s not like the the 75/25 dividing line will fall on pool territorial borders. For instance one can expect MORE double spend attacks on the XT 75 chain if the present distribution of hash power was (pool hash powers adding to 100) 40/30/10/5/3/2/1/… Because at the judas block XT will have exactly 3 pools owning 50%, 37.5% and 12.5% (from their previous 40/30/10 splits. )

      My numbers were based on various BIPs and dev discussion boards. BIP 100 and 102 support an upping to 2, miners say 8 is probably okay for them (though how much miners test or know the network effects are unknown) and 20mb was Gavin’s original suggestion and was denounced to the point that even he recounted on it and settled on 8.

      • What I meant is that a hostile miner could switch to the 25% chain, double-spend and switch back, that doesn’t work the other way around, because the other chain is too weak.

        • Well, actually no, I just explained a situation where the XT chain will be weaker in terms of 51% attacks (and possible double spends) post Judas block. They (XT) have a miner which owns 50% of the power off the bat. The Core chain would end up with a hash power distribution of 25%/15%/10%/5%/5%/5%…

  6. One thing that I have yet to see anyone mention in this debacle is the likelihood that exchanges will choose one, regardless of the 75%/25% divide. Since exchanges and payment processors are the “tip of the spear” for adoption, I believe they will have a far large impact on breaking any impasse than will the contentious developers.

    I actually have a good deal of respect for Gavin, but I believe that doing this in the manner he did was, putting it nicely, premature at best. More like asinine, because I think it likely to fail and that makes him look like a fool. He’s not a fool, but it’s a hard label to lose once you’ve gained it.

    • Yeah he’s a smart guy and made huge contributions to the project in the past. I harbour hopes that after all the dust settles he and the rest of core can reconcile.
      Yes, if all miners pick one side then we have no problem. That’s what happens when a hard fork is not contentious (the one time it happened before in 2013(?) all miners unanimously downgraded to the version that core recommended to maintain consensus. The danger of this upcoming fork is that Gavin is lobbying miners to join his side and Core is doing the same, (as this time, it’s political/ideological) which is going to definitely result in some split. And also why you read so much mudslinging and heated debates going on.

  7. When you discuss the scenario that would occur post-fork, you fail to make clear that from then on the game is effectively over. The only reason for the original fork to continue would be to deliberately subvert the work of the (now) legitimate XT fork. They would now be a de facto bad actor, on a par with common dDos attackers. Bearing in mind that XT now possesses 3 times the power ( and will rise very quickly), not even an attempt to cheat by the core developers (as you stated, by lowering difficulty) would have any chance of succeeding. If the fork ever occurs, its too late for core.

    • I don’t think so, because even though they have 3 times the power (mining 3 times faster), mining a second block on top of judas block (regardless of size) will be dropped and ignored by the core chain and won’t affect its mining at all. Sure they may broadcast the “INV” interrupt and make core miners download the blockheader (of the next block after judas) but the core nodes won’t download the whole block because it’s previous block is invalid (judas) so it ignores and continues on their merry way. Remember that each block has a hash of its parent in the header. If the parent hash doesn’t match what you expect, you ignore it. Compare and contrast to a DoS attack in which you are forced to download the block because it is actually valid to you according to your consensus rules.

      XT will essentially be an altcoin running on the same port as bitcoind.

      • –“I don’t think so, because even though they have 3 times the power (mining 3 times faster)”
        This is incorrect. They have 3 times the _chance_ to get the hash. It will still take the same length of time. This is a very important distinction to make. Difficulty is based on the length of time it takes to work out the hash, not the number of miners doing it.

        –“XT will essentially be an altcoin running on the same port as bitcoind”
        This is also not the case. XT will have chieved the consensus target and will in fact be the de facto coin. Core will be the alt-coin at that point.

        • Effectively it is the same. You have three times the chance to find a solution. But even if you find one, we all ignore you. (But your friends will accept that solution) That is exactly the same as core having 1/3 the effective hashing power as before the fork because the current difficulty is set too high for us to find a block in 10min.

  8. What incentive would there be for Bitcoin core miners to continue mining on the smaller chain? I think we all believe that in the event of a Jan 2016 hard fork, short term the price of Bitcoin/XT will plunge. However, it’s even more likely that Bitcoin ‘small block’ coins will plunge even further. Without a mechanism to pay for the electricity costs, miners will be forced to turn off their miners, move to XT or operate at a loss.

    I have a hard time believing that miners, exchanges, merchants etc will decide to continue operating on the weaker chain – there’s not enough incentive for the risks involved.

    • Normally, if the fork is not contentious (for instance, like an obvious BUG on one side) the core devs collectively tell all the miners which fork branch to choose. So there is no incentive. BUT if the fork is contentious (as the fact that we are even discussing this now is proof of) then there may be some miners who don’t agree with the politics or the ideology of one fork vs the other. Right now, the choice seems to be XT (fast, progressive, a bit reckless) vs Core, (slow, conservative, quixotic). So its less of a clear choice, especially since core has split and there is no clear “use this version” directive. Miners are not necessarily that technical, so they normally trust the core dev they have interacted with and trust most. But as it has essentially become an election (with all the political messiness of humans along with it) it’s anyone’s guess now which the miners will support. Nakamoto consensus and proof of work no longer can save us, we have to save ourselves, as the system is now in an in-determinant state.

      From an economics stand point, smaller blocks would prima facie be preferred by miners. As once wallets allow for auto increasing of fees (up to a ceiling) that you are willing to pay for a txn to go through, more traffic means more fees collected for them. We have to eventually move to this model anyway, because we really can’t give infinite bandwidth, so some time in the future, we will need wallet software to be able to automatically handle the paying of the ‘right’ fee to get your txn processed within the time frame that you need. (we will have fee classes you can choose from: free/hours, economy/1h, normal/10min, priority/next block). Mycelium already has this implemented (kudos!)

      The issue with electricity isn’t really a concern. After 2 weeks the difficulty resets on both sides, and the hash target pressure is gone and both sides miners are mining at the ‘right’ rate again (XT is no longer mining blocks 3x faster etc). Most mining operations (if properly run) have more than enough capital to tide over a 2 week period of reduced mining rewards. During the 2 weeks if the distribution of the miners becomes one that I cited in a previous response as a worst case scenario for XT, the smallest pool of the three (with 12.5% power) will actually be incentivized to jump BACK to the core chain and make more money (smaller pool of fish).

      After the difficulty reset, the incentive is even higher (lower difficulty in the Core chain now vs XT chain) mining pools which are too small to ‘win’ enough rewards in the XT chain will jump to the Core chain, leaving the XT chain even MORE centralized and exposed to 51% attack.

      Of course if the dice roll another way, it could all be different. Its pretty much chaos theory and anyone’s guess at this point. Impossible to know. But it is a very very complex problem to model. (And you know why I’m sure of that? Because its a similar problem in economics and economists have been trying to predict the markets forever, with no satisfactory results.)

  9. great articles bitcoin XT has great argument mostly the block size limit to compete with big payments processors but if the dev continue to fight bitcoin will be worth nothing is a few years someone has to print bitcoin XT against bitcoin core teeshirts should be a money making business all the people who invested in bitcoin are going to lose money the dev have to work for the community

    • Yeah, so it’s a tough time for all of use bitcoiners. Who do we trust? The group who is willing to risk a Hard fork just to be overly conservative, slow, and meticulous to a fault, or the group who will risk a fork for speed, progress, and urgency ?

  10. Isn’t this an area of improvement for the Bitcoin protocol itself? “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).”
    Shouldn’t a Bitcoin mining node work like this: other miners start downloading the new block, verify it and (only then!) drop what they’re mining?
    In this way, SPAM attackers wouldn’t succeed in getting a head start.

    • That is what they do actually. I simplified that mining model a bit. Actually mining pools consist of a node and miners. (Roughly) The miners get the block header template from the node which is constantly getting and verifying transactions and blocks. So even when the node gets notification of an (externally) found block and starts downloading it, the miners never do stop mining away at their present block. The difference though is that after the download and verification if the block checks out then all the work the miners were doing in the interim time is wasted as the block they are currently mining is no longer at the tip of the chain. So effectively you can think of it analogously as if they actually dropped their work when the node received a valid block header from outside. The DoS attack with big blocks consists of giving enemy nodes large blocks to download to stall them. You cannot start mining the next block until you have downloaded the previous one as you need to include a hash of it in your next mining target block header template. Conversely now you can see why the XT chain won’t affect the core chain miners at all. As the XT block header is invalid and the core node wouldn’t even bother downloading it.

  11. Thanks, your article helped me understand this: “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 every 2 years, ***the limit increases with each block linearly***.”

  12. Yeah, so it’s a tough time for all of us bitcoiners. Who do we trust? The group who is willing to risk a Hard fork just to be conservative, slow, and meticulous, or the group who will recklessly risk a fork for unneeded speed, progress, and overstated urgency?

    => If you try to sound impartial you need to do better. Never mind the speling.

  13. Pingback: Bitcoin XT vs Core, Blocksize limit, the schism that divides us all. | Crypto-Tech News

  14. Pingback: Bitcoin XT vs Core, Blocksize Limit, The Schism That Divides Us All - Consolidated Crypto

  15. Pingback: Both Sides in the Bitcoin War

  16. Pingback: Both Sides in the Bitcoin War - Freedom's Floodgates

  17. Pingback: Let's Talk Bitcoin! #240 As They See It |

  18. Pingback: Outside in - Involvements with reality » Blog Archive » Chaos Patch (#76)

  19. Pretty good article, but there are several issues:

    (1) As you mentioned in another comment, miners don’t really stop hashing when they’re downloading a new gigantic block from an attacker. You claim it doesn’t matter because once the huge block has been downloaded, the miner will accept it and realize he had wasted all his previous work. This completely ignores the possibility of the huge block getting orphaned while it is being downloaded. If the miner downloading a huge block has 1 more minute of downloading to do, but he finds a block of his own that he knows he can transfer to the rest of the network in seconds (since he’s using the relay network), he’ll broadcast his block and the attacker will be orphaned. The only way this wouldn’t happen is if miners were running extremely dumb software that refused to look at any other potential blocks after they started downloading a huge block. If existing mining software is that dumb, it could be easily fixed.

    (2) You misrepresent the position of the XT people when you suggest that they think Bitcoin should be able to handle all transactions on earth without any caveats. Yes, Gavin and Mike would like Bitcoin to be able to handle all of earth’s transactions eventually if it could be done in a decentralized enough way. But there’s a reason why they are not proposing 8 GB blocks right now. What they want is also subject to decentralization constraints. They believe that technology will improve at a pace such that many years into the future we can handle ~53k tps in a decentralized way. You are arguing against them as if they’re advocating for 53k tps soon. Gavin doesn’t believe that 8 GB in the far future will require centralization.

    (3) You are incorrect when you say that if the XT block size increase is triggered there is no turning back. You are assuming that miners have the power to steer Bitcoin in the way that they want, against the wishes of users. They do not, for the same reason that miners couldn’t decide among themselves to continue awarding themselves block rewards indefinitely. Users would not accept their blocks, so exchanges and payment processors would not accept their blocks, so the value of coins on the miners’ new block would fall to zero and people with mining equipment would keep mining on the chain whose coins did have value. Similarly if users favored a hard fork to reduce the block size and miners did not respect this hard fork, miners would find themselves mining a worthless chain. Long term power in Bitcoin ultimately rests with those who provide the demand for coins. Just because miners have short term power before users react to them doesn’t mean they can control Bitcoin.

    (4) “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.” Your “if and only if” is too strong. If 90% of users and all major exchanges and payment processors migrate to XT and 10% of users stick with Core, the pain will be distributed almost entirely upon the 10% of users sticking with Core. It will not take long for merchants and users to know that they should be wary of people who are trying to send them coins from the “old” bitcoin.

    • Thanks for your thoughtful comments. I shall try to address them, keeping in mind that I am not a core dev.
      1) I suppose that assumes that the mining node have apriori knowledge of the expected network delays so that they can make the decision of whether to stop downloading the big block and send their’s instead, and hope that the even though the rest of the network knows that their block was not first, that it will still be preferred due to the fact that it is smaller, and thus will take less time to verify. Does mining nodes have access to a reliable source of such apriori knowledge? Additionally, I think you still are burdened with downloading the big block, as orphaned or not, you need to add it to the orphan pool, regardless of whether or not you have put it on your ‘mainchain’. So at the very least, you are spending your bandwidth resources for that extra 1min downloading this big block. Considering these kind of attacks may be executed on the ‘weakest’ miners in the network (the ones that have the worst sensitivity to bandwidth bottlenecks) and this seems to me to still be a valid attack vector, and thus a centralizing effect on the network.

      2) Actually, I find the problem is that they have an auto-schedule that doesn’t take into account external factors that may affect what the floating target of a ‘safe’ upper limit may be. Such a global economic downturn, or a world war which destroys half of the world’s internet bandwidth capacity. I don’t doubt that we likely need 8GB someday. I’m just not confident that a linear schedule is the best way of doing that. I don’t see why we just don’t let limits get hit, and when the average txn/s the last 2016 blocks goes close to 1.5x the previous window then we up the limit by 1.5x. Or some other dynamic, yet damped, system response.

      3) You are right. The miners are nothing without the exchanges and payment processors. And vice versa. But I fail to see a situation where exchanges and payment processors would ever argue for a smaller block size, once we have given them a big one. If they have built their off-chain solutions to work expecting a given txn/s or block size, scaling down would be a tough proposition. Going up or down in block limit is not a linear function, there are economic forces that make going one way easier than the other. Therefore we much have a mechanism that is always harder to increase than to decrease. Remember that left to its own devices, nature (and economic actors) tends to centralize, because centralization is a lower energy state.

      4) True, I would argue 95% is likely ‘okay’, for consensus. BUT the issue is the chaos that will occur in the interim. Wallets (let alone merchants) can’t identify which chain clients are on. And even a payment system that has a 10% failure rate, is pretty darned sub-optimal. The shake in confidence is much more serious than the technical aspect of the network incompatibility.

      • (2) I find that the biggest thing that small block advocates do not take fully into account are the sections titled “Fees” and “Growth” at There is really no good reason why we want to stay close to the limit of how large we have to be to avoid high fees, aside from decentralization pressures. The further we are above the limit, the safer we are from increases in demand having severe negative consequences. I definitely think we need to make sure we don’t increase too fast too soon so that we can preserve decentralization, but IMO 8 MB is very unlikely to cause issues now. If I were confident that the core devs could increase the block size in one day any time fees got above a certain level that’d make me much less concerned, but there is no agreed upon criteria about when to increase fees ( For all I know the core devs would be happy with 75 cent fees because it would lead to better wallet/node software for handling of fees.

        (3) Exchanges and wallet providers are in the business of serving customers. If their customers wanted the small block fork and they refused to provide coins on that fork, they’d lose their customers to exchanges and payment processors who did go with the small block fork. I agree that decreasing the block size wouldn’t be as easy as increasing it, but I think the pressure from users is very powerful and would be the dominant factor.

        • Agreed. Some sort of unofficial promise to ensure that the limit is not hit for too long would be quite reassuring by the core Devs. Though we have seen most of Mike Hearn’s concerns that unpredictable delays in confirmations due to txn backlog would somehow cause network chaos and a mass exodus of users prove untrue thanks to the stress tests. So I see no need to rush.

  20. Pingback: ビットコインXTで起きる最悪の事態とは?その問題点と影響【プレミア記事】 | 大石哲之ブログ ビットコイン版

  21. Pingback: ビットコインのスケーラビリティに関して | 日本デジタルマネー協会 / ビットコイン / Bitcoin

  22. Pingback: Bitcoin XT против Core: раскол, который нас разобщает | Bit•Новости

  23. Pingback: Addiction to Power and Radical Therapy for the 1%

  24. Pingback: The regulatory process: if you’re not at the table, you’re on the menu | Crypto Coin News

  25. Total layman here, but I tried to follow as best I could, including most of the comments. As this post is few months old now, where do we currently stand with this potential split?

    • I’m attending scaling Bitcoins Hong Kong so I’ll be able to answer you in about a week or so. From what I can say now I’d think BIP 101 is unlikely but some sort of increase of blocksize is likely. The jury is still out on whether the dangers of a hard fork are real or contrived but I think we will have hard data one way or another very soon.

  26. Pingback: Dr. Bitlove (or how I learned to stop worrying and love XT) | The Wall Street Technologist

  27. Pingback: 监管过程:只是时间问题而已 | Nxt区块链资讯

  28. Pingback: Block size: We have consensus! Or do we? | The Wall Street Technologist

  29. Pingback: It’s The Jons 2015! | TechCrunch

  30. Pingback: It’s The Jons 2015! | Gulf News Today

  31. Pingback: It’s The Jons 2015! -

  32. Pingback: It’s The Jons 2015! | EuroMarket News

  33. Pingback: It’s The Jons 2015! | Wisdom Parliament

  34. Pingback: It’s The Jons 2015! | World Updates

  35. Pingback: It’s The Jons 2015! - Press TV News

  36. Pingback: It’s The Jons 2015! - Hell on Heels

  37. Pingback: It’s The Jons 2015! – HardMug

  38. Pingback: It’s The Jons 2015! | Feedlesticks

  39. Pingback: It’s The Jons 2015! – Viral News

  40. Pingback: It’s The Jons 2015! – Nigerian Herald

  41. Pingback: It’s The Jons 2015! – Entire News Link

  42. Pingback: It’s The Jons 2015! | This Viral

  43. Pingback: It’s The Jons 2015! – Viral Headlines

  44. Pingback: It’s The Jons 2015! | Rep News

  45. Pingback: It’s The Jons 2015! » Peepstalks!

  46. Pingback: It’s The Jons 2015! | The H2O Standard

  47. Pingback: It’s The Jons 2015! |

  48. Pingback: KEEP CALM AND BITCOIN ON - Decentralize.Today

  49. Pingback: 保持镇定,把比特币进行到底 – 比特币资讯分享站

  50. Pingback: Block size: We have consensus! Or do we? | Wall Street Technologist

  51. Pingback: Dr. Bitlove* (or how I learned to stop worrying and love XT) | Wall Street Technologist

  52. Hey I am so happy I found your blog page, I really found you by accident, while I was searching on Google for
    something else, Regardless I am here now and would just like to say
    cheers for a incredible post and a all round enjoyable blog (I also love the theme/design),
    I don’t have time to read it all at the minute but I have
    saved it and also included your RSS feeds, so when I have
    time I will be back to read a lot more, Please do keep up the excellent b.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.