Ключи и цифровая подпись в Bitcoin
Отпечаток позволяет проверить содержание, но не отвечает на вопрос, кто разрешил потратить выход. Bitcoin решает эту задачу с помощью условий расходования, в которых могут использоваться цифровые подписи. В этом уроке построим модель проверки подписи и отделим владение ключом от личности читателя и права на конкретный курс.
Будем рассматривать учебного читателя, который распоряжается выходом в 80 000 сатоши. Он хочет перечислить 30 000 библиотеке. Настоящие ключи здесь не создаются, а криптографические операции не выполняются: цель — понять данные и проверяемое разрешение.
Секрет и открытая проверка
Приватный ключ — секретное значение, используемое алгоритмом подписи. Из него получают соответствующий открытый ключ. Открытый ключ позволяет проверить подпись, но при принятой стойкости алгоритма не позволяет восстановить секрет. Эта асимметрия делает возможной проверку разрешения участниками сети, которые не доверяют подписанту и не получают его ключ.
Подпись зависит от конкретного сообщения. В транзакции подписывается не произвольная надпись «я согласен», а вычисленное по правилам значение, связанное с её данными и выбранным режимом подписи. Если получатель, сумма или другие защищённые поля меняются, прежняя подпись перестаёт разрешать новое действие. Какие поля входят в вычисление, определяется типом расходования и параметрами подписи.
Можно записать абстрактную модель:
publicKey = derive(privateKey)
message = transactionSignatureDigest(transaction, input, mode)
signature = sign(privateKey, message)
allowed = verify(publicKey, message, signature)Это схема операций, а не готовая библиотека криптографии. Здесь особенно важно не перепутать проверяемое сообщение с полным текстом RPC-ответа. Узлы должны получить одно и то же значение по правилам протокола, иначе подпись не будет одинаково интерпретироваться.
Как меняется разрешение
Для нашей покупки подготовлен выход библиотеке на 30 000 сатоши и сдача читателю на 49 300. Оставшиеся 700 составляют комиссию. Если подписант рассчитывает сообщение в обычном режиме, который защищает выбранные входы и выходы, замена получателя библиотеки меняет подписываемое значение. Сеть не примет старую подпись как разрешение новой версии.
При этом существуют различные SIGHASH-режимы. Они позволяют ограничить набор данных, на который распространяется подпись. Это полезно для специальных протоколов, но означает, что фраза «подпись защищает всю транзакцию» требует уточнения. В обычном учебном маршруте выбираем ожидаемый стандартный режим и проверяем его. Не предлагаем пользователю подписать непрозрачный пакет с необычным режимом, объясняя это одной зелёной галочкой.
| Проверяемый вопрос | Источник ответа |
|---|---|
| Какое сообщение подписано? | Правило digest и режим подписи |
| Каким ключом разрешено действие? | Условие траты предыдущего выхода |
| Подходит ли подпись? | Алгоритм проверки |
| Правильный ли это заказ? | Серверная связь адреса и счёта |
Последний вопрос намеренно остаётся вне криптографии. Корректная подпись на переводе другому получателю не оплачивает нашу библиотеку. Подпись доказывает разрешение в установленной модели, а не добросовестность пользователя или соответствие перевода коммерческому договору.
Адрес не равен ключу
В простом объяснении иногда говорят, что пользователь отправляет средства «на публичный ключ». Однако обычный адрес может кодировать хеш, версию программы свидетеля или иной способ задания условия. В некоторых видах выхода сам открытый ключ появляется только при расходовании. Другие условия могут требовать нескольких подписей или допускать альтернативный путь.
Поэтому проверка должна следовать структуре конкретного предыдущего выхода. Нельзя взять произвольный открытый ключ из браузера и считать его получателем средств только потому, что он корректно проверил какую-то подпись. Узел сопоставляет данные расходования с условием выхода, который указан входом транзакции.
Точно так же цифровая подпись не устанавливает имя человека. Один читатель может использовать много ключей; одним условием могут управлять несколько участников. В нашем сайте личный кабинет идентифицируется собственной моделью сессии. Если позже добавляется вход с подписью, сообщение должно содержать домен, назначение, срок и одноразовое значение. Это отдельный протокол авторизации, а не повторное использование транзакционной подписи.
Подписант и наблюдатель
Разделим библиотечную инфраструктуру. Наблюдатель знает публичные условия получения и отслеживает входящие выходы. Подписант располагает приватным материалом либо обращается к защищённому устройству. Наблюдатель может подготовить транзакцию, но подписант должен самостоятельно проверить получателя, сумму и сдачу перед разрешением.
Такой разделённый маршрут не решает задачу автоматически. Если подписант слепо подписывает всё, что прислал веб-сервер, ограничение превращается в формальность. Устройство или оператор должны видеть содержательное действие. В учебном договоре для возврата укажем номер заявки, согласованную сумму и новый адрес, подтверждённый получателем. Подпись применяется только после сравнения подготовленного расходования с этой заявкой.
Приватный ключ нельзя помещать в URL, клиентский код, журнал ошибки или Markdown-пример с реальными средствами. Даже тестовая конфигурация должна явно отмечать, что значения предназначены только для локальной сети. Мы избегаем фиксированного общего секрета для всей серии: читатель должен получить свой материал в будущей лаборатории, а не переносить общеизвестный ключ в другую сеть.
Почему не стоит писать криптографию вручную
Корректность подписи зависит не только от математической формулы. Важны выбор случайных или детерминированных значений, кодирование, проверка границ, обработка точки и защита реализации. Ошибка генерации вспомогательного значения может раскрыть секрет даже при правильном названии алгоритма. Учебная схема не является основанием создавать собственный подписывающий сервис.
В Bitcoin применяются разные правила подписи для исторических и новых типов расходования. Taproot использует Schnorr по BIP 340, тогда как многие прежние выходы используют ECDSA. В обоих случаях библиотеке нужен совместимый проверенный инструмент и явный профиль сети. Поздний урок рассмотрит особенности Schnorr без ложного вывода, что переход алгоритма отменяет требования к хранению ключей.
Открытые спецификации BIP 143 и BIP 340 показывают, насколько конкретны правила вычисления и проверки. После этого урока наша модель разрешения содержит ключ, сообщение, подпись и условие предыдущего выхода. В следующем разборе определим, как адрес сообщает нужный тип условия и сеть.