Bitcoin is all about incentives
There are people who try and tell you that Bitcoin is not about incentives or economics. The structure of Bitcoin is one that allows competition to determine a stable monetary system. Miners (nodes) have skin in the game unlike developers, and thus, are in competition for the block reward and transaction fees. The result is they will seek to maintain the protocol and not to debase and alter the currency.
Bitcoin is pseudonymous as it is about honest money. Private has to be traceable. It is not drug money, it is not money for bucket shops and it is not money for crime.
The root problem with conventional currency is all the trust that’s required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.
These people who tell you Bitcoin is not built on incentives are wrong. Worse, most of these people seek to intentionally deceive others. Just as the central bank must be trusted not to debase the currency, we need a system that does not allow developers to become technocrats thinking they are smarter than the market. Just as the history of fiat currencies is full of breaches of that trust, so is the history of promises from technocrats.
Understand that in this system, it is not only miners, but a user who has a choice. There are choices in all aspects of life. In Bitcoin, the system is one based on incentives. Both miners and users have incentives, and even if a dishonest miner seeks to radically alter the protocol and reduce its monetary stability, the incentives are able to make this fail. A user has a choice as they would need to decide to risk a transaction with an invalid (on one chain) OP_CODE.
The incentive can also be funded with transaction fees.
This aspect is important — as I will demonstrate in this post.
OP_CODES are not supposed to be arbitrarily added on a developer whim. We will explain how miners can profit from ensuring this does not occur.
Bitcoin is an economic system, an incentive system. This is what many are still slow to learn.
The incentive may help encourage nodes to stay honest.
If greedy attackers such as Bitmain and Bitcoin.com who seek to drastically alter the protocol are able to assemble more CPU power than all the honest nodes, they would have to choose between using it to defraud people by stealing back their payments, or using it to generate new coins. The
system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.
In this instance, if the miner seeks to split the chain, a temporary fork that they want to try and make permanent, such as through the use of DSV (OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY), the honest miners can treat the invalid OP_Codes as a fee. This remains within the bounds of what Bitcoin was designed to be. It is sound money that uses incentives which all ensure that the honest miners are aligned with maintaining the stability of the system.
So, any amount sent to deliberately attack the chain moves from ABC to SV. That is, the amount transacted on ABC nodes using invalid transactions will be a miner subsidy to incentivise good behaviour.
Note: This is a single example from the multiple changes made in ABC to radically alter the nature of Bitcoin.
In this example, if a dishonest miner seeks to add an OP_CODE to intentionally split the chain, they are now creating a fee structure for the honest chain.
One answer is to incentivise good code and a stable protocol. Bitcoin has been around for 10 years. In the early days, we could expect errors and mistakes, and handling errors would be the same as any other issue where you fail as simply as possible. This in Bitcoin was to effectively ignore the script for some time.
A better way is to add the incentives fully. Most are in place, but, some developers have found ways to bypass these controls and try to alter the base protocol radically. To ensure that dishonest miners and developers do not seek to alter the codebase, we add an incentive structure to test and align the development towards a stable protocol. In order to do this, we use the structure that was derived in Bitcoin 0.1. We allow the bad transactions to be used as an incentive. That is, rather than rejecting these, we allow them to be used as a miner incentive, a fee.
If developers add an unauthorised OP_CODE, it is to be treated as a miner fee. The honest miners are paid to take the value in the chain that does not alter the structure of Bitcoin, making the system more stable and resilient.
No OP_CODES that have been defined in the original version of Bitcoin would be altered. It would stop the reckless experimentation with what is designed to be sound money.
Let us investigate a split.
We will say that Chain A is (SV) and Chain B is (ABC) — where ABC seeks to help dishonest miners in altering the protocol and adding subsidies to make sidechains and other additions cheaper, allowing the theft of miner fees and a loss of control by miners.
In each of these chains, we would see no replay protection. A standard transaction would be valid on both. But, the dishonest miners could seek to divide the chain with an invalid OP_CODE (such as DSV).
The BCH(SV) chain would then see all valid BCH(SV) and BCH(ABC) standard transactions whilst not seeing those on BCH(ABC) that have intentionally injected DSV into a transaction. The BCH(ABC) chain would have included DSV allowing them to send a double spend keeping their money in a DSV transaction but moving the same address later on the BCH(SV) chain allowing them to have their money and spend it, too. A fraud. There is no other way to say it.
Well, this is easily countered using the original incentives.
The BCH(SV) chain can send any transaction that includes a DSV illegal OP_CODE (this is with DSV) in the transaction to the first miner to discover a block as a miner fee. In this, if and when the dishonest miners on the BCH(ABC) chain seek to send an invalid OP_CODE to split the chain, they are really giving away any money they have on the BCH(SV) chain to the miners that are mining on the BCH(SV) chain. That is, the dishonest miners/attackers would need to subsidise the honest miners seeking to maintain the original Bitcoin protocol.
This incentivises miners to mine on the BCH(SV) chain. In fact, it can make mining the SV chain 100s of times more profitable if you are an honest miner.
When we have developers actively seeking to subvert the Bitcoin protocol, this is something we need to stop in its tracks. Bitcoin is not an experiment, it is about stable money.
Using DSV when users do not choose.
Some wallets such as Bitcoin.com have signalled that they will use DSV in all their transactions. This is a signal that Bitcoin.com seeks to actively defraud their users leaving them liable (Bitcoin.com) for any losses those users experience. This remains problematic as we do not know if those users will be able to recover funds that Bitcoin.com plans to burn without user permission.
In the BCH(SV) chain, as per our example, have not altered or added this new rule and illegitimate OP_CODE. To send a transaction to a new address with DSV embedded in a transaction is not a simple act. It is not like sending a standard transaction. Where the user has not agreed to the use of this dishonest OP_CODE addition, the user would have the right to recover against the exchange or wallet doing this in law.
You see, Bitcoin works within the law. The aim of some players (such as Bitmain and Bitcoin.com), to make Bitcoin into a system that acts outside of the legal system, changes it from what Bitcoin was designed to be: a stable money and contractual system based on P2P electronic cash.
If a user sends money, and sells it on the BCH(ABC) chain, without adding a dishonest OP_CODE change, they will lose nothing. The transaction will be valid and accepted on both chains. The same applies to the BCH(SV) chain. The only loss is if the user sells on the BCH(ABC) chain, and here, the change needs to be good enough and desired enough by miners to ensure that a split does not occur (such a change would include a vulnerability with a hash function or a signature algorithm that threatened stability to the chain if not updated).
Change can occur, but, it is expensive and difficult. This means, the money supply is stable, it is sound.
Of course, this is and was the goal of Bitcoin. Bitcoin is not about “social consensus” or some other collectivist dream, it is capitalist money designed to follow the vision of Mises and Hayek. That is, sound money that cannot be debased.
The worst thing would be to replace the central banks and government with developer technocrats. In this, we take a few monetary economists with no idea, and replace them with far more clueless code monkeys — sorry, that is exactly what Bitcoin was designed to stop.
In Bitcoin, we have an incentive structure such that miners (nodes) are rewarded to allow stable money to be maintained.
Developers in this model are rewarded to create better code — by miners. Developers are able to gain funding in this capitalist system by developing code that allows individual miners to compete more effectively — code that forces more and more competition in the Red Queen Game that is Bitcoin.
This is the division in Bitcoin. Not a race to play (experiment as a developer without idea or clues) more and more. A system that is stable. Gold was able to be manipulated, as the way to trust gold was to have it minted. If it was minted; you needed to trust the mint and they could debase it. Bitcoin, when controlled in competition by miners, cannot be easily manipulated, and as it scales, it will be more and more difficult to alter, to debase.
In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes.
The goal was never to find ways to make a system that seeks more and more strange boondoggles to pivot into, it is P2P electronic cash. As Bitcoin grows and as the mining reward diminishes, the miners need to receive more fees. If others want to pay for fees in alternate methods to allow the original version of Bitcoin to survive, we have a method to allow for this.
We should always allow at least some free transactions, and what better way is there right now than to have the dishonest miners and developers start to fund it first.
Users can choose
Users on Bitcoin.com can choose to have a transaction sent using DSV. If this is not forced, the user will select that they want to give up any value on the BCH(SV) chain, and select the BCH(ABC) chain. If the user does not want to have anything to do with SV, they are free to choose to give up all value in that chain. They can sell out, and use fiat or any other altcoin. That is the nature of fair competition.
In doing so freely and paying that value to miners on the BCH(SV) chain they are signalling they do not want to be a part of the original vision for Bitcoin.
If they FREELY choose to do this, that is their decision.
If people are FORCED by wallets such as Bitcoin.com to do this, then they have a valid claim against Bitcoin.com for the losses. In effect, in any contentious fork, the value of the chain is split against the risk of either chain losing. Without replay protection, only one chain wins, the other will in time end. So, if the value is split 50/50, the loss in forcing a client to a particular branch will be 50% of the funds.
Consequently, no matter what we have as an outcome, or what chain prevails (secret, it is SV), the wallet will have taken from the owner of the address an amount equal to the risk premium or more.
In the case of a company doing this (such as Bitmain), the shareholders would have an action against the directors.
The incentive can also be funded with transaction fees.
As a protocol change such as DSV seeks to find holes in the original code, we can allow them to choose to lose money if they dishonestly seek to split the network. If a standard transaction is sent, any miner will accept it. On the other hand, if a dishonest miner seeks to try and split the network, we can use incentives to have them see the folly of their way and hopefully work on the main Bitcoin chain. If they do not, the incentive structure is one that drains all value from their fork allowing it to wither.
Miners would have a lottery in a split game. As soon as a malicious and dishonest miner seeks to run code that is designed to split the network, the miners have a lotto ticket for money on the honest chain.
The incentive can also be funded with transaction fees. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.
Well, as the OP_CODE is not a valid means to redeem, this basically means that we have an output that they want to send to miners. A fee.
The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU proof-of-worker than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins.
The miners will need to choose: do they risk all they have in a split sending to DSV where the miners can choose to have this as a fee? Or, will they remain honest and build a stable platform?
This adds an incentive for nodes to support the network.
If you’re having trouble with the inflation issue, it’s easy to tweak it for transaction fees instead. It’s as simple as this: let the output value from any transaction be 1 cent less than the input value. Either the client software automatically writes transactions for 1 cent more than the intended payment value, or it could come out of the payee’s side. The incentive value when a node finds a proof-of-work for a block could be the total of the fees in the block.
And, there is no reason to have users send DSV in a transaction, it is not a part of the protocol. As such, it is a choice the user makes. If they send it, they make the decision to fund miners on the honest chain with the value in the transaction.
There will be transaction fees, so nodes will have an incentive to receive and include all the transactions they can. Nodes will eventually be compensated by transaction fees alone when the total coins created hits the pre-determined ceiling.
As the whitepaper states, a miner and developer, even a dishonest one ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.
Bitcoin is purely incentive based.
If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.
As long as Bitcoin is controlled by honest miners, those not seeking to change the protocol for personal reason, we recommend strongly that you avoid using any new OP_CODES during the hash battle. nChain are dedicated to ensuring that the original Bitcoin remains as close to version 0.1 as is possible. This is the economic incentive structure to ensure that Bitcoin is sound money.
If you are using a standard cash transaction in this time, one with no new changes, then you should be fine on most wallets. The Money Button has a great write-up here. If you follow this advice, you should be fine for most things.
This is my personal post. Details will follow. Take care.
We will not give up. The real Bitcoin is worth fighting for. If a miner seeks to attack by injecting protocol changes designed to alter the nature of Bitcoin, the miners will be incentivised to mine SV as they are rewarded on this chain.
Please note further that DSV transactions can be sent to the BCH(SV) chain using P2SH. In this, a transaction will be included in the SV chain as it is now, but the funds will become unspendable. That is, they are burnt and lost forever. We see the use of these funds to provide enticement for miners to protect the protocol. Either way, the user has lost them, but, earmarking these for miners can allow them to stay in circulation and provide value.