Адреса со скрытым ключом KIP-22 дошли до кошельков раньше правил

KIP-22 — предложение Ори Ньюмана по адресам, которые скрывают открытый ключ до момента траты, — за несколько дней прошло путь от идеи до основной сети. Пользователи уже отправляют монеты на новый тип адресов в основной сети Kaspa, а свод правил, по которому любой кошелёк сможет восстановить эти монеты по фразе восстановления, всё ещё пишется. Для тех, кто хранит ключи самостоятельно, вся история — именно в этом разрыве между внедрением и спецификацией.

Что меняет KIP-22

Обычный адрес Kaspa показывает свой открытый ключ любому, кто на него посмотрит. В принципе достаточно мощный квантовый компьютер мог бы вычислить по этому открытому ключу закрытый. Новый тип адреса показывает лишь отпечаток ключа и делает его известным только в момент траты. Внешнее давление здесь вовсе не гипотетическое: Europol, полицейское агентство ЕС, в недавнем отчёте предупредил, что «как только открытый ключ раскрыт, он навсегда остаётся уязвимым для будущей квантовой расшифровки».

Различить адреса просто: новые начинаются с kaspa:p, а не с привычного kaspa:q.

От сетевого предложения к правилам для кошельков

Сначала Ори опубликовал идею как KIP-22 — Kaspa Improvement Proposals, стандартный трек для изменений самой сети. Но KIP-22 не требует никаких изменений в сети. Поскольку речь идёт о соглашении касательно того, как кошельки и приложения работают с ключами, IzioDev предложил перенести его на трек KCC — единый свод правил для кошельков и приложений, — и Ори согласился.

Гаурав Рана, известный как BitcoinsSG, раньше выдвигал похожую идею — без части про пути ключей — и присоединился в качестве соавтора. Заявленная мотивация Ори была практической, а не рекламной: «Я видел, как многие, как и ты, ищут и реализуют решения, и хотел написать для этого каноническое решение». Иначе говоря, предложение существует затем, чтобы десяток несовместимых реализаций не разошлись молча.

Почему у аккаунтов со скрытым ключом свой путь

Одна фраза восстановления может породить бесконечное число адресов. Кошелёк находит ваш, следуя пути вывода — по сути, почтовому адресу для ключей. Черновик выделяет аккаунтам со скрытым ключом отдельный путь, в стороне от обычных аккаунтов, и это разделение не косметическое.

Ори пояснил, что без него обычный кошелёк «может раскрыть открытые ключи» аккаунта со скрытым ключом. Aglovale добавил более резкую формулировку: если вы уже поделились расширенным открытым ключом обычного аккаунта, все ключи под ним уже раскрыты, и адрес со скрытым ключом на той же ветке окажется раскрытым ещё до того, как с него кто-то потратит. Ори согласился.

Со стороны кошельков IzioDev хотел того же разделения, чтобы избежать ошибок в обратную сторону: «Я не хочу по ошибке воспользоваться своим p2pkh-аккаунтом и, например, отправить сдачу на p2pk». Кошелёк, смешивающий два режима, потратил бы со счёта со скрытым ключом и утёк ключ, который обязан был держать в тайне.

Номер пока не утверждён

Эту часть ранним пользователям стоит прочитать дважды. В первом черновике аккаунты со скрытым ключом шли под 22'. Когда предложение перешло на трек KCC, номер стал заглушкой — XXXX' — с пометкой заменить его, как только номер KCC будет определён. Он не определён до сих пор.

Сначала Ори присвоил предложению KCC-3. С тех пор KCC-3 превратился в более широкий план организации ключей в кошельках, написанный IzioDev вместе с Ори. Он добавляет уровень для типа подписи, но только для новых видов аккаунтов: пути, которыми кошельки пользуются сегодня, 44' и 45', остаются как есть. Свод правил для скрытых ключей должен лечь поверх отдельным KCC.

Оба отрабатывали это в открытом режиме. Когда Ори предложил разделить типы подписи на существующих путях, IzioDev возразил: «Я не любитель вводить ещё один устаревший путь для кошельков. Люди и так в растерянности, а мы сделали лишь одно несовместимое изменение». После обсуждения IzioDev согласился, что тип подписи должен быть частью самого пути — «я согласен с тобой», — но только для новых типов аккаунтов. Затем в ревью Ори на GitHub прозвучала просьба навести порядок: оставить 44' и 45' в покое, а части про мультисиг вынести в последующий KCC. IzioDev ответил, что это «звучит хорошо». Отдельный разработчик кошельков задокументировал, как сегодняшние мультисиг-кошельки на Rusty Kaspa упорядочивают свои ключи, и предложил оформить это так, чтобы последующий KCC мог ссылаться на это при восстановлении.

Ловушка раннего внедрения

Кошельки, которые успели раньше, используют путь 22' из первого черновика. Если итоговый свод правил присвоит аккаунтам со скрытым ключом другой номер, кошелёк, следующий только финальной версии, не станет заглядывать в 22'. Восстановите в таком кошельке фразу восстановления — и баланс может показать ноль.

В этом случае ваши монеты не потеряны. Они по-прежнему лежат под 22', и любой кошелёк с поддержкой этого пути снова их найдёт. Это неприятный сюрприз, а не потеря средств, — но для того, кто хранит ключи самостоятельно, нулевой баланс после восстановления — ровно тот шок, который толкает на панические и необратимые решения.

Практические правила на время, пока правила не утверждены:

• Оставайтесь в том кошельке, который создал адрес со скрытым ключом, пока KCC не станет финальным.
• Храните фразу восстановления в надёжном месте и держите резервную копию самого кошелька, если она у него есть.
• После траты с адреса со скрытым ключом не используйте его повторно — трата раскрывает ключ, и он уже не скрыт.
• Не передавайте расширенный открытый ключ своего аккаунта — тот мастер-ключ, который некоторые приложения запрашивают, чтобы отслеживать баланс. Он открывает все открытые ключи аккаунта.

Насколько это реально помогает?

Честный скептицизм — часть обсуждения. Ханс Муг, работающий над vprogs, лично сомневается, что квантовые компьютеры когда-нибудь взломают криптографию с открытым ключом на реалистичных размерах ключей. И всё же Муг назвал KIP-22 «действительно простым и недорогим способом значительно снизить квантовую угрозу для пользователей Kaspa», добавив, что это «не "полное" постквантовое решение».

Уязвимый момент — трата. Ваш ключ виден, пока транзакция подтверждается, поэтому атакующему понадобился бы квантовый компьютер, достаточно быстрый, чтобы взломать его в это окно. «На Kaspa это значит всего несколько секунд», — написал Муг. Это структурное преимущество времени блока в Kaspa, и стоит сказать прямо: то же самое свойство, которое делает подтверждение быстрым, сокращает и окно уязвимости, но не сводит его к нулю.

Ори считает, что Kaspa в конечном счёте добавит нативную поддержку постквантовых подписей, и называет это соглашение «лишь первым шагом». Адресация со скрытым ключом — это мера смягчения, которую сегодня может внедрить любой кошелёк без форка, а не готовый ответ на вопрос.

Что это значит для держателей KAS

Для держателей KIP-22 — недорогое улучшение гигиены: если не публиковать открытый ключ, долгосрочная уязвимость снижается для адресов, с которых вы ещё не тратили. Для майнеров и операторов, которые делились расширенными открытыми ключами ради бухгалтерии, «просмотрных» схем или координации мультисига, компромисс острее — эти ключи открывают всё под собой, так что адрес со скрытым ключом, размещённый на уже расшаренной ветке, не даёт ничего.

Открытый вопрос — ровно тот, что в заголовке: обнаружение по фразе восстановления. Соглашение об адресах стоит ровно столько, сколько экосистема кошельков сможет отыскать его спустя пять лет, а номер вывода пока остаётся заглушкой. Пока KCC не зафиксирован, самое безопасное поведение — нудное: тот же кошелёк, хорошие резервные копии, никакого повторного использования адресов, никакой передачи расширенных открытых ключей.

Если вы храните ключи сами, эта нудная часть и есть вся работа. Инструменты вроде Kaspa Safe и остальная архитектура Kaspa Forge существуют, чтобы сложнее было ошибиться в нудной части, а не чтобы заменить дисциплину.