<p>Block explorers I've seen typically accept the following inputs:</p>

<ul>
<li><p>Bitcoin address: <a href="https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses" rel="nofollow noreferrer">25-34 alphanumeric characters</a>.</p></li>
<li><p>Block height: decimal number, up to let's say 10 digits</p></li>
<li><p>Block hash: 64 hex digits (0-9, a-f), representing a 256-bit number</p></li>
<li><p>Transaction ID: 64 hex digits</p></li>
</ul>

<p>So it's easy to recognize a Bitcoin address or block height with a simple regex.  </p>

<p>They can't tell apart a block hash from a transaction ID, because in principle any given 256-bit number could be the hash of either (or neither).  So when a string of 64 hex digits is input, they simply search for it as block hash <em>and</em> as a transaction ID, and if one of them is found, they return the appropriate information.  It's overwhelmingly improbable that the same string could be the hash of a valid block and of a valid transaction, so there isn't really any need to handle the possibility that both are found.</p>

<p>They could do some minor optimizations: for instance, if the string starts with a bunch of zeros, it's more likely to be a block hash, so maybe they search that table first.</p>

CC BY-SA 3.0
2018-02-05T19:23:20.807Z
Í would like to, if I may, to add to first bullet point: when on production, addresses begin with „1“ or „3“ ...
pebwindkraft
CC BY-SA 3.0
2018-02-05T14:05:13.273Z
2018-02-05T14:05:13.273Z
Nate Eldredge
<p>I'm building a block explorer using blockchain.info and their API
<a href="https://github.com/blockchain/api-v1-client-php/blob/master/docs/blockexplorer.md" rel="nofollow noreferrer">https://github.com/blockchain/api-v1-client-php/blob/master/docs/blockexplorer.md</a></p>

<p>but what I don't understand is, what is the best way to recognize if the user is searching for an address or a block hash, or what ever.
how do the other block explorers do that?
They allow to search for all of those in the same search box.</p>

<p>Thanks for any help !</p>

<blockchain.info><php>
Recognize Bitcoin address from block hash, and transaction hash
Roy Glaser
# Recognize Bitcoin address from block hash, and transaction hash

(Asked by: username_0 on 2018-02-05)

I'm building a block explorer using blockchain.info and their API
<https://github.com/blockchain/api-v1-client-php/blob/master/docs/blockexplorer.md>

but what I don't understand is, what is the best way to recognize if the user is searching for an address or a block hash, or what ever.
how do the other block explorers do that?
They allow to search for all of those in the same search box.

Thanks for any help !

**Tags:** blockchain.info, php


---

## 1 answers

### Answer by username_1 on 2018-02-05. Score: 1 | Accepted answer

Block explorers I've seen typically accept the following inputs:

* Bitcoin address: [25-34 alphanumeric characters](https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses).
* Block height: decimal number, up to let's say 10 digits
* Block hash: 64 hex digits (0-9, a-f), representing a 256-bit number
* Transaction ID: 64 hex digits

So it's easy to recognize a Bitcoin address or block height with a simple regex.

They can't tell apart a block hash from a transaction ID, because in principle any given 256-bit number could be the hash of either (or neither). So when a string of 64 hex digits is input, they simply search for it as block hash *and* as a transaction ID, and if one of them is found, they return the appropriate information. It's overwhelmingly improbable that the same string could be the hash of a valid block and of a valid transaction, so there isn't really any need to handle the possibility that both are found.

They could do some minor optimizations: for instance, if the string starts with a bunch of zeros, it's more likely to be a block hash, so maybe they search that table first.

> **Comments:**
> **username_2**: Í would like to, if I may, to add to first bullet point: when on production, addresses begin with „1“ or „3“ ...  

---

