<p>As per <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Specification" rel="nofollow noreferrer">BIP 173</a>, the data part consists of:</p>

<pre><code>The data-part values:
1 byte: the witness version
A conversion of the 2-to-40-byte witness program (as defined by BIP141) to base32:
Start with the bits of the witness program, most significant bit per byte first.
Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.
Translate those bits to characters using the table above.
</code></pre>

<p>The value itself is simply the byte data encoded with bech32's encoding system, which is also outlined in BIP 173.</p>

<p>Thus, you need to store up to 41 bytes per address, if you know that all your addresses have the same human readable portion. If not, you will need an additional byte or two to store a reference to which human readable part that address uses (if that information is relevant to your usecase - the 41 bytes from the data portion may be enough, if all you want is a list of used Bitcoin addresses, for example).</p>

<p>The human readable part is usually fixed for a given network or address family, and the separator is always <code>1</code></p>

CC BY-SA 4.0
2019-09-25T04:27:21.160Z
2019-09-25T04:27:21.160Z
Raghav Sood
<blockquote>
  <p>Is there a way to get to the hash160 address from bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c</p>
</blockquote>

<p>Yes, you could use the <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Reference_implementations" rel="nofollow noreferrer">reference implementations</a> in various languages to encode and decode a bech32 address. For example, I have decoded the sample address you mentioned in the question, <code>bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c</code>, using python below. The decode function gives us the witness version (0 in this case) and a byte array.</p>



<pre><code>import bech32

address = "bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c"
address_decoded = bech32.decode("bc", address)

address_decoded  # a tuple containing witness version and bytearray of the address
&gt;&gt;&gt; (0, [141, 122, 10, 52, 97, 227, 137, 23, 35, 229, 253, 248, 18, 156, 170, 0, 117, 6, 12, 255])

bytes(address_decoded[1])
&gt;&gt;&gt; b'\x8dz\n4a\xe3\x89\x17#\xe5\xfd\xf8\x12\x9c\xaa\x00u\x06\x0c\xff'  
</code></pre>

<p>Couple of points to note:  </p>

<ul>
<li>The address you have mentioned here is a P2WPKH and has a length 20 bytes. However, P2WSH addresses are 32 bytes (they also begin with "bc1...") as we take the SHA256 of the witnessScript instead of HASH160. </li>
<li>Although version 0 addresses (P2PKH, P2WSH) will have a data payload of 1+20 or 1+32 bytes, <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP173</a> allows up to 40 bytes in a witness program, for a total of 1+40 bytes.</li>
</ul>

CC BY-SA 4.0
2019-09-25T06:24:04.007Z
Note that although version 0 addresses will have a data payload of 1+20 or 1+32 bytes, BIP173 allows up to 40 bytes in a witness program, for a total of 1+40.
Raghav Sood
CC BY-SA 4.0
2019-09-25T10:27:20.203Z
@RaghavSood Thanks. I have incorporated that in my answer.
Ugam Kamat
CC BY-SA 4.0
2019-09-25T04:26:43.890Z
2019-09-25T10:27:05.403Z
2019-09-25T10:27:05.403Z
Ugam Kamat
<p>This is not a duplicate of <a href="https://bitcoin.stackexchange.com/questions/37153/what-is-the-most-efficient-way-to-store-bitcoin-addresses-in-a-database">What is the most efficient way to store bitcoin addresses in a database?</a> but it's the same question except I need a segwit answer.</p>

<p>Let's say I wanted to store every standard BTC address in an SQL database.
The most space efficient way is to extract the HASH160 address by converting to base58 then slicing away the checksum. This will allow you to store a BTC address in 20 bytes.</p>

<p>Until segwit blocks come.</p>

<p>Is there a way to get to the hash160 address from:
bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c</p>

<p>If not, could someone tell me the most space efficient way to store this address in a database?</p>

<p>I have no need to convert it back to original string, but only ensure its identity.</p>

<p>Thank you</p>

