Bitcoin – Potential Network Disruption on July 31st

I'm really tired of hearing the "increasing the block size won't suffice"-argument. Yes, increasing blocks to 10 MB won't give us VISA-scale, but it will allow Bitcoin to serve TEN TIMES AS MANY USERS! I can't believe how many otherwise intelligent people fail to see that this is desirable. It's like driving your car at 10 km/h per hour on the high-way and refusing to increase your speed because that would still not make you as fast as a rocket.

Well - increasing the block size is not costless - it is not just pushing the gas pedal a little more like in your example.

A counter-argument is that the Lightening work is a proprietary development outside of bitcoin core (lead by Blockstream) and the work is even patent-encumbered.

They state the ip is for defensive purposes only - however that is questionable given that anything they implement, automatically becomes prior-art. It is also contrary to the spirit and practice of the majority of crypto/alt projects.

It is unreasonable to attack miners for having interests, without disclosing that other interests may benefit from the current levels of network congestion that a skeptic would say are caused by having artificially small blocks.

I wish there was a concise way to explain what is going on, but there really isn't. I'm going to do my best though.

Bitcoin is a consensus system. This means that the goal is to have everyone believe the exact same thing at all times. Bitcoin achieves this by having everyone run identical software which is able to compile a list of transactions, and from there decide what money belongs to which person.

As you can imagine, it's a problem if you have $10, and Alice believes she owns that $10, Bob believes he owns that same $10, and Charlie believes that the money was never sent to either of them. These three people can't interact with eachother, because they can't agree on who owns the money. Spending money has no meaning here.

In Bitcoin, there are very precise rules that define how money is allowed to move around. These rules are identical on all machines, and because they are identical for everyone on the network, nobody is ever confused about whether or not they own money.

Unfortunately, there are now 3 versions of the software floating around (well... there are more. But there are only 3 that seem to have any real traction right now, though even that is hard to be certain about). Currently, all versions of the software have the exact same set of rules, but on August 1st, one of those versions of the software will be running a different set of rules. So, depending, people may not be able to agree on the ownership of money. If you are running one version, and your friend is running another, your friend may receive that money, or they may not. This is of course a bad situation for both of you, and its even worse if you are working with automated systems, because an automated system likely has no idea that this is happening, and it may have no way to fix any costly mistakes.

It gets worse. The version of the software that is splitting off actually has the power to destroy the other two versions of the software. I don't know how to put this in simple terms either.

In Bitcoin, it is possible to have multiple simultaneous histories. As long as all of the histories are mathematically correct (that is, they follow all of the formal rules of Bitcoin), you know which history is the real history based on how much work is behind it. The history with the most work wins. If the history is illegal, you ignore it no matter how much work is behind it.

So, this troublemaker version of the software (the UASF version) has a compatible set of rules with the other 2 versions. Basically, everything that it does, the other versions see as valid. So if its history is the longest, the other versions will treat that history as the one true history. The thing is, this troublemaker version of the software is stubborn, and so even if the histories of the other two versions have more work, it'll ignore them and focus only on its own version of history.

So, the dramatic / problematic situation happens if the UASF software initially has less work in its history. What'll happen is a split, and two different versions of Bitcoin will exist at the exact same time. But then, if the UASF software ends up with more work after some period of time (days, weeks, etc.), the other versions of the software will prefer its version of history over their own.

Basically, what happens there is that entire days, or weeks, etc. of history get completely obliterated. The UASF history becomes canonical, and the histories built by the other versions all get destroyed. Miners lose all of their money, people who accepted payments lose those payments, people who made payments get those payments back. Basically a lot of chaos where people end up losing probably millions and millions of dollars.

----

I hope that helps. This whole situation is screwed up, and really the best thing to do is to put your coins in a cold wallet (one that you control, not an exchange), and then just not send or receive any coins for a few weeks. Let the dust settle, and then resume using Bitcoin once its clear that the turmoil is over.

----

The most likely situation here is that nothing interesting happens at all. My personal opinion is that the vast majority of people who matter in Bitcoin aren't even paying attention to the drama, and something dramatic is really only possible if the majority of Bitcoin users opt-in to doing something. I don't think that's the case at all, which means essentially nothing interesting is going to happen.

But, I could be wrong. There's a non-zero chance that something very unfortunate happens, and there's a pretty easy way to isolate yourself: don't send or receive any Bitcoins starting July 31st, and don't resume until it's clear that the storm has passed. It'll likely take less than a week to come to a well-defined conclusion.

I think the car analogy is not quite correct. A car is able to dynamically change its velocity, bitcoin can't easylie do that. It would be much better to find a genereal solution that fix that problem altogether, instead of finding a solution that works for the next few years and might require future forks.