Bitcoin's second near-death experience, aftermath of the scaling debate, the SEC - Crypto year 2017 and what's to come in 2018

2017 has been one of the most turbulent year in crypto history to date. We have seen important changes in technology and the political climate, divides in the community, as well as wild jumps in prices of many cryptos. I would like to take a moment to talk about a few key takeaways from this year and what I think had the most impact on the future of crypto.

Bitcoin's second near-death experience

Bitcoin has been declared dead so many times it has basically become a meme. As of the time of writing, there have been 222 obituaries proclaiming the death of the currency. I'm not here to talk about those, but about a feeling you could get from old-timer Bitcoiners.

I've been in the community since 2011, and I have experienced two moments where Bitcoin's future was uncertain. I came in right around the first notable bubble, when the price soared to the unthinkable... $30/BTC (or about ~$40 in the polish markets). After that bubble has popped, the price began to decline. Slowly creeping down, taking with it confidence of many bitcoiners. At the time nobody could tell for certain what was going to happen - whether the coins will become worthless, or will we see something different happen entirely.

People nowadays despair when Bitcoin drops 30% from all-time-high peak, but back in 2011, we saw Bitcoin go down to about $2 per coin, or a decline of about 93%. The future of the project was uncertain, everyone was depressed, and for me, that was Bitcoin's first near-death experience.

Of course, we recovered. After that, when the next bubble came, you had more confidence that Bitcoin will bounce back. We've seen it before. "There is no bubble like the 2011 bubble" I tend to say.

In 2017, we had to deal with the scaling problem that has been anticipated since at least 2015. We had to figure out what solution might be the best - whether to go with big blocks, or go off the chain. At the same time, we had to anticipate that ever since The DAO and Ethereum's split, any major, contentious change to the Bitcoin protocol would create a similar split. Piled on top of that we had the covert ASICBOOST scandal and over a year of the community being forcibly divided in discussing the scaling solutions.

In other words, the pressure was rising from all sides and something had to give. At the same time, many sides have remained rigid, not willing to make a compromise. Instead we saw warring solutions - SegWit, 2x, UASF, etc. In the end we saw a group trying to reach a solution - "SegWit now, 2x in half a year", which allowed SegWit to activate but would backfire when that second part was to come due.

However, before SegWit could be activated, we had a different fork be proposed - Bitcoin Cash. Increasing the block size and changing a few other things. However, this one didn't wait to reach a majority, instead opting to declare a fork happening and going through with it.

The period following the announcement has been Bitcoin's second near-death experience. The future was once again uncertain - would this split in mining power mean some crazy oscillations in the difficulty? Would the currency retain its value after the split? Would one chain dominate the other and just take over? These were uncertain times in which the altcoins thrived.

The forks came and went, Bitcoin is still around, so is Bitcoin Cash. We now know how Bitcoin responds in this situation, so we will be ready in the future once more. "There is no split like the 2017 split" I suppose?

The aftermath of the scaling debate

Even though SegWit has been activated, we are still seeing a lot of transactions waiting to be confirmed in the mempool. With the lightning network being months away from being ready, it seems the transaction fees will keep on increasing. We can also see an interesting trend lately - people trying to bully companies into integrating the "optional" SegWit into their system to lower fees. It's somewhat disheartening to see. I hope that in 2018 we will see an empty mempool again...

Another important event that took place this year was the failed attempt to follow through with the SegWit2x agreement and the subsequent backlash against the "transgressors". We've seen old-school bitcoiners wanting to change Bitcoin's POW to spite the miners or force various businesses to "sign a very simple pledge that acknowledges that Bitcoin is not ruled by miners in order to be linked from bitcoin.org". Luckily neither of those have gotten any traction and could be written off as a pendulum effect to the SegWit2x continuing up to the 11th hour before being called off.

