<p>Ok, I've found the problem.</p>

<p>Input has 52 5-bit groups. 260 bits. Remember that every encode calls convertBits to convert from 8 bit groups to 5-bit groups. But 260 bits made of bytes is impossible! So there were 264 bits originally, = 33bytes. 264 bits need to be padded by convertBits (convertBits can/will pad when encoding but won't while decoding). So we have 265 bits. 53 5-bit groups. So you need to add a zero at the end of your input to achieve the intended result.</p>

<p>While decoding, convertBits will, until the number of bits is a multiple of 8, check that the last bit is 0, drop it. In your case, the last bit is not zero, so the only way not to discard it is to pad it, which it's not allowed to do while decoding.</p>

<p><strong>TLDR</strong> all 5-bit groups as input are converted from 8-bit groups (addresses are designed for hash outputs and hashes output full bytes). If decoding can't decode to 8-bit groups without padding, the address is considered invalid.</p>

<hr>

<p>Let's try to do what convertBits does to decode!</p>

<p>First, to simplify ignore first few multiples of 40 bits in the input. The last few bits remaining are:</p>

<pre><code>10000 00110 01001 10001
</code></pre>

<p>Convertbits, while decoding converts from 5 to 8:</p>

<pre><code>10000001 10010011 0001
</code></pre>

<p>Does the last group have exactly 8 bits? (In that case no further action would be needed) No.
Does the last group have zeros only? (In that case we can just erase the last group) No.
Throw an error. We either need to discard bits or pad, which is not allowed while decoding.</p>

<p>This is why the address you generated is can't be decoded. (<a href="http://bitcoin.sipa.be/bech32/demo/demo.html" rel="nofollow noreferrer">Try it</a>) </p>

CC BY-SA 4.0
2020-04-09T14:23:44.273Z
thanks very nice answer, I fix it. anyway I don't understand when Drop last 5 bits. I create another address and last 5 bits are 00000. I paste the address `tb1qgw3wu3a67tk7p4ltpxxfm6np6y78m5c4wp0qlpy8c4qaydus7s5qsva89z` in (http://bitcoin.sipa.be/bech32/demo/demo.html) I don't receive any errors.  Anyway my procedure seems "inverse" of BIP_0173. First of all I create scriptHash, then convert script hash and re-arrange in 8bit adding 0 at the end. Add Witness program (5 bits of 0) and re-arrange in 5 bit. create checksum and create address. in BIP_0173 seems that before use 5 bits after 8 bits
monkeyUser
CC BY-SA 4.0
2020-04-09T14:44:38.037Z
It's correct. Adding 8 times 0 at the end makes the decoder think some of it as coming from padding. Apart from your description of padding, that's exactly BIP 173. Converting from 5 bits to 8 bits is for decoding.
MCCCS
CC BY-SA 4.0
2020-04-09T14:49:45.840Z
ok, add 8 zero ad the end because i need of 1 megabyte I presume. Very similar to calculate the seed.
monkeyUser
CC BY-SA 4.0
2020-04-06T18:31:33.607Z
2020-04-07T07:34:51.130Z
2020-04-07T07:34:51.130Z
MCCCS
<p>My goal is replicate the same P2WSH of <a href="https://en.bitcoin.it/wiki/BIP_0173" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/BIP_0173</a> </p>

<blockquote>
  <p>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7</p>
</blockquote>

<p>I'm able to generate the "first" part before checksum. 
There are my binary</p>

<blockquote>
  <p>00000 00011 00001 10001 10001 01000 01111 00000 10100 11000 10100
  01011 00110 10000 00001 00101 11101 00011 00100 10000 00011 00110
  10101 10110 11010 00010 01101 10110 01001 10000 10101 10011 11000
  11001 10101 00110 10010 01111 01000 01101 11000 11000 11000 11001
  01001 01100 00001 00100 10000 00110 01001 10001</p>
</blockquote>

<p>And Their values in base10</p>

<blockquote>
  <p>0, 3, 1, 17, 17, 8, 15, 0, 20, 24, 20, 11, 6, 16, 1, 5, 29, 3, 4, 16,
  3, 6, 21, 22, 26, 2, 13, 22, 9, 16, 21, 19, 24, 25, 21, 6, 18, 15, 8,
  13, 24, 24, 24, 25, 9, 12, 1, 4, 16, 6, 9, 17</p>
</blockquote>

<p>After that I use Python function</p>

<pre><code>python -c "import bech32; print bech32.bech32_create_checksum('tb', [0, 3, 1, 17, 17, 8, 15, 0, 20, 24, 20, 11, 6, 16, 1, 5, 29, 3, 4, 16, 3, 6, 21, 22, 26, 2, 13, 22, 9, 16, 21, 19, 24, 25, 21, 6, 18, 15, 8, 13, 24, 24, 24, 25, 9, 12, 1, 4, 16, 6, 9, 17] )"
</code></pre>

<p>And I get that result:</p>

<pre><code>[3, 1, 3, 10, 2, 25]
</code></pre>

<p>After that I can map on charset ("qpzry9x8gf2tvdw0s3jn54khce6mua7l")</p>

<p>The final result is:
My address is:</p>

<pre><code>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3rpr2ze
</code></pre>

<p>the address of <a href="https://en.bitcoin.it/wiki/BIP_0173" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/BIP_0173</a></p>

<pre><code>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7
</code></pre>

<p>As you can see the problem is only the checksum, the first part <code>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3</code> is the same.</p>

CC BY-SA 4.0
2020-04-06T18:16:16.180Z
I am actually getting the same result as you. I am using the python implementation here https://github.com/sipa/bech32/tree/master/ref/python
Oscar Serna
<address><segregated-witness><bech32-address>
Checksum P2WSH failed
monkeyUser
# Checksum P2WSH failed

(Asked by: username_0 on 2020-04-06)

My goal is replicate the same P2WSH of <https://en.bitcoin.it/wiki/BIP_0173>

> tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7

I'm able to generate the "first" part before checksum.
There are my binary

> 00000 00011 00001 10001 10001 01000 01111 00000 10100 11000 10100
> 01011 00110 10000 00001 00101 11101 00011 00100 10000 00011 00110
> 10101 10110 11010 00010 01101 10110 01001 10000 10101 10011 11000
> 11001 10101 00110 10010 01111 01000 01101 11000 11000 11000 11001
> 01001 01100 00001 00100 10000 00110 01001 10001

And Their values in base10

> 0, 3, 1, 17, 17, 8, 15, 0, 20, 24, 20, 11, 6, 16, 1, 5, 29, 3, 4, 16,
> 3, 6, 21, 22, 26, 2, 13, 22, 9, 16, 21, 19, 24, 25, 21, 6, 18, 15, 8,
> 13, 24, 24, 24, 25, 9, 12, 1, 4, 16, 6, 9, 17

After that I use Python function

```
python -c "import bech32; print bech32.bech32_create_checksum('tb', [0, 3, 1, 17, 17, 8, 15, 0, 20, 24, 20, 11, 6, 16, 1, 5, 29, 3, 4, 16, 3, 6, 21, 22, 26, 2, 13, 22, 9, 16, 21, 19, 24, 25, 21, 6, 18, 15, 8, 13, 24, 24, 24, 25, 9, 12, 1, 4, 16, 6, 9, 17] )"

```

And I get that result:

```
[3, 1, 3, 10, 2, 25]

```

After that I can map on charset ("qpzry9x8gf2tvdw0s3jn54khce6mua7l")

The final result is:
My address is:

```
tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3rpr2ze

```

the address of <https://en.bitcoin.it/wiki/BIP_0173>

```
tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7

```

As you can see the problem is only the checksum, the first part `tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3` is the same.

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

> **Comments:**
> **username_1**: I am actually getting the same result as you. I am using the python implementation here https://github.com/sipa/bech32/tree/master/ref/python  

---

## 1 answers

### Answer by username_2 on 2020-04-06. Score: 1 | Accepted answer

Ok, I've found the problem.

Input has 52 5-bit groups. 260 bits. Remember that every encode calls convertBits to convert from 8 bit groups to 5-bit groups. But 260 bits made of bytes is impossible! So there were 264 bits originally, = 33bytes. 264 bits need to be padded by convertBits (convertBits can/will pad when encoding but won't while decoding). So we have 265 bits. 53 5-bit groups. So you need to add a zero at the end of your input to achieve the intended result.

While decoding, convertBits will, until the number of bits is a multiple of 8, check that the last bit is 0, drop it. In your case, the last bit is not zero, so the only way not to discard it is to pad it, which it's not allowed to do while decoding.

**TLDR** all 5-bit groups as input are converted from 8-bit groups (addresses are designed for hash outputs and hashes output full bytes). If decoding can't decode to 8-bit groups without padding, the address is considered invalid.

---

Let's try to do what convertBits does to decode!

First, to simplify ignore first few multiples of 40 bits in the input. The last few bits remaining are:

```
10000 00110 01001 10001

```

Convertbits, while decoding converts from 5 to 8:

```
10000001 10010011 0001

```

Does the last group have exactly 8 bits? (In that case no further action would be needed) No.
Does the last group have zeros only? (In that case we can just erase the last group) No.
Throw an error. We either need to discard bits or pad, which is not allowed while decoding.

This is why the address you generated is can't be decoded. ([Try it](http://bitcoin.sipa.be/bech32/demo/demo.html))

> **Comments:**
> **username_0**: thanks very nice answer, I fix it. anyway I don't understand when Drop last 5 bits. I create another address and last 5 bits are 00000. I paste the address `tb1qgw3wu3a67tk7p4ltpxxfm6np6y78m5c4wp0qlpy8c4qaydus7s5qsva89z` in (http://bitcoin.sipa.be/bech32/demo/demo.html) I don't receive any errors.  Anyway my procedure seems "inverse" of BIP_0173. First of all I create scriptHash, then convert script hash and re-arrange in 8bit adding 0 at the end. Add Witness program (5 bits of 0) and re-arrange in 5 bit. create checksum and create address. in BIP_0173 seems that before use 5 bits after 8 bits  
> **username_2**: It's correct. Adding 8 times 0 at the end makes the decoder think some of it as coming from padding. Apart from your description of padding, that's exactly BIP 173. Converting from 5 bits to 8 bits is for decoding.  
> **username_0**: ok, add 8 zero ad the end because i need of 1 megabyte I presume. Very similar to calculate the seed.  

---

