That’s not Bitcoin, that’s BCash
Tags: Segwit, Blockchain, Bcash, Bitcoincash, Bitcoin

It’s not about storing those transactions. It’s about full-nodes being able to receive the transaction, check the UTXO set to verify the information in the transaction is correct, and consider it valid before sending it off to the next node to do the same. This takes time. This delays propagation. Then at some point a miner successfully finds a valid hash for a block and sends that block out to the network, which must then propagate to the nodes on the network and get validated just like all the transactions. There’s ways to shortcut this by checking the block against transactions you’ve already validated, but again it still takes time, and increasing the block size directly effects this process. If you want to increase the block size, put in work that helps offset this issue.

This is real scaling:

So we’ve established (again…) that all of this is important because of the centralizing effects on full-nodes. Good, now that we’ve completely dismissed that argument, we can forget it even happened. Why? All that work you put into arguing with someone online over this doesn’t matter because:

You don’t need to run a node, only miners should decide what code is run.

There’s only two sides to this debate. “Non-mining” nodes matter, or they don’t. Anyone arguing in between these two stances is missing the bigger picture, or knows that arguing the middle ground helps the side you’re actually on win the tug of war.

…Let’s discuss why that’s a misunderstanding of the bigger picture, but first go over some simple concepts we should all be able to agree with.

It’s better to overshoot security than it is to undershoot security.

If a change in consensus results in an increase in the number of individuals with the ability to operate a full node, ceteris paribus , the network decentralizes by some value.

the network decentralizes by some value. If a change in consensus results in a decrease in the number of individuals with the ability to operate a full node, ceteris paribus , the network centralizes by some value.

the network centralizes by some value. Soft-forks are inclusive. Hard-forks are exclusive. Inclusiveness builds a healthy single network, exclusion divides.

Any change you propose that results in someone no longer being able to run their node, and the code they agree upon when they connected to the network, is a bad thing to do. You just created an enemy who has the financial incentive to oppose your change, and you downsized the network by some degree. You also established a precedent that disincentivizes others from getting involved because they may fear being disconnected. (Tangentially, this precedent is one reason why a Proof of Work change is also a bad idea. You’re cutting off nodes and hashpower.)

Additionally, you run the risk of breaking infrastructure that is already in place. Right now this includes services that are dependent on running nodes, current and future services that make use of the Lighting Network, and anything else down the line that will get built on top of this network. Lightning is just the beginning. I wouldn’t even say the network is secure right now because there’s still too much risk of change, and I don’t think it will be secure until there is sufficient layering and real-world negative consequences for even attempting to make such a change to the underlying rules.

What do I mean by attempting?

The following is a “TCP segment”. You don’t have to know what that means, and I don’t know much all about it past what I’m about to tell you.

A TCP segment consists of a segment header and a data section. The TCP header contains 10 mandatory fields, and an optional extension field. The data section follows the header. Its contents are the payload data carried for the application. The length of the data section is not specified in the TCP segment header. It can be calculated by subtracting the combined length of the TCP header and the encapsulating IP header from the total IP datagram length (specified in the IP header). — Wikipedia

Those are consensus rules. The Internet consensus rules.

If you change those rules and try to send that data across the Internet using your new rules nothing happens, it’s unrecognized. It’s invalid.

If you implement network code or hardware that uses different rules, and then connect 2 computers together with those new rules, you just created a new network which is completely incompatible with the rest of the Internet.

If you do this with a datacenter full of new hardware and software, network them all together, and then try to connect to the outside world, nothing happens, and you just wasted a lot of money and time.

If you’re the AT&T CEO and you conspire with Verizon to roll out 4G LTE as a hard-fork, you have a few options:

Surprise everyone, nobody has 4G phones, everyone switches to Sprint, and you lose so much money your mother rejects you as her child.

Announce a hard-fork date. Everyone laughs at you. You scrub your idea.

In either scenario, if you were the CEO and wanted to do this, you wouldn’t even be able to. If the entire Board of Directors voted yes, you still wouldn’t be able to get it done. From your lawyer calling you all idiots down to the engineering group being told that in 6 months they need to offline all of their switches globally, and then subsequently laughing at the memo you just sent them. While just a sample of a much broader analogy I won’t be making, this is what enforced consensus really is.

My 3G phone enforces this consensus just by existing alongside millions of others, and asking the following question just sounds absurd, doesn’t it?

What’s the minimum number of phones worldwide to ensure that you have sufficient decentralization?

Hard-forks don’t happen in real life. There are just too many layers to the entire system such that going against the grain and refusing to cooperate with existing infrastructure would only result in you getting cut off from the system. Try driving on the opposite side of the road as a hard rule. I’ve done it on an empty road, I’ve done it to pass slow cars, but actually as a hard rule? Never going back to the normal side? See how long that works out for you. Get back to me with the results.

Bitcoin’s consensus security at full scale doesn’t come from the amount of “users” running “nodes”, it comes from an overall inability to change any old rules from the mining or the client side. How we get to that point or when we get to that point I couldn’t tell you, but we will never get to that point with a “hard-forks are okay” mentality, and we will never get to that point with a “miners can dictate consensus freely” mentality, as if the miners ever even had decentralization on their priority list…

Satoshi Dundee

In an interesting turn of events, disdain has begun brewing within the BCash community surrounding Fake Satoshi (Craig S Wright). Craig is starting to get called out by his own team and I think this is important because it’s likely this will result in a perfect example as to why the “hard-forks are okay” mentality is actually not okay. Something that would normally be mundane, like a conflict between a community and a few individuals, would normally just result in those individuals disappearing or being known as “the loud mouths who won’t go away”. In this community, they have financial influence and control over various aspects of Internet/social platforms, and the potential result is a hard-fork of a multi-billion market cap technology. Sounds great, right?

It actually is. Remember inclusiveness versus exclusiveness? They both compound themselves with each iteration. Every time you try to hard-fork you end up with a minor community on its own that thinks they are all in agreement, until they’re not again and they hard-fork…again, and again, and again, splitting them up more and more. Conversely, the soft-fork community continues to build by being inclusive. Never kicking your node off the network, making sure the software you coded doesn’t become incompatible, or ensuring the wallet you downloaded doesn’t get disabled or confused on what to do or who to follow with each upgrade to the network.

Generally, each client that tried to fork, or proposed a fork for Bitcoin has had a single lead developer behind it:

Mike Hearn — Bitcoin-XT

Gavin Andresen — Bitcoin Classic

Peter Rizun — Bitcoin Unlimited

Jeff Garzik — 2X (btc1)

Amaury Sechet (deadalnix) — Bitcoin Cash

Emin Gun Sirer — Bitcoin-NG (fork proposal for Bitcoin Cash, no client yet)

Ever since BCash successfully forked off, two of these old clients have been repurposed to be compatible with that chain. Mike, Gavin, and Jeff are gone, although the clients are stringing by, but there are really only three people who have potential influence on the code and direction of BCash at the moment: Amaury, Peter, and Emin.

I don’t mean to discredit the other developers, but there’s only three others that work on Bitcoin Unlimited along with Peter who claims lead as Chief Scientist, and a two developers patch-working XT. Amaury is the only developer committing code to Bitcoin-ABC (the BCash reference client), and has helped repurpose the Bitcoin XT client to be compatible with the upcoming BCash hard-fork. This helps to put on the impression that BCash has “implementation decentralization” and that ABC is not the reference client…it is.