1

I'm trying to understand the code from the BIP173. 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?

3
  • 1
    The choice of values is much better described in the bitcoin implementation of bech32 here, worth reading:github.com/bitcoin/bitcoin/blob/master/src/bech32.cpp Commented Feb 21, 2018 at 18:16
  • I'm answering the first question below. I think the second question is unrelated, and should probably move to a separate thread. Commented Feb 21, 2018 at 20:15
  • 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 :-) Commented Feb 21, 2018 at 21:10

1 Answer 1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.