1. Does this imply that consensus guidelines are solely these associated to information from the chain, and any rule that’s in any method linked to data outdoors the chain (resembling comparability, subtraction, addition, or the rest with one thing from the true world) can’t be a part of consensus guidelines as a result of we are able to all understand that ‘one thing outdoors the chain’ otherwise, even when we’re completely right/trustworthy?

Sure, consensus guidelines can solely depend upon data that’s dedicated to by block hashes. Something can’t be assured to be noticed identically by each validator, at each time limit. And when consensus guidelines yield totally different outcomes for various validators, the chain can fork.

Word that it does not even want dishonesty; in any case, we solely care about trustworthy nodes behaving appropriately. To make use of the instance of real-world time, nodes can obtain blocks at totally different time limit (attributable to propagation delays, community infrastructure failures, and even simply attributable to a node synchronizing from scratch solely years later). In all these circumstances, nodes should come to the very same conclusion about which blocks are legitimate or invalid, or a fork happens.

2. Do consensus guidelines should be such that one thing is both perpetually right or perpetually incorrect, and never that it may possibly develop into right or incorrect over time (for instance, a block with a sure timestamp turns into legitimate sooner or later)? After I say perpetually, I don’t think about circumstances when consensus guidelines change.

Sure. Consider the consensus guidelines abstractly as a operate which is given as enter a whole chain of blocks (so a block with all its ancestors, not together with any blocks that have been as soon as a part of the chain however received reorganized out), and returns both “legitimate” or “invalid”. It takes no different different enter, and can’t use randomness within the course of.

3. A transaction with a locktime worth (set to a timestamp; to not block top) that has not but occurred should not be a part of the block. So far as I do know and as I’ve thought to date, this can be a consensus rule. What pursuits me is how this is usually a consensus rule when the comparability might be made with actual timestamp, which is off-chain data?

That is not right. A transaction with a locktime is in contrast towards the block timestamps, not towards real-world time.

Particularly, since BIP113, it’s in contrast towards the median of the timestamps of the 11 blocks previous the block the transaction is included in. Earlier than BIP113, the block’s personal timestamp was used.