The last unfortunate aftermath of the scaling debate has been the decisive split of the Bitcoin community. Up until the SegWit / Bitcoin Cash split I had hopes there could be some reconciliation (1, 2). After the scaling debate would be over and the project could be back on track that we could come back together and bury the hatchet. However, once a split happens and both sides survive long enough, there is no going back - there are people financially tied to one end but not the other that understandably won't leave their side. We had some high-profile people supporting one side or the other, and what seems like layers of narrative being spun on both sides (proclaiming something is being implemented because of X, but in reality it's done because of more selfish reason Y, for example - invading Iraq because of WMDs, while in reality it might be because of oil or the like). It's unfortunate that we have failed to keep the community together in the first place and to bring it back together before the differences were irreconcilable...

Here's to hoping we can learn to at least respect and tolerate one another and remember what we were fighting for in the first place...

Crypto securities and the SEC report

The DAO has been an important project that has already shaped the industry despite or perhaps precisely because its failing. It has split the Ethereum blockchain in twine, and this year it has given us something rather unexpected - a SEC investigative report. It concluded that The DAO has been a security, which has had a significant impact on the ICO community. Now you have to seriously consider whether you're creating a security or a utility token when creating an ICO and follow with the appropriate requirements.

This has created a new wave of interest in the community. Some people are embracing being a security and taking a full advantage of that, while others are moving away from being a pseudo-security not to be found guilty of fraud or other regulations.

The crypto-securities have definitely been dominating my conversations over the last months and I have no doubt they will be the big news in 2018. I also heard some rumours from credible sources that at least one notable project has been declared to not be a security, but I can't disclose what it is until some official announcement unfortunately. So there is development happening on both sides of the spectrum, which is always good to hear.

Conclusions

The Bitcoin scaling forks and splits have been a major event in the Bitcoin's history. They have left a lasting effect on the community and technology. This year we have also seen some important report coming from the SEC that has already began to shape the ICO landscape. We are likely to see that become a major influence of what 2018 will look like.

Here's to 2018 and what's yet to come!

The need for universal opt-in replay protection

SegWit2x got cancelled, and with it probably the most heated "battle" in the Bitcoin space thus far draws to a close. There are many lessons to be learned from this ordeal as well as some other forks that are happening around Bitcoin - what constitutes "consensus" in the community, how will the future forks be handled and so on. One important aspect I haven't seen discussed as much currently is the ongoing issue of fork-proof replay protection - a feature that caused some controversy by its absence in SegWit2x and made Bitcoin Gold a laughing stock when they created a bounty for it very close to their forking date.

Strong vs opt-in replay protection

There is an important distinction to be made between strong and opt-in replay protection. When a fork occurs, the former is always on and prevents any transaction on one side of the fork from being valid on the other side of the chain. Bitcoin Cash has strong replay protection for example.

Opt-in replay protection on the other hand is optional - you can create a transaction that won't be valid on the other side of the fork, but you are also able to have a transaction that is valid on both sides.

Strong replay protection is useful when you want to split from the main chain and remain an independent project. However, it can be detrimental when the changes you're proposing are meant to be an upgrade to the current code rather than forking off into a new project. This is why SegWit2x didn't opt to have a replay protection - it was meant to be an upgrade to the Bitcoin project and be the only version used. The only way to achieve that was to make it hard for both sides of the fork to coexist.

Problem with opt-in replay protection

While opt-in replay protection sounds like the proper way to go, there is one important problem to consider - how do you implement it in a way that will apply to all future forks?

In a perfect world, every fork would be carefully maintained and it would make sure to make its opt-in replay protection create transactions only valid on its own chain. However, as Bitcoin Gold and other projects have proven - we can't rely on forks being managed competently. Hence, we need a universal opt-in replay protection, one that is agnostic to any future forks (even those that don't honour any replay protection whatsoever) and creates transactions that will be only valid on one chain.

Universal opt-in replay protection

A fork that splits off from the main project can be caused by any alteration to the protocol. There is no universal way to differentiate between both sides of the fork ahead of time save for one - the blockchain history. You can mimic anything about the code, even pretend to be some different client, but for certain at some points the blockchains will diverge - otherwise we wouldn't be dealing with a fork. Once that is done, the data can be used to implement the replay protection.

