1

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.

1

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.

2
  • 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
    Jun 13 at 5:04
  • 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. Jun 13 at 5:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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