BIP 80 Non-Coloured Voting-Pool Wallet Hierarchy Explained

BIP 80 Voting-Pool Wallet Hierarchy: This guide explains BIP 80 Hierarchy for Non-coloured Voting Pool Deterministic Multisig Wallets in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

The voting-pool custody idea

A voting pool distributes withdrawal authority across an m-of-n group rather than one online wallet. Deterministic public branches let members derive deposit scripts consistently. The hierarchy organised assets and cold-storage series, but the quorum, key ownership, withdrawal approval and recovery contract remained out-of-band responsibilities.

Four-level path

The proposed path was m / purpose prime / coin_type prime / series prime / address_index. Hardened derivation separated the first three levels; the final public child enabled sequential deposit keys. Every participant needed identical path, coin registry, series number, master-public material and multisig-script convention to reproduce an address.

Purpose and coin separation

Purpose encoded the BIP 80 namespace under BIP 43, while coin type reused the BIP 44 registry. Separate hardened asset branches reduced cross-coin address reuse and private-key exposure. A registered coin number did not define network parameters, script wrapper or supported recovery software by itself.

Series for FIFO cold storage

Deposits could move through numbered series so older funds were selected first for withdrawal and only a bounded collection of private keys needed temporary online access. The operational benefit depended on strict series activation, deposit cut-off and retirement records. Mixing series without evidence could strand funds beyond the active signing set.

Address index and script contract

The public address index incremented from zero and supplied keys to an agreed multisignature deposit script. BIP 80 did not fully encode that shared script contract in the path. Different key ordering, threshold, wrapper or compression produced different addresses even when every participant derived the same child index.

Closed status and recovery risk

The reference concept did not become a broad modern standard. A BIP 80-looking path imported into generic wallet software may derive keys but not reconstruct the voting-pool policy. Recovery requires the exact implementation, source revision, series state, participant xpubs and historical scripts rather than only one seed.

Historical recovery rehearsal

On isolated software, reproduce several known series and deposit addresses from sanitised fixtures. Take one signer offline, cross a series boundary and perform a small regtest withdrawal. Export descriptors where possible and compare scripts byte-for-byte before planning any migration to maintained multisig tooling.

Conclusion

BIP 80 documented a specialised deterministic cold-storage hierarchy, not a self-describing wallet backup. Recovering one safely requires the complete voting-pool contract, series history, key set and implementation evidence.