CC BY-SA 4.0
2019-09-25T18:43:06.683Z
A popular block explorer converting addresses into hash160's in their database resulted in funds loss, since their service erroneously reported the same funds being paid to both p2pkh and p2sh addresses.  Make very sure what you do is fit for purpose...
G. Maxwell
CC BY-SA 4.0
2019-10-16T05:19:38.583Z
Thank you, it's just for a home machine learning project. Not a mission critical security application.
Roderick Obrist
<address><segregated-witness><bech32-address>
Most efficient way to store Segwit Address in a database
Roderick Obrist
# Most efficient way to store Segwit Address in a database

(Asked by: username_0 on 2019-09-25)

This is not a duplicate of [What is the most efficient way to store bitcoin addresses in a database?](https://bitcoin.stackexchange.com/questions/37153/what-is-the-most-efficient-way-to-store-bitcoin-addresses-in-a-database) but it's the same question except I need a segwit answer.

Let's say I wanted to store every standard BTC address in an SQL database.
The most space efficient way is to extract the HASH160 address by converting to base58 then slicing away the checksum. This will allow you to store a BTC address in 20 bytes.

Until segwit blocks come.

Is there a way to get to the hash160 address from:
bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c

If not, could someone tell me the most space efficient way to store this address in a database?

I have no need to convert it back to original string, but only ensure its identity.

Thank you

**Tags:** address, segregated-witness, bech32-address

> **Comments:**
> **username_1**: A popular block explorer converting addresses into hash160's in their database resulted in funds loss, since their service erroneously reported the same funds being paid to both p2pkh and p2sh addresses.  Make very sure what you do is fit for purpose...  
> **username_0**: Thank you, it's just for a home machine learning project. Not a mission critical security application.  

---

## 2 answers

### Answer by username_3 on 2019-09-25. Score: 8 | Accepted answer

> Is there a way to get to the hash160 address from bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c

Yes, you could use the [reference implementations](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Reference_implementations) in various languages to encode and decode a bech32 address. For example, I have decoded the sample address you mentioned in the question, `bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c`, using python below. The decode function gives us the witness version (0 in this case) and a byte array.

```
import bech32

address = "bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c"
address_decoded = bech32.decode("bc", address)

address_decoded  # a tuple containing witness version and bytearray of the address
>>> (0, [141, 122, 10, 52, 97, 227, 137, 23, 35, 229, 253, 248, 18, 156, 170, 0, 117, 6, 12, 255])

bytes(address_decoded[1])
>>> b'\x8dz\n4a\xe3\x89\x17#\xe5\xfd\xf8\x12\x9c\xaa\x00u\x06\x0c\xff'  

```

Couple of points to note:

* The address you have mentioned here is a P2WPKH and has a length 20 bytes. However, P2WSH addresses are 32 bytes (they also begin with "bc1...") as we take the SHA256 of the witnessScript instead of HASH160.
* Although version 0 addresses (P2PKH, P2WSH) will have a data payload of 1+20 or 1+32 bytes, [BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) allows up to 40 bytes in a witness program, for a total of 1+40 bytes.

> **Comments:**
> **username_2**: Note that although version 0 addresses will have a data payload of 1+20 or 1+32 bytes, BIP173 allows up to 40 bytes in a witness program, for a total of 1+40.  
> **username_3**: @username_2 Thanks. I have incorporated that in my answer.  

---

### Answer by username_2 on 2019-09-25. Score: 2

As per [BIP 173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Specification), the data part consists of:

```
The data-part values:
1 byte: the witness version
A conversion of the 2-to-40-byte witness program (as defined by BIP141) to base32:
Start with the bits of the witness program, most significant bit per byte first.
Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.
Translate those bits to characters using the table above.

```

The value itself is simply the byte data encoded with bech32's encoding system, which is also outlined in BIP 173.

Thus, you need to store up to 41 bytes per address, if you know that all your addresses have the same human readable portion. If not, you will need an additional byte or two to store a reference to which human readable part that address uses (if that information is relevant to your usecase - the 41 bytes from the data portion may be enough, if all you want is a list of used Bitcoin addresses, for example).

The human readable part is usually fixed for a given network or address family, and the separator is always `1`


---