If one could flag a transaction to only be valid if a given block hash is present in the blockchain, that would be enough to ensure it will always be possible to safely move coins around on any fork that might occur in the future.

If both sides of the fork honour that flag, only one side will include the transaction in the block. Do this on both sides and the coins will be safe to spend on two sides of the fork.

If only one side of the fork honours the flag however, the replay protection could still work, albeit with some limitations. You would need to create a transaction with the flag on the chain that doesn't honour it. This way the chain will include the transaction in its blockchain, but the main chain will reject it, since it would not recognise the block hash. After the first transaction is confirmed, it would be safe to spend the coins on the other side of the fork.

Conclusions

It is possible to implement a universal opt-in replay protection that will still be effective even if only one side of a given fork will respect its rules. This should be sufficient to protect one's bitcoins in an event of a possible future bitcoin fork.

The proposed implementation is rather simple and elegant. I came up with this idea when contemplating SegWit2x awhile back, but then became pleasantly surprised when I found out someone else already proposed it as a BIP115 a year before :). It's not part of the main codebase yet, but maybe by the time next fork rolls around we'll have something to protect our bitcoins with...

Hard fork contingency plans and SegWit readiness - a challenge to solution evangelists

Currently, the biggest discussion in the Bitcoin community concerns the possible forks we might see this year - Bitcoin Unlimited and SegWit. Whether those forks should or should not be activated and whether they will create a network split is an important discussion, but what is less discussed is the risk mitigation in case either of those forks happen. I would like to post a challenge to the various solution evangelists to see if their software is ready for any outcome.

Note - some questions apply to more than one scenario. Duplicates have been omitted for conciseness.

Scenario 1 - SegWit activates before Bitcoin Unlimited

Lets say SegWit activates before Bitcoin Unlimited or any other block scaling solution takes place.

First, some questions to the Core team:

How much extra transaction throughput are you expecting to see with this solution?
Do you have any estimates as to how many transactions should move off-chain in the near future? When do you expect this solution to start reaching critical mass to alleviate the block congestion?

How many of the big Bitcoin companies will be ready for SegWit?
This important question is somewhat answered by a handy spreadsheet or two. Let's have a look and see if some important players are missing... Coinbase is "planned" so far. BitPay is nowhere to be seen. BitGo is "wip". Top exchanges - Poloniex, bitFlyer, BTC-E, OKCoin are missing. For the wallets - Armory, BreadWallet are wip, Bither, Exodus and Multibit HD are planned.

All in all, the coverage looks good, but some top players still need to get on board.

What are the fees users should be expecting?
A large pressure for the increase in the network capacity comes from the high fees to the average user. What fees should the users expect under SegWit? I've seen mention that on-chain fees will drop from 0.5BTC/block to about 0.2BTC/block, but some numbers on the off-chain fees would also be interesting.

What is the block scaling plan going forward?
Are you planning on changing the block size following SegWit? If so, when are we likely to see the size change and what would it be?

And a big question for the Bitcoin Unlimited team:

Is your client SegWit ready?
Are you ready to integrate SegWit into your client? Will it have some issues in case SegWit activates?

Scenario 2 - Bitcoin Unlimited activates first, network splits

In this scenario, Bitcoin Unlimited activates first and the network splits itself into Bitcoin Core and Bitcoin Unlimited.

Question to both sides:

How are you mitigating the damages of the split for your users?
There are many things that need to be considered when the network splits. How are you mitigating the cross-split replay vulnerability? How will you avoid the confusion when it comes to addresses being the same on both networks?

Bitcoin Unlimited devs:

Is your code ready to be pulled to Bitcoin Core?
A lot of people consider Bitcoin Core to be the "gold standard" when it comes to Bitcoin clients. Developing a different client without allowing the options to be pulled into Bitcoin Core cleanly will only make the adoption of your client harder.

So, is your code ready to create a pull request to Bitcoin Core? Do you have a branch that is up-to-date with the latest commits to Core, or will you need to catch up? If you don't have these ready, it is almost inviting a network split, rather than working on keeping the network unified.

