There is a lie and myth of decentralised consensus where a small group of developers alters a protocol and says that it is a fork that somehow relates to the original system. Bitcoin was said to be set in stone, and it is the only way the system works. I shall detail in this post why Bitcoin must follow the original protocol and why alterations that take away from the white paper mean that they are no longer Bitcoin.
Forking the software is not the same as altering the protocol. There is a radical difference that people have been trying to obscure. The reason for doing so is simple; they are misleading investors in a false and vain long-term attempt to hijack a system.
The key technology within Bitcoin is the ability to create a single ledger. It cannot be divided into two and remain Bitcoin.
One use of Bitcoin is to store information such as ledger records. Let us start by imagining that property records are stored on the Bitcoin blockchain. Ask the question: if the ledger is copied, what happens to the property record? If you have a real estate ownership record stored on an original protocol, and the protocol has now been copied by a new set of developers who have decided to take the protocol in a different way, ask the question: do you now have two copies of property? Can you sell the real estate record proving ownership of your property to two parties and maintain a legal right under both titles? If you have a company share, is the share now valid on both chains?
People (the ignorant, fools, or those seeking to scam others in reality) will seek to sell a false concept of decentralisation. They will tell you that even a security token issued over Bitcoin or another copied blockchain will allow you to democratise finance. It is utterly false.
There are many things that Bitcoin solved. The ability to bypass regulations is not one of the solutions. In fact, it makes systems easier to regulate, and it makes it harder to operate outside the law. The concept of an ICO and the so-called ability to operate outside of regulations is nothing but a re-badged penny stock/pink sheet scam in the form that occurred in the 90s using USENET and websites.
Apple shares are decentralised.
Google shares are decentralised.
Monsanto shares are decentralised.
Here lies the point; anyone can buy an amount of common stock and vote. More importantly, there are rules that protect not only the founders of such organisations but also small investors. This drive to say how finance is being democratised because of ICOs and associated scams (every single ICO that has ever existed is in some way a fraud designed to mislead and steal funds from foolish investors) is simply an investment engine.
Prepaid investment tokens are not new.
There is not one single use case of any ICO or tokenised good that has not existed in some form in the 20th century. Anyone who tells you that an ICO is in any way different is again attempting to pull the wool over your eyes. Bitcoin can help businesses lower the cost of managing their ledger records. It in no way at all helps democratise shareholding or even aids consumers.
More importantly, no blockchain will ever significantly reduce the cost of an IPO for a company. To make the claim that it will materially change the cost of capital raising is to falsely and misleadingly claim that the ledger and database behind raising capital are in any way a material aspect of the costs of conducting an IPO. Blockchain does not help market. Blockchain does not aid in auditing statements and assertions made about the future as they have not been recorded. The fact of the matter is that every ICO ever created has simply been a pure scam designed to raise money by bypassing existing law and confusing regulators, saying it is decentralised.
If you can change the protocol, you cannot call it decentralised.
The protocol associated with any blockchain is set in stone.
As soon as you alter the protocol as a developer, you have exerted power. It is the nature of decentralised systems. If you can change protocol, you are proving control. Arguing that you are only a group of developers is irrelevant. In the UK, we have the Unincorporated Companies Act.
In effect, if viewed as a derivative associated with an informational commodity, Bitcoin and any related time-chain system (which is the correct term for blockchain) cannot fork the protocol. An alteration means in effect that it is a system controlled by a small number of individuals.
Such control and power is important. When we look at Bitcoin, the rules allow miners to risk orphaning blocks but not to change the rules. As such, I mean that the block cap is outside of the protocol. Miners can accept an arbitrary limit with an understanding that if they choose not to take larger blocks or build on larger blocks, other miners may bankrupt them.
The reality is that there has never been a group of more than eight people who control Bitcoin Core (BTC). Consequently, all code changes, all protocol changes to the system are overseen by a group that is smaller than many public company boards. More importantly, the same group has confused and misled miners and investors into believing that you can only run Bitcoin by updating the software they provide.
It effectively makes them an unincorporated board issuing derivatives under their control.
If they could maintain software, yet had no rights to alter the protocol, it would be different. If the protocol is set in stone, the actions of a group of developers no longer matter. There is no way to decentralise a group of developers. Anyone who’s telling you differently is lying. Developers are people, and no matter whether they use pseudonyms or not, they are simply individuals acting within a system that can be controlled by the law. Even if they don’t have a formal partnership or a company, they are in effect simply an unincorporated partnership or trust.
How does the fraud work?
Fraud is an attempt to gain money out of people through deception.
So I will quite simply call the airdrop scams associated with protocol changes a fraud. Creating a new coin and competing based on a promise of a new system is different. As such, something like Ethereum Classic (ETC), when it was originally created, was a completely new coin, and those owning Bitcoin did not receive anything.
It is an important point;
In the 1990s, there were many Internet security offerings where shares would be distributed for simply signing up to a webpage. There were also a number of attempts to split organisations and say that they were not a demerger.
When miners act within the rules or change the limits within the rules of the manner that Bitcoin works, only one ledger exists. If we take the introduction of a block cap, it is not a change to the protocol rules. Any miner could seek to continue with blocks bigger than 1 MB, and if more than 51% of the network supported it, it would be the new norm. There is no requirement to update or change the software.
It is the bait and switch, a change such as Segregated Witness, that is a protocol change and requires software to update.
The miners, as they validate blocks, do not impact user wallets. To take two examples, if nodes start enforcing a limit on the size of blocks or the number of transactions they will accept, it does not in any way alter how users receive transactions. In fact, a user could have an nLockTime transaction set to run three years from now, and it will remain valid.
Miners can choose what they will and won’t build on. But, it does not allow for the introduction of new aspects in the protocol. It allows rules to be enforced within the protocol.
The distinction is that miners cannot force a change that alters the ecosystem. Any such change is the creation of a new system and protocol. If we take the change implemented by the Core team, what we see is not a vote on something like block size by miners. Rather, it is a group of individuals promoting a new system.
We saw the same happening in the alteration by the Bitcoin Cash team.
When Bitcoin Cash forked away from Bitcoin, they promoted a radical alteration that required that they talk to exchanges. Exchanges had to be convinced to alter the software running on their machines.
It occurred with the introduction of a new form of reordering, radically changing the way Bitcoin operates. The Bitcoin white paper explains that transactions are ordered by time of arrival. It is a key aspect of what Bitcoin does. Bitcoin Cash created an airdrop copy of Bitcoin by duplicating the existing ledger and then continuing it going forward with the addition of an altered protocol. It incorporated new OP_Codes and radically changed the block-ordering system amongst other alterations.
No amount of hash power alone can do so with long-term success. Interestingly, many of the Bitcoin Core supporters mistakenly came to believe that a UASF could work and that users can set protocol rules. Which is also an error. The distinction is that the protocol is set, and miners can choose to act within the protocol.
It is not Bitcoin that changed at the fork. It is BCH that was altered just as it was BTC that forked away from the original Bitcoin protocol to drop the requirement for digital signatures.
And it is part of how they fool people. The current bucket shops that call themselves exchanges and yet play loose and fast with other people’s money — acting outside of the requirements of law (such as the US BSA) — alter a ticker symbol, and people believe that such is what dictates the underlying ledger system. They do not notice that they need to update their software.
They do not see the updates from the organisations and companies that are running Bitcoin. They do not notice that if such organisations and companies stay on the original protocol, their transactions will no longer be valid.
It is an important point; miners can choose not to validate a particular rule at any time and risk losing profit if they like to do so and others do not follow, but they cannot alter the protocol itself.
It is a key aspect of the security model of Bitcoin.
The quote “They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism” only remains valid where the protocol itself is unchanged.
SPV — Simplified Payment Verification
People have either completely failed to understand SPV or helped mislead others when it comes to its use, seeking to promote a false agenda. Importantly, if a user is storing keys, they can store an input transaction.
The customer wallet, that is the person sending a transaction, can even be offline. They do not need to check whether change is sent to them, they dictate where the change is to be sent, and if the merchant doesn’t send the transaction to the network, then the user is not ever charged.
SPV is far simpler than people understood. There are no needs for private proves or any of the other boondoggle projects that people are seeking. All that needs to occur is for the wallet to store not only the keys but also the transaction details for the last transaction. Consequently, if Alice is sending bitcoin to Bob, and she has two input transactions (Tx1 and Tx2), then all she requires to store is the block headers, the Merkle paths for the transactions that she wants to spend, and the transaction itself. Bob can simply check the information and calculate the Merkle path and block headers to validate the transactions that Alice is sending to him against the inputs. At this point, Alice only needs to keep the block headers, as I explained in section 8 of the white paper.
Note the following features of the offline customer SPV wallet:
1. UTXOsTXs — Pre-loaded full, unspent transaction outputs (UTXOs) can be stored as pre-paid ‘money’ available to be data containing Alice’s available unspent transaction outputs. Full transaction data alongside a Merkle path constitutes a Merkle proof that the transaction Alice is spending is valid. Hashing the full transaction will give the TXID which is required as part of the input data for the new transaction spent.
2. Private/Public Keys — The wallet must have access to a set of private keys to sign UTX outputs and public keys to specify change addresses when conducting transactions.
3. Merkle Paths — The Merkle path of each of the transactions containing the UTXOs will be used by the merchant’s point of sale wallet to verify that the UTXOs are valid. Note the Merkle proof provided by such a wallet does not prevent a double spend, but acts as a fail-fast mechanism against spam attacks.
4. Minimal Processing — The SPV wallet is required to sign the unspent transaction outputs (UTXOs) in order to spend them. It requires the offline wallet to be able to implement ECDSA, meaning that enough processing power is required to perform elliptic curve point multiplication and compute hash functions.
5. Block Headers (optional) — The customer wallet may wish to include block headers to verify that payments to point of sale SPV wallets have been processed. It would also require storing the TXIDs and Merkle paths after interaction with a point of sale wallet.
For Alice, even the block headers are optional. Bob of course will need them.
As long as we do not change the protocol rules, there is no way to attack the system. In fact, even if a group of miners with more than 50% of the network chooses to alter the protocol, they will suddenly find that no one is spending any bitcoin on their network. Such is the nature of a split. It is not miners voting on protocol changes; there are no protocol changes.
Only miners are nodes — an important aspect of Bitcoin. It is not your software that dictates the rules and what miners can do. In fact, the consensus is purely enforced by mining. The protocol is the entire system.
It is why SPV can work and why it doesn’t on a system such as BTC. Where the protocol can change, SPV does not exist. Bitcoin allows for local validation that links to the main chain. In fact, the process is incredibly simple. All that needs to occur is for the recipient to store the transaction. If we assume that Alice and Bob seek to exchange transactions, and Bob is selling goods that Alice wishes to buy for bitcoin, then SPV can be very simple.
If Alice has maintained a copy of the transaction she was paid with and the Merkle branch, she can hand the two parts of a transaction and the respective block to Bob who can now validate and verify the entire transaction chain very simply.
Any needed rules and incentives can be enforced with this consensus mechanism.
The last line in the Bitcoin white paper is incredibly important. If you require all SPV wallets and the entire set of organisations running Bitcoin or creating transactions to upgrade, then you have an alteration to the protocol and not the rules. Here lies a major distinction.
As the last line in the white paper explains, rules and incentives that act within the bounds of the Bitcoin protocol can always be updated through the simple decision of miners who accept the proof of work chain and vote on the acceptance of valid blocks. The system acts without any further alteration of the network. Note that the conclusion very specifically says that nodes and only nodes need to vote. The white paper in section 5 is explicit in saying that a node is in fact a miner and creates blocks. All others on the network are wallets and users of the network. Both are important in the security model in that the security of the system cannot be hijacked unless the majority of the users are fooled into altering the protocol.
It in effect may be likened to software that needs to be changed in order to be compromised. That is through social engineering.
It is extremely simple to prove.
We have a logical statement; the statement is that the simple voting on rules by miners can set any rules within the protocol. Logically from here we can deduce that any rule outside of the ability for miners to vote on by rejecting transactions and blocks is also outside of the protocol. Logically, there is no other way to read the statement. Either nodes (always miners) can set rules through voting alone, or it is outside of the protocol.
We will now look at the difference in establishing rules that are outside of the protocol and hence create a system that is not Bitcoin.
The addition of changes leading to Segregated Witness required the alteration not only of how miners operate, but also the update of software used by users. Hence, it is not the mere voting by nodes, it is a replacement of the former software with something else. In fact, it is simply a different set of software.
Very simply, we can logically argue that such a change alters the protocol in such a manner that it is no longer Bitcoin. More importantly, such a form of change requires that the users of the system are duped into accepting the change. It requires a power structure. The nature of decentralisation as a term and as something in law and art is one of power decentralisation. The very argument or way used to enforce it is in itself not decentralised. In fact, the parties who are changing the protocol are not miners, they are not users, but rather a small bunch of developers. That is, a small bunch of people are dictating the course of a protocol and a financial investment. There is nothing decentralised in it at all.
This is important; people have the right to create a transaction using Bitcoin that will be valid for years potentially. It includes the ability to pre-sign partially completed transactions using nLockTime that could be allowed on the Bitcoin network years later. Such is a key aspect of Bitcoin that is destroyed in any protocol change. In fact, it is the key aspect of any system built on a time chain.
You cannot have certainty and contracting and hence you cannot have any validity on any system that allows protocol changes. Importantly, there are many protocol changes that would need to be valid for multiple years. Real-property transactions can be required to be valid for over a century. Any alteration by Bitcoin within such a time window violates the probity of contracts and property.
If users have to change software, it is an airdrop into a new system.
I’ll use two analogies here; the first one is Linux versus Microsoft.
If you have Microsoft software running on your computer, and I hand you a disk saying that all users must use the software to ensure that they maintain network connectivity, and you install it, my calling it Microsoft software does not make it so. In fact, the disk I handed you could have been a Linux install disk, and you are now mistakenly running Linux while calling it Microsoft. It is what was done to Bitcoin. There are a number of users who have installed the new protocol and think that it has any relation to Bitcoin at all.
If we now look at it from the point of view of users, one of the earliest use cases of Bitcoin was the ability to form contracts that will remain valid for years. Importantly, the way it was done in the first place required users to store files and protect the integrity of their own transactions. Using nLockTime, users could store many possible transactions that may be valid if certain events happened in the future. None of them would be added to the blockchain unless it was later valid. It could take generations. In particular, it could be something that would be valid only decades later. It allows for succession planning and even wills.
But with protocol changes, the same is no longer valid. If a transaction cannot remain valid, we have a separate system that is created. It is not an aspect of the system such as miners choosing block size or even when existing transaction script codes will be available but a radical alteration to something that changes the nature of Bitcoin itself.