<p>Currently, my node is syncing blocks and tip(height) is 230000.</p>

<p>At this point, if I use command <code>bitcoin-cli getblockhash 230000</code>, the return information will be successful but, if I use <code>bitcoin-cli getblockhash 240000</code>, it returns error due to out of current range.</p>

<p>Yes, I know that the query that I request is definitely out of range in my chain. 
but I want to query even if the data is not in my chain. 
I think that it will be possible by asking my peers. <strong>so what is the command for my purpose?</strong></p>

<p>Sorry for my English.</p>

CC BY-SA 4.0
2019-11-22T18:18:53.483Z
I don't think is possible, the RPC framework work only on your copy of blockchain (for when i know).
vincenzopalazzo
CC BY-SA 4.0
2019-11-22T18:32:22.520Z
oh.. really? so what should I do when I want to specific query to my peer? is there alternative tool or method instead bitcoin-cli?
Hyunsoo
CC BY-SA 4.0
2019-11-22T18:50:00.003Z
The Bitcoin protocol literally has no way to ask for a header at a given height. It would be pointless information as it cannot be validated. If you want to know, wait until your own node is in sync, and ask it locally.
Pieter Wuille
CC BY-SA 4.0
2019-11-23T06:36:17.283Z
@PieterWuille At first run time, the node connects DNS seeder and receive other peer address then receive block data. if your claim is true, we could not receive block from connected peer but, actually bitcoind can receive block from connected peer.
Hyunsoo
CC BY-SA 4.0
2019-11-23T06:38:10.883Z
@Hyunsoo Nodes can request blocks and headers based on the blocks before it, allowing them to synchronize that information. But there is no "give me the block hash at height X". If you need blockchain information, you at least need fo ask for all the headers.
Pieter Wuille
CC BY-SA 4.0
2019-11-23T06:48:17.253Z
@PieterWuille Ah.. I may know what's your mean. Maybe it is problem based on RPC communication design what request and response. if I have 100 blocks and want to receive only one specific block, let's say it 107. what's the scenario for my purpose? there is no way? Do I should have all the information just before it?
Hyunsoo
CC BY-SA 4.0
2019-11-23T06:56:00.360Z
As I said, there is literally no way in the protocol to request a block or header or hash based on its height. This is not a limitation of the RPC interface, or of the Bitcoin Core implementation, it is simply not something you can do in the protocol, nor is there is need for it. Just wait until your node is synchronized.
Pieter Wuille
CC BY-SA 4.0
2019-11-23T07:04:47.370Z
I really can't understand the mean you said between two sentence. one is "Nodes can request blocks and headers based on the blocks before it," and another is "there is literally no way in the protocol to request a block or header or hash based on its height.". these sentences are conflict. If there is no protocol that can ask block information, your first sentence doesn't make sense.
Hyunsoo
CC BY-SA 4.0
2019-11-23T07:13:13.993Z
Synchronization does not happen by height, but by hash. One node says "I have blocks up to the one with hash X, what comes after?", the other responds with a bunch of hashes or headers. Once those are processed, the first one asks for more. The reason synchronization does not work by height js because there may be multiple blocks with the same height when there is a fork
Pieter Wuille
CC BY-SA 4.0
2019-11-23T07:39:43.200Z
@PieterWuille I think that your last sentence is answer on my question. I think it is not good design because reorg is generated on only tip(current block to be mined). all blocks have limitation for this reason. in other words, we couldn't ask query based on height... okay thank you for kind replying. have a nice day.
Hyunsoo
CC BY-SA 4.0
2019-11-23T15:14:12.630Z
@Hyunsoo I want to ask you, _why you think that the design of the RPC is wrong?_ I want to do you an example if suppose to have the possibility to get the block for the height from another node, and you require the last block, for how to work the Bitcoin, you don't know the time of life of the last block (look the mining consensus). So with this is not possible require the last 6 blocks and this is useless work and complexity inside the software. I think the important answer of Pieter is this:  "because there may be multiple blocks with the same height".
vincenzopalazzo
<bitcoin-cli><query>
Getting blockhash using bitcoin-cli command in shell
Hyunsoo
# Getting blockhash using bitcoin-cli command in shell

(Asked by: username_0 on 2019-11-22)

Currently, my node is syncing blocks and tip(height) is 230000.

At this point, if I use command `bitcoin-cli getblockhash 230000`, the return information will be successful but, if I use `bitcoin-cli getblockhash 240000`, it returns error due to out of current range.

Yes, I know that the query that I request is definitely out of range in my chain.
but I want to query even if the data is not in my chain.
I think that it will be possible by asking my peers. **so what is the command for my purpose?**

Sorry for my English.

**Tags:** bitcoin-cli, query

> **Comments:**
> **username_1**: I don't think is possible, the RPC framework work only on your copy of blockchain (for when i know).  
> **username_0**: oh.. really? so what should I do when I want to specific query to my peer? is there alternative tool or method instead bitcoin-cli?  
> **username_2**: The Bitcoin protocol literally has no way to ask for a header at a given height. It would be pointless information as it cannot be validated. If you want to know, wait until your own node is in sync, and ask it locally.  
> **username_0**: @username_2 At first run time, the node connects DNS seeder and receive other peer address then receive block data. if your claim is true, we could not receive block from connected peer but, actually bitcoind can receive block from connected peer.  
> **username_2**: @username_0 Nodes can request blocks and headers based on the blocks before it, allowing them to synchronize that information. But there is no "give me the block hash at height X". If you need blockchain information, you at least need fo ask for all the headers.  
> **username_0**: @username_2 Ah.. I may know what's your mean. Maybe it is problem based on RPC communication design what request and response. if I have 100 blocks and want to receive only one specific block, let's say it 107. what's the scenario for my purpose? there is no way? Do I should have all the information just before it?  
> **username_2**: As I said, there is literally no way in the protocol to request a block or header or hash based on its height. This is not a limitation of the RPC interface, or of the Bitcoin Core implementation, it is simply not something you can do in the protocol, nor is there is need for it. Just wait until your node is synchronized.  
> **username_0**: I really can't understand the mean you said between two sentence. one is "Nodes can request blocks and headers based on the blocks before it," and another is "there is literally no way in the protocol to request a block or header or hash based on its height.". these sentences are conflict. If there is no protocol that can ask block information, your first sentence doesn't make sense.  
> **username_2**: Synchronization does not happen by height, but by hash. One node says "I have blocks up to the one with hash X, what comes after?", the other responds with a bunch of hashes or headers. Once those are processed, the first one asks for more. The reason synchronization does not work by height js because there may be multiple blocks with the same height when there is a fork  
> **username_0**: @username_2 I think that your last sentence is answer on my question. I think it is not good design because reorg is generated on only tip(current block to be mined). all blocks have limitation for this reason. in other words, we couldn't ask query based on height... okay thank you for kind replying. have a nice day.  
> **username_1**: @username_0 I want to ask you, _why you think that the design of the RPC is wrong?_ I want to do you an example if suppose to have the possibility to get the block for the height from another node, and you require the last block, for how to work the Bitcoin, you don't know the time of life of the last block (look the mining consensus). So with this is not possible require the last 6 blocks and this is useless work and complexity inside the software. I think the important answer of username_2 is this:  "because there may be multiple blocks with the same height".  

---

## 0 answers

