До 2012 года создание резервной копии кошелька было бесконечной задачей. Оригинальная программа хранила сто готовых ключей в файле и использовала их по одному; после сотого резервная копия, сделанная в первый день, уже не содержала новых ключей, и те, кто на неё полагался, узнавали об этом самым неприятным образом. Решение этой проблемы — причина существования двенадцати слов.
Предложение поступило в феврале 2012 года от Питера Вилле и называется BIP-32. Идея проста для объяснения: вместо того чтобы генерировать каждый ключ отдельно, генерируется единственное семя, и все остальные ключи выводятся из него, всегда по одному и тому же пути. Резервная копия, сделанная сегодня, будет актуальна и через десять лет, потому что ключи уже определены — они просто ещё не были рассчитаны.
Первый шаг — это взять семя из 512 бит из предыдущего урока и пропустить его через HMAC-SHA-512. Получаются шестьдесят четыре байта, которые делятся пополам: тридцать два слева — это мастер-ключ, а тридцать два справа — это новая вещь, код цепочки. Этот второй кусок предотвращает то, что знание одного дочернего ключа может что-то сказать о его "сестрах".
Вывод дочернего ключа — это всего лишь одна операция: соедините оба, добавьте номер дочернего ключа, пропустите через ту же функцию. Получается новый приватный ключ и новый код цепочки, готовые для генерации "внуков". Это дерево из миллиардов ключей, где любая ветвь может быть пересчитана из семени, и ни один из них не нужно хранить.
Из этой структуры рождается самая полезная часть — расширенный ключ. Приватная версия записывается как xprv и выводит всё. Публичная версия записывается как xpub и выводит только публичные ключи — то есть адреса — без возможности тратить. Магазин может установить xpub на сервере, генерировать новый адрес для каждого клиента и не иметь на этой машине ничего, что позволило бы перемещать монеты.
Эта удобство требует осторожности. xpub раскрывает все адреса, которые этот аккаунт будет иметь всегда, и, следовательно, всю историю и весь баланс. Он не тратит, но всё рассказывает. Отправка xpub кому-то — это открытие всего выписки, и закрыть её потом невозможно.
Существует ещё одна математическая ловушка, и именно из неё происходит апостроф в путях вывода. В обычном выводе, тот, кто имеет xpub родителя и может получить один приватный дочерний ключ, может вычислить приватный ключ родителя — и, с ним, всю семью. Укреплённый вывод разрывает этот обратный путь: он использует приватный ключ родителя в расчёте, и поэтому xpub просто не может производить укреплённых потомков.
Теперь путь перестаёт быть загадкой. В m/84'/0'/0'/0/5, m — это корень. 84 с апострофом — это цель, которая указывает, какой стандарт адреса будет использоваться, и это тема следующего урока. Следующий 0 — это валюта, и Bitcoin — это ноль. Третье число — это счёт, что позволяет разделить личные финансы и финансы бизнеса в рамках одного семени. Первые три уровня всегда укреплены, именно по причине, описанной в предыдущем параграфе.
Два последних уровня не укреплены, по практическим причинам. Четвёртый уровень равен 0 для адресов, которые вы даёте тем, кто будет платить, и 1 для сдачи, которую кошелёк создаёт самостоятельно; пятый — это счётчик, который увеличивается на единицу. Поскольку эти два уровня общие, xpub счёта вычисляет их все — что и нужно магазину в примере.
Ежедневная деталь завершает урок. При восстановлении семени кошелёк не сканирует всё дерево: он ищет адреса по порядку и останавливается после нахождения двадцати подряд без движения. Этот предел в двадцать — это соглашение, и тот, кто вручную сгенерировал адрес далеко впереди счётчика, может увидеть, как деньги исчезают с экрана, не исчезая из блокчейна.
Остаётся объяснить первое число пути, так называемую цель. Именно оно решает, будут ли адреса, начинающиеся с 1, с 3 или с bc1, отображаться для одного и того же семени — и почему два честных кошелька показывают разные балансы для одних и тех же двенадцати слов. В следующем уроке — стандарты 44, 49, 84 и 86.