The article is crap and tries to induce in error less savvy readers.
There are a lot of bitcoin forks, litecoin and dogecoin are examples of such forks the same way Joomla! is a fork of Mambo, Bitcoin Unlimited is a protocol upgrade.
In bitcoin development what is called a fork, hard or soft, is different from what the author is trying to compare with.
BTW, the same claim can be made about the changes Bitcoin Core team is trying to introduce.
You don't know shit about bitcoin. You don't get to say what is and isn't a protocol upgrade. BUcoin introduces a deep protocol change with something demonstrated to not work called EC. satoshi was against getting his software forked for a reason.
A second version would be a massive development and maintenance hassle for me. It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.
I know, most developers don't like their software forked, but I have real technical reasons in this case.
The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.
The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.
The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.
The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.
I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.
The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.
satoshi qualified BUcoin literally as a "menace to the network".
All exchanges already spoke: BUcoin will be an altcoin, they all will support the BTC token for Core, your BUchina will never be BTC. I will enjoy dumping BTU or BTE or whatever is called for more BTC.
