Viability of Native Introspection of Mature Block Headers and Coinbase Transactions

The other day I asked this question about Native Introspection

did you guys consider making blockchain context available to script by allowing introspecting a prevout’s block hash and height?

and @emergent_reasons made me quickly realize why that’s not viable:

forces re-evaluation of every transaction in the mempool on each block

After some more brainstorming, one thing became clear, there are already some special kinds of outputs that may force re-evaluation of all transactions dependent on them: coinbase outputs. Because of that, we have the maturity rule so they can’t be spent unless 100 blocks deep.

Then I started thinking, what if we put data about the block header into coinbase outputs, so they can be spent by other TX-es in order to bring the data about some past block header into local transaction scope.
I think that could work, but it’s really a convoluted way to achieve something that could be better achieved with an opcode like this:

<block_hash> <data_element> OP_GETBLOCKDATA

data_element would encode the field we’re interested in, i.e. block header fields: version, previous block hash, merkle root, timestamp, target, nonce.
We could also access extended data that goes into coinbase TX. Right now it’s only the block height, but in the future it could also access the UTXO commitment for the height.

The opcode would work only if the referenced block is buried more than 100 blocks deep than the transaction that’s being evaluated. If not, the opcode would return an empty stack element.

I think it is viable, but it would be a delicate thing to implement, and there’s (yet) not a clear use-case that would require it.

I think it would enable:

  • accessing blockchain-native randomness entropy that can’t be manipulated by users (but theoretically it could be manipulated by miners with power to reorg 100 blocks), potentially used for blockchain-native trustless gambling
  • “introspecting” some past UTXO commitment state at height X by reconstructing the merkle branch as transaction input’s proof and matching it against the root hash provided by the opcode, sounds useful but I haven’t got a good idea for what. (if we will have utxo commitments written into coinbase tx) Edit: utxo commitments are not a merkle tree, not sure if accessing it from an input’s script would be useful.
  • “introspecting” any transaction older than 100 blocks, SPV method

I am not proposing anything, it’s just an idea, and I don’t want to forget it, so posting here to maybe brainstorm it, see what other people think… have it ferment here and maybe revisit the idea in 2024 :slight_smile:

1 Like