Yayyy, finally a proposal about recent header data in transactions!! 
I’d like to start with the following quote from @jm9k about the current L1 off-chain determinism, which is the underlying L1 design principle from which this proposal is seemingly departing from:
What is being called off-chain determinism is not really true. It is an optimization of the mempool. Absolute off-chain determinism without any exceptions is likely impossible.
In the case of CKB, the optimization is that it only has to check UTXOs again before inclusion. Since is checked to enter the mempool, so nothing actually resides in the mempool until it becomes valid, and then it is valid forever.
On my side, I agree that a Nervos L1 script should have some ways to check if the outside world has changed since the transaction was sent, but this has to be done in a way as smart as possible to avoid breaking the Off-chain determinism optimization of the mempool.
Back to the current proposal, if the open transaction aggregator and the block producer are either the very same entity or very tightly integrated together, then this proposal completely sidestep the issue of the Off-chain determinism as the aggregated transaction never actually enter the public mempool. Very smart 
Now it’s an issue of the aggregator’s mempool tho … and I’d like to see how they handle an open transaction whose script whose validity is:
- True if and only if the timestamp is even.
- False otherwise.
That said, why limiting the scope to the timestamp?? I’d like to see the possibility to access the full header of the previous block!! Luckily this is accomplished easily, the cell data instead of being a timestamp, it’s the header hash of the previous block.
Then again, we don’t strictly need to include this information as a cell, we just need:
- A conventional way to inform the scripts inside an open transaction that a certain Header Deps is the header of the previous block. For example: “the first header deps is the header deps of the previous block” or “the header deps with maximum blocknumber is the the header of the previous block”
- A way for other miners to validate the previous convention being respected, the only consensus change needed.