BIP 67 Sorted Multisig Keys Explained for Deterministic P2SH

BIP 67 Sorted Multisig Keys: This guide explains BIP 67 Deterministic Pay-to-script-hash multi-signature addresses through public key sorting in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

Why ordering changes the address

A multisig redeem script serialises M, each public key in sequence, N and CHECKMULTISIG. Reordering keys changes the script bytes, HASH160 commitment and P2SH address even though the same quorum could sign. For N keys there can be many permutations, multiplied further when compressed and uncompressed encodings are mixed.

Compressed keys only

BIP 67 accepts the 33-byte compressed public-key representation beginning with 02 or 03. An uncompressed key signals incompatible software and must not be silently compressed because that transformation changes the agreed script input. Participants should exchange and validate canonical public-key bytes before funding.

Binary lexicographic sorting

Implementations compare full compressed byte arrays from the first byte onward and order them ascending. Sorting displayed hexadecimal text gives the same result only when it faithfully represents those fixed-length bytes with consistent case and no prefixes. Locale-aware or natural-number sorting is incorrect.

Building the redeem script

After sorting, software inserts the threshold and ordered keys into a standard multisig script, then applies BIP 16 script hashing and network encoding. Every cosigner should derive the exact script and address independently. A matching display address is useful; a matching script hash and redeem-script bytes are stronger evidence.

Application convention, not consensus

P2SH hides the redeem script until spending, so the network cannot know whether a wallet followed BIP 67 at funding time. Enforcing a particular order globally would change validity expectations. Compatibility depends on every wallet participant and recovery tool intentionally applying the same convention.

Recovery and service independence

Sorted keys let a user with the threshold and participant public data reconstruct addresses without a specific service provider. The benefit disappears if origins, derivation paths or wrapper are missing. Modern descriptors can state sortedmulti explicitly and should be checked against historical P2SH scripts before migration.

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 67 removes key-order ambiguity from legacy P2SH multisig through one simple binary sort. That determinism is valuable only when compressed keys, threshold, origins and script wrapper are all preserved and independently verified.