Will you be activating SegWit on your network?
There are some good use cases for off-chain transactions - will you be activating SegWit or other soft forks required to run off-chain transactions on your network anytime soon?

How are you planning to convince more exchanges to adopt Bitcoin Unlimited?
Some developers have sworn off BU completely - for example, BitGo (and thus indirectly - BitStamp, OKCoin, Kraken, etc.), while others might be on the fence. Do you have any plans on convincing them to start supporting your software?

Bitcoin Core devs:

Will you make your client opt-in compatible with Bitcoin Unlimited?
This question was originally asked by Gavin - since "Bitcoin Core does not want to and does not make decisions on Bitcoin’s consensus rules", is Bitcoin Core prepared to let the users op-in to be able to connect to the Bitcoin Unlimited network? It shouldn't be that much work to add a flag disabling the block size check at the very least.

Scenario 3 - Bitcoin Unlimited activates first, minority network gets attacked

In this scenario, Bitcoin Unlimited activates first, the network splits, but the minority chain gets attacked by miners in hopes of preserving only one side of the fork.

Bitcoin Core devs:

What is your contingency plan for such an attack?
As I understand, the current plan is to change the PoW algorithm in a hardfork. Is that hard fork already in the works? Is the new PoW algorithm decided on yet? Has the hardfork been tested? It is a large change - you don't want to be scrambling around trying to figure this out while an attack is ongoing. Do you have your legal side of things covered? Will you be coordinating actions with important Bitcoin players, such as exchanges?

Since hardforks don't come as often, are you planning on implementing any of the hardfork wishlist items while you're at it? Will the hardfork also include SegWit?

Bitcoin Unlimited devs:

