A Bitcoin multisig address is easy to misread. It looks like a place where several keys meet, but the address you actually share with your co-signers is not a hash of those public keys. It is a hash of a script—the redeem script of a pay-to-script-hash output, or the witness script of a native SegWit output—and that script is assembled from the keys, a signature threshold, an ordering rule and a wrapping rule. Change any one of those inputs and the destination changes, even when every participant imported identical keys.
This is why two wallets can claim to describe the same two-of-three setup and still hand out different receiving addresses. The productive question is narrower than “did everyone import the keys?” It is whether everyone built the same script from the same derived keys.
The ordering disagreement has a formal answer. BIP67, titled “Deterministic Pay-to-script-hash multi-signature addresses through public key sorting,” requires compressed public keys and lexicographic sorting of their binary representations before the redeem script is constructed. That one rule turns the many possible orderings of a key set into a single canonical order, so the same key set and threshold always map to the same P2SH address. It is equally explicit about what it will not tolerate: uncompressed keys are incompatible, and a conforming implementation should not quietly compress a key a participant handed over. A key-encoding disagreement is something to surface, not to normalize away.
BIP383, the multisig descriptor specification, makes the ordering choice visible in wallet software. A multi(k, A, B, C) descriptor preserves the order in which the keys were written, while sortedmulti(k, A, B, C) sorts them lexicographically when the script is produced. The timing is the subtle part: the sort runs after extended-key derivation. Alphabetizing xpub labels by hand is not equivalent, and it will not repair a disagreement over which child keys actually entered the script. When several key expressions are extended keys, they use the same child index and move in lockstep.
When two coordinators disagree on an address, ordering is only one candidate cause. Compare the inputs from the outside in before changing any configuration: the network, the complete key expressions and the threshold; then the account derivation, the receiving-or-change branch and the exact address index rather than each tool’s “next address”; then the derived child keys and their encodings; then their order in the script; finally the complete enclosing descriptor. BIP48 supplies the shared vocabulary for the derivation half. It fixes the path as purpose, coin type, account, script type, change and address index, separating native P2WSH at m/48'/0'/0'/2' from nested P2SH-P2WSH at m/48'/0'/0'/1', with branch 0 for receiving and branch 1 for change. Two wallets that agree on everything except the branch will diverge at the very first address, and comparing only the final index will never reveal it.
The wrapping layer is a separate check. BIP383 permits multi() and sortedmulti() at the top level or inside sh() and wsh(), including nested constructions, so agreement on the inner multisig expression does not by itself mean agreement on the destination script. The conclusion to keep is deliberately modest. A reproducible address is a bookkeeping property, not a security certificate: two wallets that show the same address have proved they built the same script, not that the intended signers can complete a spend or that the address belongs to the party you believe it does. Switching a funded wallet from multi() to sortedmulti() is not a cosmetic fix, because a change in key sequence changes the script and therefore the address. Preserve the original policy while you diagnose.
Source: BTCUSA.