Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to get the BTC block-height in bitcoin canister? #269

Closed
readygo67 opened this issue Nov 20, 2023 · 8 comments
Closed

how to get the BTC block-height in bitcoin canister? #269

readygo67 opened this issue Nov 20, 2023 · 8 comments

Comments

@readygo67
Copy link

No description provided.

@THLO
Copy link
Contributor

THLO commented Nov 20, 2023

There is no dedicated endpoint for the block height. Instead, you can just call bitcoin_get_utxos (or bitcoin_get_utxos_query) on the management canister.
The returned get_utxos_response contains both the height at the tip of the blockchain (tip_height) as well as the hash of the block at that height (tip_block_height).

@readygo67
Copy link
Author

In my dapp, btc block height is used as input to unfreeze staked asset, block hash is used as public root of merkle proof.
hope Dfiniity provides an api to get latest (blockheight, blockhash).

@THLO
Copy link
Contributor

THLO commented Nov 21, 2023

Just in case I wasn't clear, the tip of the chain constitutes the latest block. So, when making any request for UTXOs (for min_confirmations=0), you always get the block height and block hash of the latest block in addition to the requested UTXOs.

Does that help?

@readygo67
Copy link
Author

@THLO , so it means that tip_block_hash and tip_height are the values of latest block?
For example, even if address A has no utxos, when get_utxos(mainnet, A) is called, the response also contains latest mainnet's height and hash? If yes, this endpoint is what I want.


pub struct GetUtxosResponse {
    /// List of UTXOs.
    pub utxos: Vec<Utxo>,
    /// Hash of the tip block.
    pub tip_block_hash: BlockHash,
    /// Height of the tip height.
    pub tip_height: u32,
    /// Page reference when the response needs to be paginated.
    ///
    /// To be used in [UtxoFilter::Page].
    pub next_page: Option<Vec<u8>>,
}

@THLO
Copy link
Contributor

THLO commented Nov 22, 2023

Yes, exactly!
For example, when running

dfx canister --network ic call aaaaa-aa --wallet <...> --with-cycles 1000000000000 bitcoin_get_utxos '(record { address = "1EyUbBqhyBJFC54y9spSnaXshvhDqkBLod"; network = variant { mainnet }; filter =  null;})'

for a randomly generated Bitcoin address, you get something like this:

(
  record {
    next_page = null;
    tip_height = 817_953 : nat32;
    tip_block_hash = blob "t\03\8f\0bJ\ed\bbv\bb\be\eaR\c9\f7\b1\ef\82\92\eb3f\c4\02\00\00\00\00\00\00\00\00\00";
    utxos = vec {};
  },
)

The tip_height and tip_block_hash fields contain the height and hash of the latest block when this request was sent.

@readygo67
Copy link
Author

readygo67 commented Nov 23, 2023

one more question,suppose bitcoin's height is N currently, if call get_utxos, which is the value of tip_height, N or N-6 or another value?

@THLO
Copy link
Contributor

THLO commented Nov 23, 2023

Good question!
If the block height is N and bitcoin_get_utxos is called without a filter as above, then tip_height=N.
The considered chain can be restricted by specifying a minimum number of confirmations. For example, when specifying min_confirmations=6 in the request, then tip_height=N-6.

@readygo67
Copy link
Author

thanks for your clear clarification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants