Я не считаю, что это было бы "неправильно" чтобы сделать это, но я хотел бы использовать HMAC-256 (private_key, hash_to_sign) над SHA256 (private_key || hash_to_sign) по целому ряду причин. Подробнее об этом ниже. Автор RFC 6979 принял очень осторожный подход и несколько раундов HMAC в сочетании с инициализацией предназначены для упрочнения от утечки информации в том случае, если частичные компромиссы базового алгоритма происходят в будущем. Хорошая безопасность смотрит не только сегодняшние атаки векторов, но вероятные будущие векторы атак на основе детального понимания того, как безопасность алгоритма может ухудшиться через криптоанализ. Я знаю достаточно, чтобы знать "не свернуть свой собственный крипто", Стандарт становится более сложным, поскольку он предназначен для обработки любого HMAC, любого размера дайджеста, любой ключа, любые параметров кривых, а любое сообщения дайджеста. Для Bitcoin все те статичны многие из краевых случаев не представляется возможным. Это позволяет реорганизовать стандарт производить упрощенный, который работает только с "Bitcoin" (256 бит хэша, 256 битых секретный ключ, secp256k1 кривые, HMAC-SHA256). Если взять простую реализацию и добавить в различном застывании я сомневаюсь, что это будет намного проще, чем реорганизованный RFC6979.

Почему HMAC-хэш над простым хэш? HMACs не является уязвимым для атак расширения длины, и они могут уменьшить столкновения уязвимости основного хэша. В качестве примера MD5 криптографический сломан, но HMAC-MD5 еще надежная, без прообраза или столкновения атак (быстрейшая атака грубой силы).  Я бы не рекомендовал никому использовать HMAC-MD5 только предвидение в тот день, когда SHA-2 может быть следующей MD5.

Одна из причин, чтобы использовать RFC6979 вместо некоторых "свернуть свой собственный" является повторяемость. Если ваше аппаратное устройство реализует RFC6979 посторонние может проверять его при наличии аппаратных и другой совместимый клиент RFC6979 генерировать ту же операцию и сравнения подписей. Если устройство использует детерминированные подписи и реализует BIP32 с прилагаемого семени пользователя становится намного труднее построить в лазейки, чтобы украсть у пользователя. Хотя любые пользовательские реализации также можно было бы проверить, если у вас есть пять различных реализаций, что просто означает, что в пять раз больше работы, чтобы проверить их все. Мы могли бы придумать упрощенную детерминированной подписи протокола BIP и призываем всех разработчиков стандартизировать вокруг, что, тем не менее, даже в случае успеха это очень маловероятно, что "BIP XYZ" никогда не будет реализован в любых основных криптографических библиотек. RFC6979 некоторый прогресс на этом фронте. Надувной замок в настоящее время поддерживает его и с достаточно принятия, OpenSSL, .Net Framework, моно и т.д. будет также. Это будет означать более широкое сообщество, глядя на кодовом и больше глаз всегда лучше.

Простой вариант: Когда я смотрю на существующий стандарт я смотрю на него с "Есть ли причина, почему этот стандарт не может быть использован?"  Для RFC6979 единственно возможный ответ "это слишком сложно" и для меня это не является достаточным, чтобы выбросить его в пользу другого стандарта. Большинство пользователей (или даже разработчики) не будет реализовывать RFC6979 вручную, они будут надеяться, будет с использованием хорошо проверенных библиотек. Тестовые векторы и детерминированный характер в сочетании с эффектом лавинного сделать это удаленный шанс, что вы могли "понять неправильно" и до сих пор проходят юнит-тесты.

Конечно, эта тема не была бы полной без: