BIP-32 — Bitcoin Improvement Proposal 32, авторства Питера Уилле в 2012 году — определяет иерархическую детерминированную (HD) структуру кошелька. Из одной мастер-сид BIP-32 позволяет кошельку выводить неограниченное дерево дочерних ключей, каждый из которых может в свою очередь производить собственных детей. Результат — детерминированное отображение: одна сид, одно дерево, каждый раз, на любом кошельке, следующем стандарту.
Зачем существуют HD-кошельки
До BIP-32 Bitcoin-кошельки генерировали каждый приватный ключ независимо и хранили каждый ключ в файле БД (знаменитый wallet.dat). Бэкап Bitcoin Core кошелька в 2011 году означал бэкап файла каждый раз, когда вы генерировали новый адрес. Потеряли файл — потеряли каждый ключ, сгенерированный после последнего бэкапа.
BIP-32 свернул это в один бэкап: мастер-сид. Каждый ключ, который кошелёк сгенерировал или сгенерирует, достижим из сид. Мнемоническая фраза, которую вы записали один раз в день первый, остаётся валидной навсегда.
Форма дерева
Мастер-сид производит мастер extended private key (xprv) и соответствующий extended public key (xpub). Из них кошелёк выводит дочерние ключи через нумерованные индексы. Путь вроде m/44'/0'/0'/0/5 говорит: из мастера, возьмите ребёнка 44' (hardened), затем ребёнка 0' (hardened), затем 0', затем 0, затем индекс 5. Апостроф маркирует "hardened" деривацию, которая предотвращает кому-либо, у кого есть только xpub, вычисление приватных ключей.
Возможность xpub
BIP-32 позволяет вам делиться extended public key (xpub) без раскрытия соответствующих приватных ключей. Watch-only кошельки и аудит-инструменты используют это: импортируйте xpub в чистое устройство, видите каждый адрес и каждый баланс, и никогда не раскрываете способность подписывать. Это механизм за watch-only режимом Sparrow Wallet и за большинством бухгалтерских инструментов, которые читают on-chain историю без обладания ключами подписи.
Что это означает для российского холдера
Вы обычно никогда не касаетесь BIP-32 путей напрямую. Кошелёк это абстрагирует. Что вам нужно понять — это импликацию совместимости: если вы мигрируете с Ledger Live на Sparrow, или с MetaMask на Rabby, новый кошелёк покажет те же адреса, только если он следует тому же пути деривации. UI импорта кошелька обычно с этим справляется, но если вы когда-либо видите неожиданный нулевой баланс после миграции, причина почти всегда — несоответствие пути деривации — не утерянный ключ.
Дополнительное чтение: BIP-39, BIP-44, Derivation path.