How each node discriminate legitimate peers?

[wsxdrfv]

Bitcoin is constantly updated, so client also changed.

So lets say there 5 nodes,

A is version 0.1

B is version 0.11

C is version 0.15

D is version 0.16 but changed by local person without bad intention but just small test

E is version 0.16 but changed by local person with bad intention for his profit


So how each nodes can detect D and E and deny them?

What changes is reason for denial? Every change even tiny one like image modification or just add comment to script is also be recognized by other nodes for different revised node?

Then, how A, B, C each other recognize each others are legitimate updated nodes by official?

[1713894525]

1713894525

[1713894525]

1713894525

[1713894525]

1713894525

[1713894525]

1713894525

[DannyHamilton]

There are no "legitimate" peers or "not legitimate" peers.

Anybody can make any change they want.  There is no "official" software.

Clients will accept any transactions and any blocks that do not violate the consensus rules. It doesn't matter what software created the transaction or the block.  If a client is connected to a peer and the transactions or blocks from that peer are invalid, then the peer gets disconnected and blocked.  If the transactions or blocks from that peer are valid, then the peer is not disconnected and not blocked.

So, D will never be denied (as long as the small test does not create invalid transactions or blocks), and E will also not be denied until the person creates and sends an invalid transaction or block.

[Anti-Cen]

Anybody can make any change they want.  There is no "official" software.

I addressed this point but apparently it was deemed off topic and got deleted

[wsxdrfv]

There are no "legitimate" peers or "not legitimate" peers.

Anybody can make any change they want.  There is no "official" software.

Clients will accept any transactions and any blocks that do not violate the consensus rules. It doesn't matter what software created the transaction or the block.  If a client is connected to a peer and the transactions or blocks from that peer are invalid, then the peer gets disconnected and blocked.  If the transactions or blocks from that peer are valid, then the peer is not disconnected and not blocked.

So, D will never be denied (as long as the small test does not create invalid transactions or blocks), and E will also not be denied until the person creates and sends an invalid transaction or block.

Thanks. Then what factors divide "valid" / "invalid" transaction and blocks?

[DannyHamilton]

Thanks. Then what factors divide "valid" / "invalid" transaction and blocks?

The consensus rules implemented in the client software.

For example...

Any transaction such that the sum of the values of the outputs is greater than the sum of the values of the inputs, is an invalid transaction.
Any transaction such that the outputs being spent by the inputs don't exist, is an invalid transaction.
Any transaction such that the concatenation of the Txin-script and the Txout-script don't resolve successfully, is an invalid transaction.

Any block which contains an invalid transaction, is an invalid block.
Any block which does not result in a hash value that is lower than the difficulty target when hashed with SHA256d, is an invalid block.
Any block which has a timestamp outside the allowed range, is an invalid block.
Any block which pays to large of a block reward, is an invalid block.
Any block that exceeds the block size (or block weight) limits, is an invalid block.
Any block that does not have a previous block hash which matches an existing block in the blockchain, is an invalid block.

I'm sure I'm overlooking some rules, but those are the ones that immediately come to mind.

[wsxdrfv]

Thanks. Then what factors divide "valid" / "invalid" transaction and blocks?

I'm sure I'm overlooking some rules, but those are the ones that immediately come to mind.

Thanks, then what if some major group of developers want to change those [consensus]?

Is that become so called Hardfork?

[DannyHamilton]

Thanks, then what if some major group of developers want to change those consensus?

Is that become so called Hardfork?

If they want to change the rules in a way that old versions of the software will still accept the transactions or blocks, then it is a soft fork.

If they want to change the rules in a way that old versions of the software will NOT accept the transactions or blocks, then it is a hard fork.

For example...

If a block WAS limited to a maximum of 1 megabyte, and the new change limits it to a maximum of a half megabyte, then it is a soft fork. This is because a half megabyte block is still valid to the old software (it is still less than 1 megabyte). Since the blocks that are created by the new software are still accepted by the old software, you only need 50% or more of the hash power to switch to the new rules. Everyone will accept the new blocks, and any miners that create blocks bigger than the new rule will have their blocks rejected.  Since the new rules are run by more than 50% of the hash power, their chain will remain longest, and any chain created by someone with the old software will have their blocks orphaned.

If a block WAS limited to a maximum of 1 megabyte, and the new change limits it to a maximum of a 2 megabytes, then it is a hard fork. This is because a 2 megabyte block is NOT valid to the old software (it is more than 1 megabyte). Since the blocks that are created by the new software are rejected by the old software, you need everyone (miners, peer-nodes, merchants, exchanges, users, etc) to ALL switch to the new rules. If anyone continues to run the old software they will reject every bigger block and will operate on their own chain that does not include any of those blocks.The chain will fork and those running the new software will only see the new bigger blocks while those running the old software will only see the smaller blocks that are created by any miners that don't switch to the new software.

[wsxdrfv]

Perfect, then what is 'consensus'? what is not?