Brice

I pushed one small change that makes the mutants testing a bit happier. The other items it reports I think should be fixed in a more generic way, or else...

> Is there a test document somewhere that we can update so we can remember to put this PR through its paces on the Nakamoto testnet? We probably should start...

I agree. We should probably move several of these properties to a new `get-tenure-info?`. There is a challenge because this was not included in the SIP. We'll need to figure...

This is being implemented together with #4541 in #4846.

Ok, I'm going to begin implementation work for this. Based on the discussions, I think the following seems like a reasonable solution: - The miner sets a Unix time timestamp...

Note that this ignores the Bitcoin block's timestamp, so there is no guaranteed correlation between the Bitcoin block's timestamp and the Stacks blocks timestamps.

The miner will set this timestamp before processing any transactions, so transactions can access the timestamp of the current block via Clarity's `get-block-info?` function.

> The miner will set this timestamp before processing any transactions, so transactions can access the timestamp of the current block via Clarity's get-block-info? function. I realized that the `get-block-info?`...

Additionally, `get-block-info?` includes fields that cannot be known until after the block is mined, so it does not make sense to retrieve info for the current block. This will be...

I think the simplest policy for this situation would be **Option A**: **From the miner's perspective:** - If I see a burn block before proposing my block to the signers,...