<blockquote>
  <p>how to interprete script handling?</p>
</blockquote>

<p>What you're missing is that BIP173 is not a way to encode public keys or scripts. It is a way to encode segwit transaction outputs. What those outputs are and mean is currently in BIP141 and BIP143 - but may change over time, without BIP173 changing.</p>

<p>All segwit transaction outputs (current and future) have the following structure:</p>

<ul>
<li>a single opcode between OP_0 and OP_16 (whose numeric value is what we call the witness version)</li>
<li>a push of a byte array between 2 and 40 bytes (which we call the witness program).</li>
</ul>

<p>BIP173 simply encodes a witness version number and a witness program. Nothing more and nothing less. It does not care what those things mean.</p>

<p>Currently there are 2 types of native segwit outputs defined:</p>

<ul>
<li>P2WPKH: pay to witness pubkey hash. The witness version is 0, and the witness program is the 20-byte RIPE160(SHA256(pubkey)).</li>
<li>P2WSH: pay to witness script hash. The witness version is 0, and the witness program is the 32-byte SHA256(script).</li>
</ul>

<p>Segwit addresses, as defined in BIP173 permit encoding the two types above, but also all potential future witness output types, as they simply encode a version number and program bytes, whatever they are.</p>

<p>Some of the examples in the BIP use real witness versions and programs of those two types, and for clarification the keys and scripts are listed. But BIP173 doesn't really care what they are.</p>

<p>To learn how payments to public keys and multisig scripts are done in segwit, look at BIP141 and BIP143.</p>

CC BY-SA 3.0
2018-02-21T20:00:07.663Z
2018-02-21T20:00:07.663Z
Pieter Wuille
<p>I'm trying to understand the code <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">from the BIP173</a>. I read the BIP, the links to RFC3548 or z-base-32, the base32 proposal by Mark Friedenbach, and some posts here.</p>
<p><strong>Q1:</strong> how to interpret script handling?</p>
<p>I thought to understand, that bech32 is a representation of an address (encoding a hash of a public key), and has nothing to do with scripting. I got confused, in the example section it says:</p>
<blockquote>
<p>All examples use public key 0279BE66... The P2WSH examples use <code>&lt;key OP_CHECKSIG&gt;</code> as script.</p>
</blockquote>
<p>In a std tx I would have the sigscript with the signature and e.g. a pubkey. So for the spending tx, it is checked, that the pubkey matches to the signature. Is the same true for a bech32 address (besides being in the witness section)?
Is there an example with a multisig tx with only bech32 addresses?</p>
<p><strong>Q2:</strong> what is the &quot;GEN = [0x3b6a57b2 ...&quot; line?</p>
<p>In the Specification/Checksum section it says:</p>
<pre><code>def bech32_polymod(values):
  GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]
  ...
</code></pre>
<p>I am wondering, what these values do, where do they come from? I also looked into the C code, but
there is no further explanation. Where can I find it's meaning?</p>

CC BY-SA 3.0
2018-02-21T18:16:29.117Z
The choice of values is much better described in the bitcoin implementation of bech32 here, worth reading:https://github.com/bitcoin/bitcoin/blob/master/src/bech32.cpp
meshcollider
CC BY-SA 3.0
2018-02-21T20:15:00.820Z
I'm answering the first question below. I think the second question is unrelated, and should probably move to a separate thread.
Pieter Wuille
CC BY-SA 3.0
2018-02-21T21:10:20.510Z
thx, 2nd question is currently answered with your (?) comments in the cpp file, linked by MeshCollider. If required, I'll raise another one. Now reading through the below :-)
pebwindkraft
<segregated-witness><bech32-address>
understanding bech32 Addresses / BIP173 question
pebwindkraft
# understanding bech32 Addresses / BIP173 question

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

I'm trying to understand the code [from the BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki). I read the BIP, the links to RFC3548 or z-base-32, the base32 proposal by Mark Friedenbach, and some posts here.

**Q1:** how to interpret script handling?

I thought to understand, that bech32 is a representation of an address (encoding a hash of a public key), and has nothing to do with scripting. I got confused, in the example section it says:

> All examples use public key 0279BE66... The P2WSH examples use `<key OP_CHECKSIG>` as script.

In a std tx I would have the sigscript with the signature and e.g. a pubkey. So for the spending tx, it is checked, that the pubkey matches to the signature. Is the same true for a bech32 address (besides being in the witness section)?
Is there an example with a multisig tx with only bech32 addresses?

**Q2:** what is the "GEN = [0x3b6a57b2 ..." line?

In the Specification/Checksum section it says:

```
def bech32_polymod(values):
  GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]
  ...

```

I am wondering, what these values do, where do they come from? I also looked into the C code, but
there is no further explanation. Where can I find it's meaning?

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

> **Comments:**
> **username_1**: The choice of values is much better described in the bitcoin implementation of bech32 here, worth reading:https://github.com/bitcoin/bitcoin/blob/master/src/bech32.cpp  
> **username_2**: I'm answering the first question below. I think the second question is unrelated, and should probably move to a separate thread.  
> **username_0**: thx, 2nd question is currently answered with your (?) comments in the cpp file, linked by MeshCollider. If required, I'll raise another one. Now reading through the below :-)  

---

## 1 answers

### Answer by username_2 on 2018-02-21. Score: 6

> how to interprete script handling?

What you're missing is that BIP173 is not a way to encode public keys or scripts. It is a way to encode segwit transaction outputs. What those outputs are and mean is currently in BIP141 and BIP143 - but may change over time, without BIP173 changing.

All segwit transaction outputs (current and future) have the following structure:

* a single opcode between OP\_0 and OP\_16 (whose numeric value is what we call the witness version)
* a push of a byte array between 2 and 40 bytes (which we call the witness program).

BIP173 simply encodes a witness version number and a witness program. Nothing more and nothing less. It does not care what those things mean.

Currently there are 2 types of native segwit outputs defined:

* P2WPKH: pay to witness pubkey hash. The witness version is 0, and the witness program is the 20-byte RIPE160(SHA256(pubkey)).
* P2WSH: pay to witness script hash. The witness version is 0, and the witness program is the 32-byte SHA256(script).

Segwit addresses, as defined in BIP173 permit encoding the two types above, but also all potential future witness output types, as they simply encode a version number and program bytes, whatever they are.

Some of the examples in the BIP use real witness versions and programs of those two types, and for clarification the keys and scripts are listed. But BIP173 doesn't really care what they are.

To learn how payments to public keys and multisig scripts are done in segwit, look at BIP141 and BIP143.


---

