BIP 124 HD Script Templates Explained

This guide explains BIP 124 Hierarchical Deterministic Script Templates in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

The interoperability target

Wallets could derive keys correctly yet assemble different scripts because path roles, key ordering and policy templates differed. BIP 124 aimed to describe key groups with a free index and insert derived keys or hashes into a common script expression so independent wallets produced matching destinations.

Keys and key groups

An individual key combined a BIP 32 path with index k. A key group collected several parent paths evaluated at the same k, useful for repeated multisignature policies. Every participant still needed the same network, compressed-key convention, hardened steps and gap strategy before the group was deterministic.

Canonical sorting

The proposal called for lexicographic sorting of each derived key group so permutations did not change script semantics or reveal role order. Its source left sorting conventions unfinished. BIP 67 later specified deterministic public-key sorting for multisignature scripts, but that does not complete every BIP 124 template rule.

Placeholders and operations

Templates inserted placeholders into opcode sequences and could insert operations such as HASH160 of a derived key. Examples covered two-of-three multisig and policies combining a superuser path with a group. A readable expression still required a precise binary encoding, type system and validation limits to be interoperable.

Incomplete encoding boundary

The specification explicitly retained unfinished items for encoding and sorting details. Two developers can implement the examples and still disagree on edge cases. A BIP number and illustrative notation do not justify storing funds when the interchange format lacks complete canonical rules and test vectors.

Modern descriptor context

Output script descriptors now provide maintained checksummed expressions for many wallet script policies and key origins. Miniscript adds structured policy analysis for supported script families. They are not byte-for-byte continuations of BIP 124, so migration must reconstruct and verify addresses rather than rename old metadata.

How specialists test it

Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.

Conclusion

BIP 124 identified a real need for deterministic script-policy exchange, but its unfinished encoding prevented it becoming a safe standalone standard. Modern deployments should use maintained descriptors and verified script bytes.