- Does this mean that consensus rules are only those related to data from the chain, and any rule that is in any way connected to information outside the chain (such as comparison, subtraction, addition, or anything else with something from the real world) cannot be part of consensus rules because we can all perceive that ‘something outside the chain’ differently, even if we are entirely correct/honest?
Yes, consensus rules can only depend on information that is committed to by block hashes. Anything cannot be guaranteed to be observed identically by every validator, at every point in time. And when consensus rules yield different results for different validators, the chain can fork.
Note that it doesn’t even need dishonesty; after all, we only care about honest nodes behaving correctly. To use the example of real-world time, nodes can receive blocks at different point in time (due to propagation delays, network infrastructure failures, or even just due to a node synchronizing from scratch only years later). In all these cases, nodes must come to the exact same conclusion at every point in time about which blocks are valid or invalid, or a fork occurs.
- Do consensus rules have to be such that something is either forever correct or forever incorrect, and not that it can become correct or incorrect over time (for example, a block with a certain timestamp becomes valid at some point)? When I say forever, I do not consider cases when consensus rules change.
Yes. Think of the consensus rules abstractly as a function which is given as input an entire chain of blocks (so a block with all its ancestors, not including any blocks that were once part of the chain but got reorganized out), and returns either “valid” or “invalid”. It takes no other other input, and cannot use randomness in the process.
- A transaction with a locktime value (set to a timestamp; not to block height) that has not yet occurred must not be part of the block. As far as I know and as I have thought so far, this is a consensus rule. What interests me is how this can be a consensus rule when the comparison will be made with real timestamp, which is off-chain information?
That’s not correct. A transaction with a locktime is compared against the block timestamps, not against real-world time.
Specifically, since BIP113, it is compared against the median of the timestamps of the 11 blocks preceding the block the transaction is included in. Before BIP113, the block’s own timestamp was used.
