If new version source exist in network, all follow?

[wsxdrfv]

If one node has new version number with some revised source, then all chain network follow it? and recognize all themselves as obsolete?

If this is true, how to preserve past balance and record?

[HeRetiK]

Nodes don't auto-update. Version numbers are ignored for the most part, as any node could fake the wrong version number. The only thing that matters is that all nodes follow the same protocol rules (eg. blocksize, block reward, etc).

If new nodes enter the network with looser protocol rules (eg. allowing larger blocks than before), old nodes will continue enforcing the tighter protocol rules, ignoring blocks that the new nodes accept into their version of the blockchain -- a hard fork occurs.

If new nodes enter the network with tighter protocol rules (eg. SegWit), old nodes will accept the new blocks even though they can't properly interpret them and the transaction history doesn't diverge -- a soft fork occurs.

Both cases only depend on the protocol rules as enforced by the respective nodes. Neither case depends on the version number or a forced upgrade.

Note that the transaction history is untouched either way -- balances are just the sum of incoming and outgoing transactions, as stored in the blockchain. New transactions may or may not get accepted into the network, but old transactions remain, thus balances are unchanged until a transaction under the new (or old) rules is made.

[AdSkull89]

If one node has new version number with some revised source, then all chain network follow it? and recognize all themselves as obsolete?

If this is true, how to preserve past balance and record?

No. Following is my ELI5:

First of all even if core repository got wiped or infected - nothing will change since auto update is deliberately not implemented in core. every individual in BTC network have it's own "voice" and "mind". Mind decides what to follow and voice decides format of communication with the rest of the network. You can create your own client that mimics currently standard mid and voice or you can break either. If enough people decide to update either of the above - rest of the network can decide to follow (this will result in soft fork) or not to follow (this will result in hard fork).

[HeRetiK]

[...] If enough people decide to update either of the above - rest of the network can decide to follow (this will result in soft fork) or not to follow (this will result in hard fork).

Soft forks / hard forks have nothing to do with whether the majority of the network is on board or not. It's a question of compatibility between the old and the new protocol rules.

A fork that is backwards-compatible is a soft fork, regardless of whether we're talking about 1% or 100% of nodes running the new software.

A fork that is not backwards-compatible is a hard fork, regardless of whether we're talking about 1% or 100% of nodes running the new software.

One practical difference lies in the likeliness of a chain split occuring. A soft fork is almost always safe, while a hard fork will almost always lead to a chain split -- unless 100% of nodes and miners are on board.


Good point that auto-update has been deliberately omitted as to allow nodes to decide on their own which version of the software to run. It's a very important design choice, giving people the right to "vote" on possible network upgrades.

[DannyHamilton]

A soft fork is almost always safe,

Not true.

Soft forks generally require a significant majority of the hash power to all run the new software.

If a significant minority of the hash power is running the new software, then the chain will fork.

If there is a nearly even split of hash power between the old and new software, then it will be a complete disaster for those running the new software. They will risk seeing transactions with many confirmations simply vanish. Miners on the new software will carry significant risk of losing revenue.

This is why soft forks generally will have a method for miners to announce in their blocks that their software has been upgraded and the software will generally have a "trigger" that requires a significant percentage of blocks to all include the announcement before the new changes take effect.

Lets look at the scenarios...


Soft fork with a significant majority of the hash power:

Miners on the new software create blocks faster than miners on the old software.  Since the change is backwards compatible, miners on the old software accept these blocks.  Since the old software is not "forward compatible", if any miner on the old software creates a block it will be ignored by all the miners on the new software.  Miners on the new software will just build on top of the most recent new-software-compatible block. Once a few new-software-compatible blocks have been created, the chain will be longer than the blocks that have been added by miners that are still running the old software.  Since the change is backwards compatible, all miners on the old software accept this new longer chain and orphan the few old-software blocks.  In this way, the new software enforces the new rules.  Miners running the old software have a HUGE incentive to upgrade to the new software, since ALL of their blocks will get orphaned, and they won't be able to earn any block rewards until they upgrade.  Continuing to mine on the old software is a HUGE waste of time, money, and resources.


Soft fork with a significant minority of the hash power:

A miner on the new software gets lucky and creates a block. Since the change is backwards compatible, all miners accept this block. Since the old-software miners have the majority of the hash power, they eventually mine a block.  All miners on the new software ignore this new block.  All miners on the old software accept this new block and build on top of it.  The miners on the old software mine several blocks on top of that.  This forms an old-software-fork.  Meanwhile, miners on the new software do not see any of these old-software blocks.  They continue to build on top of the one new-software block.  Since the old-software miners have much more hash power, their fork is always longer than the new-software fork.  Therefore, the old-software miners never switch over to the shorter new-software fork.  Meanwhile, since the new-software miners are attempting to enforce the new rule, they see the longer old-software fork as invalid and never switch over to it.  Merchants and users that continue to run the old software will ONLY see transactions that occur on the old-software fork.  Merchants and users that upgrade to the new software will ONLY see transactions that occur on the new-software fork.


