5

What are hash functions used for in bitcoin?

I am looking for a comprehensive list.

1 Answer 1

8

In consensus rules:

  • There are script opcodes that perform hash operations on the stack:
    • OP_SHA256: SHA256
    • OP_RIPEMD160: RIPEMD160
    • OP_SHA1: SHA1
    • OP_HASH160: SHA256 followed by RIPEMD160 (very commonly used, in P2PKH and P2SH scripts)
    • OP_HASH256: double SHA256
  • The signature verification opcodes (OP_CHECKSIG(VERIFY), OP_CHECKMULTISIG(VERIFY), OP_CHECKSIGADD) compute a "sighash" operation on the spending transaction and output being spent.
    • In pre-segwit scripts, this is a double-SHA256 hash of a modified version of the spending transaction.
    • In witness v0 scripts, this is a double-SHA256 of a concatenation of specific data, including certain precomputed transaction-wide values (which themselves are double-SHA256 hashes).
    • In witness v1 (taproot) scripts, this is a tagged single SHA256 hash of a different concatenation of specific data, including certain precomputed transaction-wide values (which themselves are single SHA256 hashes).
  • In taproot spends, the signature check opcodes perform BIP340 (Schnorr) signature checking, which internally involves a tagged single SHA256 operation.
  • P2WPKH outputs are a SHA256+RIPEMD160 hash of the public key.
  • P2WSH outputs are a single SHA256 hash of the script.
  • In taproot script path spends:
    • a tagged single SHA256 operation is used to compute the tweak.
    • a tagged single SHA256 operation is used in each level of the script tree.
    • a tagged single SHA256 operation is used to compute the script leaf hash.
  • The transaction id (txid) and witness transaction id (wtxid) are computed as double-SHA256 hashes of the serialized transaction, without and with witness respectively.
  • The transaction merkle root of a transaction is computed by repeatedly applying double-SHA256 on groups of two txids.
  • The transaction witness merkle root in the coinbase is computed by repeatedly applying double-SHA256 on groups of two wtxids (excluding the coinbase transaction).
  • The block hash is the double SHA256 hash of the block header.

In the peer to peer protocol:

  • Every v1 P2P message has a checksum, which is a truncated double-SHA256 hash of the message's payload.
  • The encrypted v2 transport protocol introduced in BIP324 has no checksums anymore, but does involve several SHA256 hashes in its handshake and key setup.
  • The deprecated BIP37 (server side filtering) protocol uses Bloom filters, insertions to which use MurmurHash3.
  • The BIP158 (client side filtering) filters use a Golomb-coded set (GCS), insertions to which are done using SipHash-2-4.
  • BIP152 (compact blocks) uses 48-bit short ids for transactions, which are computed using SipHash-2-4, with a key that is computed using truncated SHA256 of the block hash plus a nonce.
  • Probably several more.

In wallets:

  • P2PKH and P2SH addresses contain a truncated double-SHA256 checksum, in addition to a SHA256+RIPEMD160 hash of the public key or script, matching the consensus ones.
  • P2WPKH, P2WSH, and P2TR addresses do not use a hash in their checksum, but do typically involve hashes matching the consensus side (SHA256 of script for P2WSH, SHA256+RIPEMD160 for P2WPKH, tweaks/leafs/script tree for P2TR, though it is possible to construct an untweaked P2TR output without any hashes).
  • The BIP32 standard for deterministic key derivation involves an HMAC-SHA512 step per tree level, and an HMAC-SHA512 step to go from seed to master key. Its xpub and xprv formats also involve a truncated SHA256+RIPEMD160 fingerprint, and a truncated SHA256 checksum.
  • The BIP39 standard involves PBKDF2 strengthening, using HMAC-SHA512 as hashing step, to go from mnemonic to seed. A truncated single SHA256 hash is also used as checksum.
  • Most ECDSA signing implementations use RFC6979 to generate the nonce, which involves several invocations of HMAC-SHA256.
  • The BIP340 default signing algorithm involves a tagged SHA256 hash to generate the nonce.
  • Signing involves computing all the hashes that will be relevant at verification time (leaf hashes, script trees, signature hashes, tweaks, script/pubkey hashes, hashes inside signature, ...; see above under consensus rules).

In the Lightning network

I'm not an expert on this matter, so I'll leave this for another answer (or, suggestions welcome).

In node implementations

The details are up to individual implementations, and not part of any protocol. I'm just listing things off the top of my head that are used in Bitcoin Core.

  • Secure random number generation often involves hashes to maintain an entropy pool, and/or to combine multiple entropy sources. Bitcoin Core uses its own SHA512-based implementation here.
  • Bloom filters are extensively used to remember what information peers already have, which involve hash functions. Bitcoin Core uses MurmurHash3 here.
  • Hash tables for various data structures inherently involve hash functions. Bitcoin Core uses SipHash-2-4 for most non-trivial hash tables.
1
  • 1
    Thanks for the detailed insight on how hash functions are integral to Bitcoin. Their versatility is truly impressive, from securing transactions to enabling the mining process. It’s remarkable how they ensure integrity and security in Bitcoin’s network, making the system robust and trustworthy. Hash functions are indeed a cornerstone of Bitcoin’s innovative architecture. Need to read more about it. Commented Nov 12, 2023 at 22:52

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.