<p>bc1 addresses are specified in <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP173</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki" rel="nofollow noreferrer">BIP350</a>. You should read and implement the algorithms there, and verify your implementation against the test vectors. There are reference implementations too that you can look at for inspiration.</p>
<p>Roughly the process is:</p>
<ul>
<li>Check the prefix (before the <code>1</code>) is as expected (<code>bc</code> for mainnet, <code>tb</code> for testnet, ...).</li>
<li>Expand the prefix to base 32 numbers.</li>
<li>Convert the data section to base 32 numbers.</li>
<li>Verify the checksum on the expanded/converted data, for both bech32 and bech32m, and remember which one succeeded. If both fail, give up.</li>
<li>Drop the last 6 values of the converted data section, interpret the first value as witness version, and convert the rest from 5 bit/symbol to 8 bit/symbol.</li>
<li>If the witness version is 0, check that the checksum matched the bech32 algorithm. If the witness version is 1..16, check that the checksum matched the bech32m algorithm.</li>
<li>Output the script OP_n (with n the witness version) followed by a push of the to-8-bit-converted data. Note that OP_0 is encoded as 0x00, while OP_1 through OP_16 are encoded as 0x51 through 0x60.</li>
</ul>

CC BY-SA 4.0
2023-03-08T15:25:46.813Z
2023-03-08T15:35:26.070Z
2023-03-08T15:35:26.070Z
Pieter Wuille
<p>I'm looking into bc1 addresses and I want to verify that the method I've implemented for generating bc1 addresses is correct. While I'm confident that I'm generating correct bc1 addresses I just had a thought that pumping the serialized bc1 address through the function to generate bc1 addresses is probably a bad idea. So, can anyone recommend to me the process by which we deserialize a bc1 address?</p>

CC BY-SA 4.0
2023-03-08T15:43:43.877Z
Out of curiosity, why are you reimplementing all of this instead of using an existing library that does all of this out of the box? If you are looking to do scientific work, surely you will want to look at usage patterns. It’s not clear to me how that is furthered by having your own implementation to parse the blockchain data. Are you sure that your Professor knew how much effort it would be to reimplement all of this and that they would still think it’s a good use of your time to do it from scratch if they were caught up on your progress?
Murch
CC BY-SA 4.0
2023-03-08T15:49:21.603Z
If they were presented between the choice of accurate data (which to clean up will probably be more than enough work!) and thorough investigation of the data, or some data made with a home-cooked blockchain parser based on regular expressions and a lot of assumptions taking up most of your time and a hasty investigation tacked on at the end, don’t you think the first would be more attractive?
Murch
CC BY-SA 4.0
2023-03-08T15:50:08.243Z
This all sounds like a heavy case of not-invented-here syndrome to me. All of the libraries we mentioned are opensource, most of them have very permissive licenses—just saying.
Murch
CC BY-SA 4.0
2023-03-08T16:01:02.690Z
@Murch I think the conundrum is that the professor wants this data parsed in real time v. from the blockchain. Do you have any libraries you suggest?
bitcoinluvr6969
CC BY-SA 4.0
2023-03-08T16:02:09.477Z
@bitcoinluvr6969 Given that the on-chain data and the protocol on the wire use the same transaction encoding, yes, literally every library that can parse transactions and can do address encoding/decoding will work. Libraries that implement the P2P protocol exist too.
Pieter Wuille
CC BY-SA 4.0
2023-03-08T16:12:18.753Z
Can either of you suggest a specific one? for python
bitcoinluvr6969
CC BY-SA 4.0
2023-03-08T16:14:44.433Z
@bitcoinluvr6969 Perhaps you should open a question about that then, explaining exactly what you're trying to do ("parse bitcoin addresses from transactions received through the P2P protocol", with clarification of your constraints like what programming language you need to use) rather than half a dozen XY problem questions (https://xyproblem.info/).
Pieter Wuille
CC BY-SA 4.0
2023-03-08T16:19:02.340Z
Thanks. done...
bitcoinluvr6969
<bech32-address><bip350-bech32m>
When a bc1 address is serialized, how does one deserialize it?
bitcoinluvr6969
# When a bc1 address is serialized, how does one deserialize it?

(Asked by: username_0 on 2023-03-08)

I'm looking into bc1 addresses and I want to verify that the method I've implemented for generating bc1 addresses is correct. While I'm confident that I'm generating correct bc1 addresses I just had a thought that pumping the serialized bc1 address through the function to generate bc1 addresses is probably a bad idea. So, can anyone recommend to me the process by which we deserialize a bc1 address?

**Tags:** bech32-address, bip350-bech32m

> **Comments:**
> **username_1**: Out of curiosity, why are you reimplementing all of this instead of using an existing library that does all of this out of the box? If you are looking to do scientific work, surely you will want to look at usage patterns. It’s not clear to me how that is furthered by having your own implementation to parse the blockchain data. Are you sure that your Professor knew how much effort it would be to reimplement all of this and that they would still think it’s a good use of your time to do it from scratch if they were caught up on your progress?  
> **username_1**: If they were presented between the choice of accurate data (which to clean up will probably be more than enough work!) and thorough investigation of the data, or some data made with a home-cooked blockchain parser based on regular expressions and a lot of assumptions taking up most of your time and a hasty investigation tacked on at the end, don’t you think the first would be more attractive?  
> **username_1**: This all sounds like a heavy case of not-invented-here syndrome to me. All of the libraries we mentioned are opensource, most of them have very permissive licenses—just saying.  
> **username_0**: @username_1 I think the conundrum is that the professor wants this data parsed in real time v. from the blockchain. Do you have any libraries you suggest?  
> **username_2**: @username_0 Given that the on-chain data and the protocol on the wire use the same transaction encoding, yes, literally every library that can parse transactions and can do address encoding/decoding will work. Libraries that implement the P2P protocol exist too.  
> **username_0**: Can either of you suggest a specific one? for python  
> **username_2**: @username_0 Perhaps you should open a question about that then, explaining exactly what you're trying to do ("parse bitcoin addresses from transactions received through the P2P protocol", with clarification of your constraints like what programming language you need to use) rather than half a dozen XY problem questions (https://xyproblem.info/).  
> **username_0**: Thanks. done...  

---

## 1 answers

### Answer by username_2 on 2023-03-08. Score: 3 | Accepted answer

bc1 addresses are specified in [BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) and [BIP350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki). You should read and implement the algorithms there, and verify your implementation against the test vectors. There are reference implementations too that you can look at for inspiration.

Roughly the process is:

* Check the prefix (before the `1`) is as expected (`bc` for mainnet, `tb` for testnet, ...).
* Expand the prefix to base 32 numbers.
* Convert the data section to base 32 numbers.
* Verify the checksum on the expanded/converted data, for both bech32 and bech32m, and remember which one succeeded. If both fail, give up.
* Drop the last 6 values of the converted data section, interpret the first value as witness version, and convert the rest from 5 bit/symbol to 8 bit/symbol.
* If the witness version is 0, check that the checksum matched the bech32 algorithm. If the witness version is 1..16, check that the checksum matched the bech32m algorithm.
* Output the script OP\_n (with n the witness version) followed by a push of the to-8-bit-converted data. Note that OP\_0 is encoded as 0x00, while OP\_1 through OP\_16 are encoded as 0x51 through 0x60.


---

