<p>There are currently 3 address types defined in Bitcoin:</p>
<ul>
<li>The satoshi-era P2PKH format, which is Base58 encoding of (1 byte version prefix) + (20 bytes pubkeyhash) + (4 bytes checksum). The checksum is the first 4 bytes of the double-SHA256 hash of the 21 bytes that precede it. The version number is 0 for mainnet; it's easy to find lists of prefixes for other networks.
<ul>
<li>It encodes the script <code>OP_DUP OP_HASH160 &lt;that pubkeyhash&gt; OP_EQUALVERIFY OP_CHECKSIG</code></li>
</ul>
</li>
<li>The P2SH format specified in BIP 13 and BIP 16. It follows the same structure as P2PKH addresses, but with a different version number and instead of a pubkey hash, it is a script hash.
<ul>
<li>It encodes the script <code>OP_HASH160 &lt;that scripthash&gt; OP_EQUAL</code>.</li>
</ul>
</li>
<li>The native witness address format introduced in BIP 173 It uses a completely different base-32 encoding (called Bech32) of data (5-bit witness version number) + (variable length witness program).
<ul>
<li>It encodes the script <code>OP_(witnessversion) &lt;witness program&gt;</code> (see BIP 141 for the semantics of such scripts).</li>
<li>The encoding was amended in BIP 350 to use a slightly different checksum algorithm for witness version 1 and up.</li>
</ul>
</li>
</ul>
<p>In general, if you're looking for specifications, the BIPs are where to look, except of course for protocol/standard aspects that predate the BIP process.</p>

CC BY-SA 4.0
2021-06-13T05:04:43.960Z
oh man thank you again. I just base58 decoded mz6KvC4aoUeo6wSxtiVQTo7FDwPnkp6URG and I ended up with 6f cbc20a7664f2f69e5355aa427045bc15e7c6c772 f982e923. and then double hashed the first 21 bytes and got f982e923!  Just one correction, it doesn't appear that the whole script it base 58 encoded. everything by generaterawtransaction was in clear hex
noone392
CC BY-SA 4.0
2021-06-13T05:05:51.603Z
No, just the version prefix byte and the pubkeyhash/scripthash are Base58 encoded. The rest of the script is implied by the version number.
Pieter Wuille
CC BY-SA 4.0
2021-06-13T04:22:53.977Z
2021-06-13T04:22:53.977Z
Pieter Wuille
<p>So I am trying to full understand how to decode transactions. In the dev docs it discusses a raw transaction: <a href="https://developer.bitcoin.org/reference/transactions.html" rel="nofollow noreferrer">https://developer.bitcoin.org/reference/transactions.html</a>
in the paragraph &quot;TxOut: A Transaction Output&quot; there is an example. Near the bottom of that example it decodes the bitcoin script. It shows you pushing 20 bytes labeled as the public key has onto the stack.</p>
<blockquote>
<p>cbc20a7664f2f69e5355aa427045bc15e7c6c772</p>
</blockquote>
<p>That value is autogenerated from &quot;createrawtransaction&quot; cli function which comes from the public key. It specifically references the example here
<a href="https://developer.bitcoin.org/examples/transactions.html#simple-raw-transaction" rel="nofollow noreferrer">https://developer.bitcoin.org/examples/transactions.html#simple-raw-transaction</a>
where it says</p>
<blockquote>
<p>NEW_ADDRESS=mz6KvC4aoUeo6wSxtiVQTo7FDwPnkp6URG</p>
</blockquote>
<p>how are they going from</p>
<blockquote>
<p>mz6KvC4aoUeo6wSxtiVQTo7FDwPnkp6URG</p>
</blockquote>
<p>to</p>
<blockquote>
<p>cbc20a7664f2f69e5355aa427045bc15e7c6c772</p>
</blockquote>
<p>? It doesn't say anywhere in the documentation. Is this just a read the source code situation? I should say I have tried plugging the address into many different hashing calculators. I never get the same result.</p>

<address><raw-transaction><createrawtransaction>
convert from public address format to raw transaction format
noone392
# convert from public address format to raw transaction format

(Asked by: username_0 on 2021-06-13)

So I am trying to full understand how to decode transactions. In the dev docs it discusses a raw transaction: <https://developer.bitcoin.org/reference/transactions.html>
in the paragraph "TxOut: A Transaction Output" there is an example. Near the bottom of that example it decodes the bitcoin script. It shows you pushing 20 bytes labeled as the public key has onto the stack.

> cbc20a7664f2f69e5355aa427045bc15e7c6c772

That value is autogenerated from "createrawtransaction" cli function which comes from the public key. It specifically references the example here
<https://developer.bitcoin.org/examples/transactions.html#simple-raw-transaction>
where it says

> NEW\_ADDRESS=mz6KvC4aoUeo6wSxtiVQTo7FDwPnkp6URG

how are they going from

> mz6KvC4aoUeo6wSxtiVQTo7FDwPnkp6URG

to

> cbc20a7664f2f69e5355aa427045bc15e7c6c772

? It doesn't say anywhere in the documentation. Is this just a read the source code situation? I should say I have tried plugging the address into many different hashing calculators. I never get the same result.

**Tags:** address, raw-transaction, createrawtransaction


---

## 1 answers

### Answer by username_1 on 2021-06-13. Score: 1 | Accepted answer

There are currently 3 address types defined in Bitcoin:

* The satoshi-era P2PKH format, which is Base58 encoding of (1 byte version prefix) + (20 bytes pubkeyhash) + (4 bytes checksum). The checksum is the first 4 bytes of the double-SHA256 hash of the 21 bytes that precede it. The version number is 0 for mainnet; it's easy to find lists of prefixes for other networks.
  + It encodes the script `OP_DUP OP_HASH160 <that pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG`
* The P2SH format specified in BIP 13 and BIP 16. It follows the same structure as P2PKH addresses, but with a different version number and instead of a pubkey hash, it is a script hash.
  + It encodes the script `OP_HASH160 <that scripthash> OP_EQUAL`.
* The native witness address format introduced in BIP 173 It uses a completely different base-32 encoding (called Bech32) of data (5-bit witness version number) + (variable length witness program).
  + It encodes the script `OP_(witnessversion) <witness program>` (see BIP 141 for the semantics of such scripts).
  + The encoding was amended in BIP 350 to use a slightly different checksum algorithm for witness version 1 and up.

In general, if you're looking for specifications, the BIPs are where to look, except of course for protocol/standard aspects that predate the BIP process.

> **Comments:**
> **username_0**: oh man thank you again. I just base58 decoded mz6KvC4aoUeo6wSxtiVQTo7FDwPnkp6URG and I ended up with 6f cbc20a7664f2f69e5355aa427045bc15e7c6c772 f982e923. and then double hashed the first 21 bytes and got f982e923!  Just one correction, it doesn't appear that the whole script it base 58 encoded. everything by generaterawtransaction was in clear hex  
> **username_1**: No, just the version prefix byte and the pubkeyhash/scripthash are Base58 encoded. The rest of the script is implied by the version number.  

---

