Thanks. I’ll study your answer some more. Much appreciated!
1 Like
I’m assuming here you are talking about some of the nodes not updating for a soft fork…
If you are, then maybe this will help:
= a shrinking/tightening of the rule set.
So, the nodes which choose not to update (for whatever reason) will still be able to validate ALL transactions and new blocks which they receive from the updated nodes — because the updated protocol “fits within” the old one. I think this is what @Fabrice means by:
However, with transactions and new blocks which are valid according to the old rules but don’t “fit within” the tighter/stricter rule set of the updated nodes, if these are propogated throughout the network by the non-updated nodes and then received by the updated nodes, the updated nodes will treat them as invalid and reject them — only other non-updated nodes will accept them. Due to consensus, this means that as long as more than 50% of the miners update, then only blocks that are valid according to the updated protocol will end up in the longest chain. Non-updated nodes can still mine or operate as non-mining nodes within the same network, but any mining nodes that don’t update will immediately become uncompetitive (because proportionately, less of their mined blocks will end up being confirmed within the longest chain). So, due to competition, miners will be incentivised to eventually update to the new protocol, whether or not they agree to it in principle — which I think could be seen as either an advantage or disadvantage of a soft fork, depending on whether you (a) want to promote adoption of the update without splitting the network, or (b) are against the update yet forced to implement it in order to remain competitive.
I wrestled with the logic of all this for a while, myself. Hopefully, these extra comments, building on what @Fabrice has already posted, will also help… 
11 Likes
Thanks for the response. There are a number of questions which arise but they may be answered in the BTC programming course.
So at least if i write them down it should be useful.
Does the 50+% adoption of new protocol precede longest chain production (as in: cause it) or do a minority of participating nodes create longer chains before the 50+% adoption occurs?
I suppose what I’m asking is: Do 50+% of participants need to adopt the new protocols before launch?
2 Likes
No,
In a soft fork, you just start to have 2 types of nodes (if not everyone upgrades) . The updated nodes with ‘tighter’ rules and the others with the previous ‘normal’ consensus rules. The nodes who didn’t update, still allows everything. Only the updated nodes have ‘tighter’ rules and have more restrictions to validate and mine.
2 Likes
My understanding is the answer to both is actually YES if…
= >50% of the network’s total hashing power.
I think this is also correct, and that you could theoretically launch an update this way, but that you would still need mining nodes with >50% of the total hashing power to update before the soft fork would actually occur, and before the longest chain would start to only include blocks mined according to the new protocol (i.e. a successful update).
I say theoretically, because I would have thought that in practice, a soft-fork update wouldn’t actually be activated until at least a majority (by a comfortable margin) of the miners were on board (and probably a large number of non-mining nodes as well), in order to account for any slippage, avoid unnecessary implementation costs and disruption — not to mention a public relations failure. I also think that:
The smaller the majority (of hashing power) ⟶ the greater the number of stale blocks created…
…leading to a much less certain and “messier” implementation.
The actual implementation of the SegWit soft-fork was extremely complicated and convoluted, with various different activation methods (both miner-activated and user-actived) discussed and attempted, but from what I can gather (bearing in mind it’s a very deep 
this one 
), an overriding common theme was the need for adoption by a super-majority of the hashing power (I’ve seen both 95% and 80% mentioned in articles).
However, if by participants we mean all of the network’s nodes (mining and non-mining), then I guess you could have a situation where <50% of the total number of participating nodes update, but >50% of the hashing power updates, and which would still result in a successful soft fork e.g.
Let’s say there are 100 nodes in the whole network;
60 of these are mining nodes;
18 mining nodes each have 4% of the total hashing power; all of these nodes update;
Only 10 non-mining nodes update (i.e. only 25% of non-mining nodes);
All 72 remaining nodes (42 mining, 30 non-mining) continue operating according to the legacy protocol.
RESULT:
A large majority (72%) of the total participating nodes don’t update (only 28% update).
Only 30% of the mining nodes update, but between them they have 72% of the network’s total hashing power. Therefore, the soft fork is successfully implemented.
5 Likes
I’m going to research a bit further on it.
I have found a great article about it.
https://medium.com/@lightcoin/the-differences-between-a-hard-fork-a-soft-fork-and-a-chain-split-and-what-they-mean-for-the-769273f358c9
3 Likes
what I understand now is that for a softfork you need a majority of the miners to approve.
there is also a difference between miner or user activated soft fork.
Hey! I’m glad we ended up coming to the same conclusion.
Yes, I’d noticed this User-Activated Soft Fork too, while reading about SegWit. I also saw it mentioned in the Medium article you found. I’m starting to understand it — it seems to be a way of the non-mining nodes pressurising reluctant miners to eventually update, in a kind of long and drawn-out soft-fork process — but I definitely want to find out more about how it works in practice.
I also didn’t fully understand what a sustained chain split or a blockchain reorganisation are, which are also mentioned in the article — although they seem to be a way of forcing the implementation of the updated protocol with only a minority of miners onboard (having realised that a soft fork isn’t going to happen).
Nothing is ever straight-forward or clear-cut is it? 
2 Likes
When there is a hard fork what percentage is needed to decide? 51% Who does the programming, who decides and makes sure it’s programmed correctly?
Can it be forked down the like, BTC then Bitcoin cash then bitcoin cash can then fork again?
Does this effect the supply of the original BTC? When it forks how is the supply determined? Does it mirror BTC then gets mined at a different rate or still 10 minute blocks.
Thanks in Advance. 
Thanks Flip, after reviewing your video concerning Updates & Forks, I have a better understanding. Even more so, the questions and discussions in the forum has also benefitted in my understanding.
4 Likes
A hard fork is when nodes of the newest version of a blockchain no longer accept the newest version of the blockchain; which creates a permanent divergence from the previous version of the blockchain. Adding a new rule to the code essentially creates a fork in the blockchain: one path follows the new, upgraded blockchain, and the other path continues along the old path. Generally, after a short time, those on the old chain will realize that their version of the blockchain is outdated or irrelevant and quickly upgrade to the latest version. You don’t need a certain percentage to fork.
you can fork the bitcoin blockchain on a certain blockheight and it will basically copy the history and utxo’s ect. so If you own 5 bitcoin before the fork happened, you will also have 5 bitcoin of the new forked version of the Blockchain. If you didn’t changed rules on the mining part, The difficulty will adjust to have an approximately of 10min blocktime.
3 Likes
Just to be clear for @TokyoCrypto, I think you meant to say:
A hard fork is when nodes of the legacy version (i.e. prior to the update) of a blockchain no longer accept the newest version of the blockchain (i.e. the one that’s implemented the new protocol with the expanded rule set)
I think this would depend on the % that implement the hard fork and also on other market factors. I suspect that if the vast majority implement the hard fork, then what you say is much more likely to happen. However, when Bitcoin Cash hard-forked, Bitcoin didn’t end up deciding that it was no longer relevant and outdated…
Yes, that sounds right — however, I think the %s will affect what happens after the hard fork, and the likely success of either chain.
In terms of % adoption, I think the important thing to note is that with a hard fork 100% of the miners need to implement the new rules in order to prevent a permanent fork in the main chain. However, with a soft fork, a permanent fork can be avoided with <100%, and my understanding is that anything >50% in terms of miner adoption is more likely to prevent a permanent split than lead to one. The Medium article you linked to here was a very interesting read in terms of how different % adoption splits affect the outcome of both types of forks, and definitely illustrates that the actual outcome depends on several different factors and community decisions.
I would assume that, theoretically, there is no limit to the number of forks and sub-forks that can occur. However, I imagine that practical and economic/market factors limit this in practice, as continual splits would inevitably mean that some of the sub-chains are out-competed and become economically unviable.
I’ve often wondered how this works in practice. So, when there is a hard fork, do your pre-fork holdings (in terms of units of crypto) automatically get replicated for the new chain, and then it is left to market economics to determine the price of both cryptocurrencies (meaning that you may have double the units, but probably not double the value — or at least to start off with?
3 Likes
I sold my BCH after the fork in August 2017. Using my 12 words of my hardware wallet (bip39 mnemonic seed) I could acces them. But because I compromised my 12 words online, I generated new keys on my hardware wallet and transferred my bitcoin to a new safe location. Supply and demand + adoption on exchange gives it value I guess. Bitcoin cash was about 600dollars and BTC 1000 dollars. We all know what happend next. The community decided wich from these two is Bitcoin.
5 Likes
If you sold your BCH and bought BTC with the proceeds at $1k per BTC, then you did very well, as the price of BTC was around $4k in August/Sept 2017!! Somehow, though, I suspect you just sold your BCH and didn’t exchange it for more BTC — if so, what a shame, after what happened next!!
1 Like
I swapped it with a BTC/BCH pair, I have no clue how much profit I had, I just wanted to get rid of it for more BTC. If you had bitcoin where you own the keys at August 1, 2017 you should be able to claim your BCH tokens (even today).
I didn’t own BCH when BitcoinSV forked from it.
ps. I didn’t owned that much BTC, I’m a simple guy 
Dollar cost average is the best strategy, buy bitcoin once and a while (mainly the dips) and learn about it as much as possible.
3 Likes
Hi Filip
Can you please tell me whether the block consensus rules is vetted before mining or after mining but before they are appended to the chain ?
Thanks
If miners broadcast a block to the bitcoin network, It has to make sure that the block is valid according to the consensus rules. Otherwise the block will be rejected.
Points 1 and 2 in the following linked post might be helpful…
Validation of blocks according to the rules is carried out by the nodes when they receive the new blocks, after they have been mined and distributed throughout the network, and before they are appended to the chain.
However, as @Fabrice suggests in his post, it is also in the best interests of the miner…
…and if the block is rejected by the nodes when they receive it, then the miner won’t receive the block reward.
3 Likes
Hi Ziomanzo
It looks from your feedback that before the mined block is adopted by the network, the nodes make sure that the consensus rule has been followed. Actually, I was initially under the impression that miners would have checked the consensus rule first before mining otherwise there would be so much hashing power wasted to find later that the block is non compliant. Thanks
Regards
Eric
Hi jon_m
Wow, what a thorough research on this matter! Appreciate your respond. Now I am clear but as I have indicated to @Fabrice I was under the impression initially that the checking on consensus rule was done previous to mining because otherwise a lot of wasted hashing power if later found out to be invalid block.
Thanks
Eric
2 Likes