All the examples of forks have used block size change that produced a hard or soft fork. What other features of the bitcoin blockchain consensus rules could be altered to produce a fork?
1 Like
Transactions that were included in a stale block are going back to the mempool. Itâs also possible that some of these transactions were already included in the other âwinningâ block
1 Like
Thank you for clarifying it
1 Like
You can do a hard Fork to change the block time, or to change mining algorithm, changing block reward, maximum supply ectâŚ
1 Like
Iâve been thinking about forks for a while. Iâm not sure that I like the definition given, that soft forks occur when previously valid blocks are now invalid and hard forks occur when previously invalid blocks are now valid. It seems too simplistic, but with the examples of block size it does work. Looking for comments @Fabrice, @filip, @ivan.
It matters which of the consensus rules are changed and perhaps how they are changed to be able to call a block valid or invalid. Strictly, if a block conforms to all the rules of consensus it is valid. Changing the rules may or may not cause a fork in the chain, but the important part is the outcome and where the hash power is going.
The examples given in the course use block size to illustrate the concept of soft and hard forks. That makes sense, but some clarification is needed to fully understand.
Itâs misleading to say that forks are either an expansion or contraction of the rules. That construct works fine for altering block size but not for altering other features of consensus like change in mining algorithm, changing block reward, maximum supply, etc. (Thank you Fabrice.)
Soft forks donât always fit within the previous ruleset. They continue the same chain with new features or maybe even security updates, so the protocol can change significantly and still result in a soft fork.
A more complete definition of forks would include the outcome of the change. Is the new chain rule set backwards compatible? Yes, if youâre only changing the reward structure so that say, miners give up a percentage of their winnings to a treasury that will assure continuation of the project. Soft forks would be backwards compatible.
Are new and different coins created? Certainly yes, with a purposeful hardfork like the increase in block size that produced bitcoinCash from bitcoin, but not so with a purposeful hardfork when changing mining algorithms to ward off ASICs from the chain as is regularly accomplished in Monero or Ravencoin.
The simple definition of a blockchain fork is when we have two or more different blocks at the same block height. Usually, forks will resolve via the existing rule set as miners adhere to the longest chain rule.
Perhaps purpose could be added to the definition of soft or hard forks?
When itâs desired to create a new chain for whatever reason, belief or experimental purpose, the consensus rules would be changed on purpose to split the chain. New rules would disallow blocks found by the old rules, or, previously valid blocks become invalid. That works for absolute rule changes like using a new mining algorithm or changing the block reward structure, but not for decreasing the block size.
When the purpose of updating consensus rules is to carry on and not cause a chain split, the fork might be called a soft fork. The definition of a soft fork, where previously valid blocks are now invalid, works for decreasing block size, but not so for changing the mining algorithm or updating the block reward structure as those things didnât yet exist.
However, there have been protocol updates that force a miner to update in order to keep mining. The old rules simply wouldnât work. That would be a hard fork, but not a new chain and no new coins would be produced. This happened with ZCash and its progeny like Horizen or Komodo when applying Sapling upgrade, an update that vastly improved the shielded transaction efficiency.
My fork definitions so farâŚ
Blockchain fork = chain with more than one block at the same block height
Soft fork = an update to consensus rules making previously valid blocks invalid, that is backward-compatible, and does not result in a chain split.
Hard fork = an update to consensus rules making previously invalid blocks valid, that is not backward-compatible, and may or may not result in a chain split.
Do we just need to add the backward-compatibility factor to the definition to clarify the fork types?
1 Like
Hi Bette,
Thanks for a great addition to the fork lecture. I think you have understood all of this very well, so good job!!
I can understand that the definition might not be intuitive at first, but I find it to be a quite complete definition. It might not always be the best lens to view updates, but we also do need a pure technical definition.
Strictly, if a block conforms to all the rules of consensus it is valid. Changing the rules may or may not cause a fork in the chain, but the important part is the outcome and where the hash power is going.
This is true. But, here we are talking about a change in the actual rules, not just judging if a block conforms to the rules or not. We also need to separate the chain split from the soft/hard fork software update. We can have a hard fork without a chain split, as long as everyone upgrades. Itâs very confusingâŚ
Soft forks donât always fit within the previous ruleset. They continue the same chain with new features or maybe even security updates, so the protocol can change significantly and still result in a soft fork.
Well, this also depends if weâre talking about the software update, that can be either a soft or hard fork update, or the actual chain split. If we have a software update that doesnât fit within the previous rule set, it is by definition a hard fork update, because old nodes would not accept blocks produced with the new rules. This doesnât mean that the hard fork software update would result in a chain split.
Itâs actually important to differentiate between soft and hard fork updates, and not only what they result in (chainsplit or not). Because when we release a software update, itâs vital to understand if we need 100% of the nodes to upgrade or only a majority.
If we have a hard fork update (exp of ruleset), 100% need to update, otherwise we have a chainsplit.
If we have a soft fork update (contr or no change in ruleset), only a majority need to update to keep on the same chain.
So we need a way to define the change in the software itself, without knowing the end result.
However, there have been protocol updates that force a miner to update in order to keep mining. The old rules simply wouldnât work.
Iâm not sure what you mean here. No one can force a miner to upgrade. I can always continue to mine with the old software even if all the other nodes switch. Sure, I would be the only one running the old blockchain, but it would still work. This would happen when we deploy a hard fork update and someone chooses not to upgrade. This is very much what happened with Ethereum Classic for example.
2 Likes
Thank you so much for your clarifications. Youâre right, itâs confusing! I know I will refer to this post again in future.
For the last part I was talking about a miner that wanted to keep on the same/original chain, so they would have to update to continue mining it with a hard fork. Nice example with ETC!
Please can you tell me how a node can verify a transaction when in it is encrypted?
Hi Filip,
On the last video on this topic you have mentioned that: âSoft forks cause no chain splits in most casesâ. Could you please elaborate on that? And explain any situation that soft forks might have caused a chain split?
Really enjoy those lectures.
Many thanks,
Diogo Fernandes
1 Like
Soft forks are backwards compatible and doesnât cause a chainsplit. Users need to vote to activate a soft fork. But there is always a possibility that some part of the community doesnât want this to happen and chooses to do a hard Fork. Like on August 2017 when bitcoin Cash forked from Bitcoin.
@filip Hello, I do have a question about slate blocks. concerning the block reward, when exactly does the miner receive the block reward? at the exact time a block is added to the blockchain?
If yes, then when a accidental fork happens, who gets the block reward? if both gets it, then the block that becomes the stale just looses the block reward?
How does all of this happens?
Thank you very much.
What happens to the stale blocks that are disregarded, do they go back to the mempool as tx?
When a miner successfully mines a block, there is a coinbase transaction of blockreward +all transaction feeâs.
this transaction is not spendable (timelock) for 100blocks in case it would become a stale block.
1 Like
Yes, all transactions that are not included in the âwinningâ block will return to the mempool
Thanks looking forward to learning and understanding more as Iâm really enjoying courses very much. The format is great and easier to retain with quizzes after and asking questions and getting good responses.
1 Like
Thatâs interesting, good to know. Thank you
Hello Filip ! I have a question about soft forks. Letâs say a miner produces a 0,2 mB block. If less than 50% of the network agrees with the update (in other words if a fork occurs), where this block will be appended since it fits with both the previous and new rules ? Will it be on both ? Thank you so much and take care !
Yes, on the same blockchain, because this block is still valid with previous consensus rules. Only hard forks that have blocks that are not valid with previous consensus rules will split into 2 blockchains
1 Like
Thanks a lot ! So have another question about forks in general. How they occur ? I mean what is the origin of an update ? Thank you so much !
Everyone can fork bitcoin by changing consensus rules. But you need enough miners that want to mine that particular blockchain. Otherwise it would be easy to hack (51% attack)