- Does this imply that consensus guidelines are solely these associated to information from the chain, and any rule that’s in any approach linked to data exterior 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 exterior the chain’ in a different way, even when we’re solely appropriate/sincere?
Sure, consensus guidelines can solely rely upon data that’s dedicated to by block hashes. Something can’t be assured to be noticed identically by each validator, at each cut-off date. And when consensus guidelines yield totally different outcomes for various validators, the chain can fork.
Observe that it would not even want dishonesty; in spite of everything, we solely care about sincere nodes behaving accurately. To make use of the instance of real-world time, nodes can obtain blocks at totally different cut-off date (because of propagation delays, community infrastructure failures, and even simply because of a node synchronizing from scratch solely years later). In all these instances, nodes should come to the very same conclusion at each cut-off date about which blocks are legitimate or invalid, or a fork happens.
- Do consensus guidelines must be such that one thing is both perpetually appropriate or perpetually incorrect, and never that it may well develop into appropriate or incorrect over time (for instance, a block with a sure timestamp turns into legitimate sooner or later)? Once I say perpetually, I don’t take into account instances 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 acquired reorganized out), and returns both “legitimate” or “invalid”. It takes no different different enter, and can’t use randomness within the course of.
- 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 up to now, it is 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 appropriate. A transaction with a locktime is in contrast in opposition to the block timestamps, not in opposition to real-world time.
Particularly, since BIP113, it’s in contrast in opposition to 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.
