1. Does this imply that consensus guidelines are solely these associated to information from the chain, and any rule that’s in any method related to info exterior the chain (similar to comparability, subtraction, addition, or anything with one thing from the actual world) can’t be a part of consensus guidelines as a result of we will all understand that ‘one thing exterior the chain’ in another way, even when we’re completely appropriate/sincere?

Sure, consensus guidelines can solely rely upon info 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.

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

2. Do consensus guidelines must be such that one thing is both endlessly appropriate or endlessly incorrect, and never that it will possibly turn into appropriate or incorrect over time (for instance, a block with a sure timestamp turns into legitimate sooner or later)? Once I say endlessly, I don’t think about circumstances when consensus guidelines change.

Sure. Consider the consensus guidelines abstractly as a perform which is given as enter a complete chain of blocks (so a block with all its ancestors, not together with any blocks that had 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 peak) 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 this point, this can be a consensus rule. What pursuits me is how this could be a consensus rule when the comparability can be made with actual timestamp, which is off-chain info?

That is not appropriate. 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.