3

In answer to one of my previous questions, Pieter Wuille wrote that the +2h rule for block acceptance cannot be a consensus rule because it is based on comparing block timestamp with information that is outside the chain (real-world timestamp). Cite:

And since real-world time is necessarily external to the chain, any rule that provides this relation cannot be a consensus rule. It's a network rule, crucial for Bitcoin's security, but it relies on information that is not part of the chain itself.

  1. 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?

  2. 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.

  3. 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?

LeaBit
  • 930
  • 1
  • 13

1 Answers1

6
  1. 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.

  1. 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 input, and cannot use randomness in the process.

  1. 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.

Antoine Poinsot
  • 8,334
  • 2
  • 17
  • 34
Pieter Wuille
  • 105,497
  • 9
  • 194
  • 308
  • Re 2.: Perhaps this is an artifact of imprecise language in the question ("correct" vs "valid"), but transactions can be invalid and then become valid. E.g. timelocked transactions are not valid to be included until they are mature, but then valid from that point on. – Murch Jan 02 '24 at 15:20
  • @Murch The consensus rules, strictly speaking, only apply to entire blockchains (not individual blocks, and not individual transactions). Of course we do validate transactions individually insofar is possible without context (e.g. script validation), but that's necessarily only partial validation (timelocks being one aspect, but also input UTXOs existing, and block weight limit form relevant context). – Pieter Wuille Jan 02 '24 at 15:38
  • Right, what I mean is that LeaBit asks about both blocks and transactions in their question and whether things have to be forever correct or incorrect. Your answer on the other hand only focuses on the validity of the blockchain, and I was wondering whether this point should be made in your answer explicitly. – Murch Jan 02 '24 at 15:41
  • 1
    Basically, the distinction I was trying to make is that a transaction can be "correct", but a block that includes it would be invalid until the transaction’s locktime passes. So, the transaction goes from "invalid for inclusion" to "valid for inclusion" at some point in time. Also, if there are two transactions competing to spend the same input, they may both be "correct" while they are unconfirmed, but once one of them is included in a block, the other is "invalid". I guess what I’m saying is that I’m not sure what you mean with "correct". – Murch Jan 02 '24 at 15:57