HD Wallet

Аліса відкриває екран отримання, і гаманець показує адресу. На неї надходить 10 000 сатоші — дрібних одиниць біткоїна. Для наступного платежу застосунок пропонує іншу адресу, на яку приходить 20 000 сатоші. Якщо це її єдині ще не витрачені надходження, гаманець покаже загалом 30 000 сатоші. Нова адреса не створила окремого рахунку, а попередні кошти нікуди автоматично не перемістилися. Застосунок керує ключами для обох надходжень. HD Wallet робить це зручним. HD означає Hierarchical Deterministic: ієрархічний, бо ключі утворюють розгалужену структуру, і детермінований, бо однакові сід і шлях дають однакові ключі, зокрема під час відновлення. Шлях — це послідовність чисел, що вказує програмі, яку гілку та який ключ обчислити. Для звичайного отримання платежів Алісі зазвичай не потрібно з ним працювати, але при відновленні гаманець має використовувати правильні шляхи. Одна копія початкового секрету може охоплювати й майбутні адреси; налаштування гаманця все одно слід зберігати. Нові адреси допомагають уникати повторного використання адрес, але самі по собі не гарантують анонімності. [1] [12]

Розширений публічний ключ, який зазвичай називають xpub, дозволяє обчислювати публічні ключі частини цієї структури. Він не містить приватних ключів, потрібних для підписання платежів. Тому самого xpub недостатньо для витрачання; щоб створювати конкретні адреси, застосунок також має знати їхній формат. Гаманець watch-only з відповідним xpub може створювати адреси й відстежувати платежі без ключів підпису. Проте витік xpub може пов’язати минулі й майбутні адреси цієї гілки, баланси та транзакції. Діліться лише потрібною гілкою. Навіть правильний xpub не завадить скомпрометованому комп’ютеру показати чужу адресу. Перевіряйте адресу отримання на надійному пристрої підпису, який знає цей гаманець. [1] [12] [14]

Магазин може створювати окрему адресу для кожного замовлення. Сайту потрібні адреси, але не ключі для витрачання виручки. BIP32 дозволяє відокремити гілку отримання від решти гаманця. Пропозицію написав Pieter Wuille; дата присвоєння — 11 лютого 2012 року. Це стандарт гаманців, а не правило консенсусу. Слова резервної копії BIP39, типи скриптів і повна процедура відновлення належать до інших рівнів. [1] [11] [12]

BIP32 додає до ключа 256-бітовий chain code — 32 байти для подальшого виведення. Приватна форма складається зі скаляра k кривої secp256k1 і chain code c; публічна використовує K = point(k) та те саме c. Головний ключ створює HMAC-SHA512 з точним рядком «Bitcoin seed» як ключем функції та сідом як даними. Ліві 32 байти — кандидат приватного ключа, праві 32 — chain code. Нуль або значення не менше за порядок кривої n робить головний ключ недійсним. [1]

Виведення — це обчислення, а не пошук у збереженому списку. Є звичайне виведення та виведення hardened. За звичайного наступні публічні ключі можна обчислити з батьківського розширеного публічного ключа; крок hardened потребує батьківського розширеного приватного ключа. CKDpriv обчислює I = HMAC-SHA512(cpar, data), ділить результат на IL та IR і додає parse256(IL) до батьківського приватного ключа за модулем n. IR стає новим chain code. Звичайна гілка використовує serP(Kpar) || ser32(i), hardened — 0x00 || ser256(kpar) || ser32(i), де i ≥ 2^31. CKDpub створює лише звичайні публічні гілки, додаючи point(parse256(IL)) до Kpar. Інший номер гілки змінює подальші ключі. [1]

Із xpub можна виводити публічні ключі, доки шлях не перетинає крок hardened. Є важливий компроміс: батьківський xpub разом із витоком приватного ключа звичайного дочірнього вузла дозволяє обчислити батьківський приватний ключ. Під загрозою опиняються й інші його гілки. Hardened блокує це зворотне обчислення, але не захищає від крадіжки сіду, неякісного генератора випадкових чисел чи підтвердження шкідливої транзакції. [1]

У mainnet стандартний публічний запис починається з xpub, приватний — з xprv; їхні версії 0x0488B21E та 0x0488ADE4. До Base58Check запис має 78 байтів: версія 4, глибина 1, відбиток батьківського ключа 4, номер дочірнього ключа 4, chain code 32 і дані ключа 33. Результат містить 111 символів. Короткий відбиток допомагає зіставляти ключі, але не доводить ідентичність. Префікси ypub/zpub зі SLIP132 іноді вказують тип скрипту; сама заміна префікса не змінює ключі чи правила гаманця. [1] [9]

BIP43 відвів перший рівень hardened для призначення. BIP44 використовує m / 44' / coin_type' / account' / change / address_index. Після рахунку йде гілка 0 для отримання або 1 для решти, потім номер адреси. Апостроф чи h означає індекс, збільшений на 2^31. Пошук BIP44 має gap limit 20: зупиняється після 20 послідовних невикористаних адрес отримання. BIP48 описує Multisig, BIP84 — призначення 84' для нативного SegWit, BIP86 — 86' для Taproot з одним ключем. Ці домовленості не записані в самому сіді й не нав’язуються вузлами. [2] [3] [4] [5] [6]

Самі ключі не визначають скрипт, що захищає монети. Output Descriptor може записати походження ключів, шляхи, конструкцію на кшталт wpkh(), потрібну кількість підписів, інших учасників Multisig і контрольну суму. Multipath descriptor може об’єднати гілки отримання та решти. Сід одного учасника не відновить інші xpub чи спільні правила. Збережіть також перевірений публічний дескриптор або експорт конфігурації та захищайте їхню конфіденційність. Якщо експорт містить приватні ключі, ставтеся до нього як до секрету. [7] [8] [10] [13]

Сід дозволяє знову вивести ключі, але застосунку потрібні формат сіду, використана BIP39 passphrase, мережа, тип скрипту, coin type, рахунки, обидві гілки та діапазон пошуку. Multisig також потребує спільної конфігурації. Нульовий баланс не обов’язково означає втрату монет: причина може бути в іншому шляху. Безпечний тест на надійному пристрої має знайти правильні UTXO, тобто ще не витрачені виходи транзакцій, і перевірити підпис. Ніколи не вводьте справжній сід або слова резервної копії у вебінструмент чи звичайний комп’ютер онлайн. [3] [7] [10] [11]

BIP32 враховує й рідкісні недійсні результати: parse256(IL) ≥ n, нульовий дочірній приватний ключ або публічну точку на нескінченності. Тоді пробують наступний індекс. Під час відновлення частіше бракує шляху, гілки решти або підтримуваного типу скрипту. Перед переходом перевірте знаходження монет і невеликий тестовий переказ. Зберігайте початкову копію та конфігурацію, доки новий спосіб не запрацює. xprv дає змогу отримати ключі для підписання, xpub розкриває фінансові зв’язки, а дескриптор описує побудову гаманця. [1] [7] [9] [10]