Soft fork with a nearly even amounts of the hash power:

The same scenario as the "soft fork with a significant minority" EXCEPT that, due to luck, occasionally the old-software fork will grow longer than the new-software fork.  When that happens, all users, merchants, and miners that are running the new software will switch to the longer old-software fork.  All transactions that were confirmed in the new-software fork will immediately lose all their confirmations. Many of those transactions will invalid on the old-software fork and will therefore vanish.  Then eventually a miner running the new software will solve a block and another new-software fork will begin again (until the old-software fork gets lucky enough to exceed the new-software fork in length and the whole process begins again).  Additionally, miners running the new software have a HUGE incentive to downgrade to the old software, since their blocks are likely to eventually get orphaned they are likely to lose block rewards until they upgrade.  Continuing to mine on the new software is a HUGE risk of wasting time, money, and resources.

[AdSkull89]

A soft fork is almost always safe,

Not true.

Soft forks generally require a significant majority of the hash power to all run the new software.

If a significant minority of the hash power is running the new software, then the chain will fork.

If there is a nearly even split of hash power between the old and new software, then it will be a complete disaster for those running the new software. They will risk seeing transactions with many confirmations simply vanish. Miners on the new software will carry significant risk of losing revenue.

This is why soft forks generally will have a method for miners to announce in their blocks that their software has been upgraded and the software will generally have a "trigger" that requires a significant percentage of blocks to all include the announcement before the new changes take effect.

Lets look at the scenarios...




Soft fork with a significant majority of the hash power:

Miners on the new software create blocks faster than miners on the old software.  Since the change is backwards compatible, miners on the old software accept these blocks.  Since the old software is not "forward compatible", if any miner on the old software creates a block it will be ignored by all the miners on the new software.  Miners on the new software will just build on top of the most recent new-software-compatible block. Once a few new-software-compatible blocks have been created, the chain will be longer than the blocks that have been added by miners that are still running the old software.  Since the change is backwards compatible, all miners on the old software accept this new longer chain and orphan the few old-software blocks.  In this way, the new software enforces the new rules.  Miners running the old software have a HUGE incentive to upgrade to the new software, since ALL of their blocks will get orphaned, and they won't be able to earn any block rewards until they upgrade.  Continuing to mine on the old software is a HUGE waste of time, money, and resources.


Soft fork with a significant minority of the hash power:

A miner on the new software gets lucky and creates a block. Since the change is backwards compatible, all miners accept this block. Since the old-software miners have the majority of the hash power, they eventually mine a block.  All miners on the new software ignore this new block.  All miners on the old software accept this new block and build on top of it.  The miners on the old software mine several blocks on top of that.  This forms an old-software-fork.  Meanwhile, miners on the new software do not see any of these old-software blocks.  They continue to build on top of the one new-software block.  Since the old-software miners have much more hash power, their fork is always longer than the new-software fork.  Therefore, the old-software miners never switch over to the shorter new-software fork.  Meanwhile, since the new-software miners are attempting to enforce the new rule, they see the longer old-software fork as invalid and never switch over to it.  Merchants and users that continue to run the old software will ONLY see transactions that occur on the old-software fork.  Merchants and users that upgrade to the new software will ONLY see transactions that occur on the new-software fork.


Soft fork with a nearly even amounts of the hash power:

The same scenario as the "soft fork with a significant minority" EXCEPT that, due to luck, occasionally the old-software fork will grow longer than the new-software fork.  When that happens, all users, merchants, and miners that are running the new software will switch to the longer old-software fork.  All transactions that were confirmed in the new-software fork will immediately lose all their confirmations. Many of those transactions will invalid on the old-software fork and will therefore vanish.  Then eventually a miner running the new software will solve a block and another new-software fork will begin again (until the old-software fork gets lucky enough to exceed the new-software fork in length and the whole process begins again).  Additionally, miners running the new software have a HUGE incentive to downgrade to the old software, since their blocks are likely to eventually get orphaned they are likely to lose block rewards until they upgrade.  Continuing to mine on the new software is a HUGE risk of wasting time, money, and resources.

Sorry for offtopic comment, but still
Dude, seriously - I'm reading your comments and cant overestimate how useful and structured your responses are. Thank you for all the effort you put in your responses! Usually after your comment there is literally no further questions on topic left.