Extension: report any burnchain block hash

[jcnelson]

Add a field to get-block-info? that allows the caller to load the burnchain block hash for any burnchain block height. This is not provided by burnchain-header-hash, which returns the burnchain block hash for a Stacks block height.

If we're going to verify Bitcoin transactions in the presence of flash blocks, this needs to be added for 2.1.

[cryptopanter]

Atleast we need that for Bithority project 🎩👍💯

[kantai]

For this issue, I think this should be implemented as a new function, e.g., get-burn-block-info?, rather than adding a field to get-block-info?.

[gregorycoppola]

Currently, the logic for burnchain-header-hash is like this:

        BlockInfoProperty::BurnchainHeaderHash => {
            let burnchain_header_hash = env
                .global_context
                .database
                .get_burnchain_block_header_hash(height_value);
            Value::Sequence(SequenceData::Buffer(BuffData {
                data: burnchain_header_hash.as_bytes().to_vec(),
            }))
        }

Does anyone know what the backend call would be for the new function?

[gregorycoppola]

@jcnelson @kantai

Should the solution use this following method BurnStateDB::get_burn_header_hash? And, if so, where does the "SortitionId" come from? Is it an input from the contract or from the system state?

impl BurnStateDB for SortitionHandleTx<'_> {
    fn get_burn_header_hash(
        &self,
        height: u32,
        sortition_id: &SortitionId,
    ) -> Option<BurnchainHeaderHash> {}
}

from src/clarity_vm/database/mod.rs

[kantai]

Yes -- that's the method that should be used. Unfortunately, getting the correct SortitionId will require some additional plumbing. Basically, the SortitionId uniquely identifies the Bitcoin view that elected a given Stacks block. So there is a mapping from StacksBlockId -> SortitionId, however, that mapping isn't currently available to the Clarity VM. You'd need to first get the consensus hash from the HeadersDB, which would require adding a new method to the HeadersDB trait.

Then, I'd recommend just changing the signature of get_burn_header_hash in that trait to accept a ConsensusHash instead of SortitionId. The implementation of that method would need to call get_sortition_id_by_consensus with the SortitionHandle to get a SortitionId and then it could continue to work as that method currently does.

[Zk2u]

Worth thinking about: clarity-lang/reference#49

[jcnelson]

Implemented in #2770

[blockstack-devops]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.