What is your plan for such an outcome?
Will you be endorsing the attack, or will you be disowning it? Are you prepared for potential legal, community, etc. backlash you might receive if the attack takes place (even if it's not of your own doing)?

Conclusions

There are many important questions that need to be addressed early on before Bitcoin starts forking. While we might still have some time before either fork activates, it's better to mitigate the potential risks early on than to scramble when they actually take place. I'm looking forward to developers from either of the sides sharing their thoughts on the issues raised here.

Bitcoin hard fork - if you want peace, prepare for war

Over the last few weeks we had a lot of people discussing Bitcoin forks. Every member of the Bitcoin community is voicing their opinions on the matter, so I figured I'd write down my thoughts as well.

Historical perspective

While the debate has picked up a lot recently, it's by no means a new problem. BIP101 proposed increasing the block size in mid-2015 and BIP-141 introduced SegWit in late 2015. Since then we had a number of projects wanting to fork Bitcoin - BitcoinXT, Bitcoin Unlimited and Bitcoin Classic. This is in addition to things like Sidechains, Liquid, user-activated soft forks, etc.

All in all, we can all agree (well, with some exceptions) that we need to expand the Bitcoin network transaction capacity. We can't really wait much longer - this was starting to be an issue in 2015, and now it has become a necessity.

Bitcoin slowing down

Bitcoin for a long while had the first mover advantage - everyone wanted to get into it, develop on top of the platform, etc. Being in the community early was really fun - seeing the first ATM launch, getting merchants on board, etc. However, nowadays it's a different story. Waiting multiple blocks to get one confirmation, paying over 30 cents in fees, etc. - that's not an ideal situation in comparison to what we saw years ago.

If nothing changes, we'll probably see a lot of the big Bitcoin companies expand or migrate to other platforms. Coinbase already doesn't want to pay the fees by themselves, Storj has moved to Ethereum, etc. With Ethereum's growing market cap, there are only so many reasons to stay with Bitcoin...

The fork

So this brings us to the fork situation. There is currently a lot going on in the community, but from what I can understand, there are two main camps when it comes to forking at the moment - those that want to activate Bitcoin Unlimited and soon, and those that want to get SegWit activated sometime this year.

When figuring out what can happen next, we have to keep in mind the scant few examples we had of contentious coin hard forks in the past.

From what I can tell, Bitcoin Unlimited is heading in the direction of activating its hard fork no matter what. It's ramping up in node and mining power count. It is likely that the node count is fake, and there have been some reports about the possibility of attacks on pools that don't signal Bitcoin Unlimited (by orphaning non-signalling blocks in a minority attack). There is also a concern with miners being blacklisted by the effective monopoly in mining ASICs if they signal SegWit.

Lastly, we need to keep in mind the man pushing for Bitcoin Unlimited adoption - Roger Ver. I'm not going to get into discussing his past or personality (there are plenty of trolls that have you covered), instead, lets focus on one fact - he's an early Bitcoin adopter, and he appears to be loaded. Being able to trade 130k BTC loaded. That's more than 4 times the amount of BTC Ethereum raised during its presale. So my guess is, that he could safely pay out of pocket to fund the forking effort, even if it doesn't make economic sense.

So because of this, I think the Bitcoin Unlimited will activate its fork sometime soon. Now, what will happen next?

The aftermath

It was interesting hearing Gavin's exchange with Matt on whether Bitcoin Core should have an opt-in flag to accept the possible fork or not. It looks like the answer for the time being is "no", which means the repository everyone considers to be the "gold standard" for Bitcoin will not accept Bitcoin Unlimited blocks, causing a fork.

If you want to keep Bitcoin network on only one side of the fork, you have to attack the other side. Whether that is a moral or legal way of handling the situation - it's up for debate. At any rate, 51% attack on the Bitcoin Core side of the fork is a possibility that has to be kept in mind. Luckily, there is "a nuclear option" to defend against something like that - PoW change. Since the vast majority of Bitcoin mining power is in ASICs, any change to the mining algorithm makes all of that hardware obsolete. This will mean that an attacker that has been stacking up on ASICs will end up with a large pile of useless hardware, but also that your honest miners will have the same issue.

So if Bitcoin Unlimited forks and tries attacking the Bitcoin Core side of the fork, it is likely we will end up with a PoW change fork and the unchanged, SHA256 fork. The SHA256 fork will either be kept alive by miners that oppose the Unlimited fork, or it will be left by the wayside as they will realise where the wind is blowing and switch over to Bitcoin Unlimited to maintain some income from their hardware.

Early on, the PoW fork would still be vulnerable to an attack. There are a lot of altcoin miners out there ready to put their CPUs and GPUs to work. Whether they will stand with the Bitcoin PoW fork supporters or be mercenaries for hire by the attackers remains to be seen.

If there is no attack on the minority fork, the Bitcoin landscape will probably be more peaceful, but also more divided. A number of exchanges have already signed a statement on the hard fork matter, and it looks like they will either be ignoring Bitcoin Unlimited, or treating it as an altcoin. So all in all, we'll have the Ethereum / Ethereum Classic scenario once more.

If a fork happens and Bitcoin Unlimited doesn't secure key supporters early on (miners, exchanges, developers, etc.), it is possible it will go the way of Elacoin. A coin needs to be traded and developed upon to stay relevant.

Preparations

Since the fork has not yet happened, there is still some time for preparations. Every Bitcoin business will have to consider the implications of the fork on what they're doing. How will customer BTC balance be handled? How will you prepare for the relay attack? What are the edge cases you need to think about?

Even working for Factom I had a discussion about this issue, and we're not holding BTC balance for our users.

Finally, every Bitcoin user will have to prepare for the fork. Whether you decide to hold onto bitcoins at a responsible exchange, keep it in your wallet, or sell it for now in hopes of buying cheap coins during the turmoil, you should make a conscious decision on what to do, or risk getting some of your coins lost in the process.

Conclusions

Bitcoin needs to address its transaction throughput sooner than leter. It is likely Bitcoin Unlimited will attempt to hard fork soon. The fork will either lead to the community being divided, or an attack on the minority chain to force everyone to switch. The attack will likely lead to another fork and an uncertain future fo the minority chain. Everyone should ready themselves for the fork.

If you want peace, prepare for war.

Contentious Bitcoin fork WILL create a split

The Bitcoin community has debated a potential hardfork to Bitcoin for over a year now. There have been various solutions proposed to change the hard cap on block size and increase the amount of transactions that can go into any single block.

Leaving aside the discussion as to which approach would be the best for Bitcoin in the long run, we can agree that there is a disagreement on the issue and any hard fork that may happen will not be as unanimous as the previous forks were. Looking at some recent examples, we can expect that any contentious Bitcoin fork will create a split in the network.

Big players can trump forks - Elacoin

Last year Steve Sokolowski shared his thoughts on a Bitcoin hard fork proposal in a forum post. Other than discussing the actual solution, Steve also shared a story of Elacoin's attempted hard fork. Apparently, it was some unremarkable Proof of Work altcoin which activity has died off after awhile. A new developer came in and decided to breathe new life into the coin by creating a Proof-of-Stake fork. A lot of people got excited for the update and the trading volume and price rose back up.

When the fork was scheduled to take place, despite the backing of the community, the developers and stakers, the fork failed since Cryptsy continued to trade the coin without upgrading their daemon. Eventually the hard fork was deemed a failure while the old coins were still being traded.

This brings to mind the famous experiments with five monkeys, a ladder and a banana. People would trade a coin in anticipation of the fork, then ignore the fork and continue trading the coin due to its increased price and volume, completely forgetting why they were trading it in the first place. Classical altcoin speculators.

This only goes to show that big players, even if they are in a minority, can trump developer forks. While a story like this is rather unlikely to happen in Bitcoin, since the coin itself has many different markets and a vast community, we could experience a different problem when a hard fork happens...

New Coke vs Coke Classic - Ethereum

Not so long ago, Ethereum has experienced The DAO debacle, wherein a large quantity of ethers were drained from a high-profile smart contract. This prompted the Ethereum developers to create a hard fork that invalidated the attack. For a few days everything seemed to go smoothly - the majority of the network supported the fork, everyone transitioned just fine and it looked like the network could put the kerfuffle behind them. Then came Ethereum Classic...

Ethereum Classic is, I suppose, an "un-fork" of Ethereum - a codebase designed to ignore the DAO hard fork and continue the network as if it never happened. Whether the developers believe that they are supporting the community that disagrees with the fork, or they just want to make a quick buck, the fact is that the classic ethers (ETC) started being traded on Poloniex, probably one of the biggest altcoin exchanges currently, and now are being actively traded on a number of other exchanges with a current market cap of $200M and 24h trade volume of $65k - forth market cap after Bitcoin, Ethereum and Ripple, and having double the trading volume of Ethereum, second only to Bitcoin...

From a perspective of any Bitcoin core developer wanting to fork Bitcoin, this is probably the worst thing that could have happened in the given situation. Exchanges supporting both sides of a fork can set a precedent of what will happen when Bitcoin is forked in any fashion short of full unanimity. Even if the unforked version of Bitcoin has 1% of its market cap, that's $94M market waiting for an exchange to take their money - it would be the 7th largest coin market, around the halfway point between Litecoin and Dash.

As an Ethereum Developer pointed out in an Ethereum Foundation Skype Chat leak - ignoring Ethereum Classic means there is no money to be made, while embracing it allows you to tap into some "vestigial value remaining from the shared chain history".

Even if any potential fork has all of the support from all of the developers and miners, there isn't much one can do to stop the un-fork, perhaps short of a Coiledcoin-esque 51% attack. Even if networks like Ethereum implemented "the bomb" (a special smart contract that prints tokens out of thin air, intended to kill an un-forked network), a developer could just create another hard fork to disable that code pretty much like the DAO was disabled...

Kill it with fire

So when all is said and done, it looks like the only way to ensure only one version of Bitcoin is around, one would need to reach an overwhelming consensus with the developers, the miners and the exchanges to support only one part of the fork. Anything short of that will create a split network with duplicate tokens being created on both tines of the fork.

To ensure the rest of the network follows suit, someone should put aside some funds and mining power to be able to execute 51% attacks on any un-fork that would start being traded at an exchange. While a 51% attack in normal cases might be in the legal murky territory, perhaps using it to enforce a hard fork might not be seen as an attack on the currency, but as a part of the upgrade process. The law might not catch up to this conundrum for years still.

Conclusions

Anything short of an unanimous hard fork to Bitcoin will most likely result in a network split where both sides of the fork. The split will most likely be motivated by short-term profit to extract some remaining value from the alt-chain. A good way to ensure no such split happens would be to divert some resources to performing 51% attacks on the minority chain and thus causing whatever exchange that tries to trade them to lose money.

Related discussions:

• "A lot of us here hate on and criticize Ethereum and Altcoins, when in truth we can learn a lot about their respective success and failures"
• "We only have one chance"
• "Failed hardfork example, Elacoin"
• Discussion on /r/Bitcoin and /r/btc

Handling bitcoins during a hard fork - pondering Bitcoin XT

As everyone might've heard by now, there is a big debate in the Bitcoin community about whether or not we should increase the block size limit. Some core devs are pushing for the size increase with the Bitcoin XT version, and it looks like some people might be committed to the hard fork even if the community would be against it. This can be a potentially dangerous move that fragments the Bitcoin world to those that use Bitcoin QT and those that use Bitcoin XT. If this was to happen and both of the versions were to coexist, there is a lot more than just confusion to be had for anyone that holds funds on behalf of their customers.

Hard fork and the transactions

Initially, when the hard fork happens, all transactions will be interchangeable between the two blockchains - after all, they will be spending the same outputs using the same algorithms. You could broadcast the same transaction to both blockchains and they will be able to get into the blocks just fine. However, this also means that any withdrawal from shared wallet, like from an exchange or CoinBase, may siphon the funds out of both chains even if the service is using only one chain. If a service was to ever switch over to the other chain, their balances might be out of order.

Over time, the networks will start drifting apart. Any transaction that spends the coinbase transaction of a block minted post-fork won't be copyable to the other chain. Similarly, any conflicting transactions will only be valid on one chain.

Since Bitcoin network currently has a lot of unspent outputs (such as the ones tied in physical bitcoins), we will probably see transactions valid on both chains for years to come.

Confusion about addresses

After the fork happens, there can be a lot of confusion as to what network everyone is on. If the address structure remains identical, someone asking you "to send 1BTC to 1PiachuEVn6sh52Ez7o6Fymvw54qvQ4RBm" might be confused when you send that amount of money to the listed address, but on a different network.

Maybe the devs behind BitcoinXT will take some precautions to prevent such mistakes by altering the Base58 alphabet in a similar fashion to Ripple (yes, Ripple addresses are identical to Bitcoin with the difference of the final Base58 alphabet used). Perhaps BitcoinXT addresses would start with an X instead of 1 without changing the underlying mathematics behind address creation or net bytes?

Recommendations for exchanges and other services

Even if one side of the fork will be more likely to stick around than the other, it is still useful to be prepared to exist on both sides of the fork. My recommendation for any exchange or service relying on a shared wallet is to make a backup of all user balances on the day the fork occurs. Since those Bitcoin balances would be valid on both chains, if the service was to support both sides of the fork, users should receive the same balance in BitcoinQT and BitcoinXT.

After that, both the hot and cold wallet balances should be spent on both chains in a conflicting fashion (send all funds to A on BitcoinQT, and all funds to B on BitcoinXT). After both transactions are confirmed on the separate forks, there will be no chance of the same transaction being copied between the chains. The balance of whichever chain is not used should be safely stored for the time being along with the backup of user balances.

If an exchange was to support both of the chains, supporting them straight away would create the least amount of confusion. Users should receive the same balance on BitcoinXT as they currently have on BitcoinQT, with their fiat balance remaining intact. Afterwards, the users would be free to trade both coins like they would be separate altcoins.

Conclusions

A Bitcoin hard fork might be coming. Exchanges and hosted wallets should have a plan of action if both chains were to co-exist.