Как генерируются сжатые PubKey?

Просто прочитайте это: https://bitcoin.stackexchange.com/a/1715/

Каков процесс создания сжатых ключей публикации через ECDSA?

интересно услышать ответы - я думал, что privkey и pubkey связаны только через ECDSA. Оба являются просто шестнадцатеричными числами... (точки на кривой тралала). И используя приватный ключ в кодировке base58, переходит к приватному ключу WIF. Добавлен дополнительный шестнадцатеричный «01» перед кодированием, у меня есть закрытый ключ WIF-c (сжатый), из которого я получаю сжатый открытый ключ. Жду ответов...

Ответы (2)

Не существует алгоритма для создания сжатых открытых ключей из ключей закрытых ключей. На самом деле, все внутренние вычисления, связанные с точками, выполняются с использованием координат x и соответствующих точек. yНет другого способа работать с точками, кроме как с помощью (x,y)координат. Сжатое представление точки полезно при передаче и хранении данных, поскольку для передачи точки требуется всего 33 байта, а не 65. Очень легко перейти от compressed -> uncompressedтого, когда возникает необходимость выполнять операции, связанные с точками, и еще проще перейти от uncompressed -> compressedпредставления. Чтобы ответить на ваш вопрос, вы должны сгенерировать открытый ключ, как обычно, с несжатым публичным ключом, и, когда вы закончите, искать четность или нечетность ключа.yкоордината. Если он четный, закодируйте только xкоординату с 0x02байтом префикса, а если он нечетный, то префикс 0x03. Чтобы вернуться compressed -> uncompressed(на самом деле я просто имею в виду найти исходную yкоординату), вы должны просто решить уравнение кривой:

y^2 = x^3 + a*x + b

В частности, для secp256k1 кривая, используемая в биткойнах, aравна нулю, что упрощает этот расчет, и есть сокращение: из-за свойства параметра кривой p, где p ≡ 3 mod 4мы можем получить yкоординату из xкоординаты, просто вычислив:

q = (p+1) * invmod(4)  mod p
y = powmod(y^2,q)      mod p

И вот мы yвернули исходную координату.

«для передачи точки требуется 33 байта, а не 65 байтов» - включает ли он префиксы для расчета точек?
Префикс используется только программным обеспечением для чтения и записи точки в виде данных. Он подсказывает программному обеспечению, какой тип ключа считывается, и если это сжатый ключ, какую из двух возможных yкоординат следует выбрать при распаковке точки.

С небольшой помощью arubi я нарисовал эту картинку. Синяя часть — это логика ECDSA. Ключи WIF и закрытые ключи связаны через кодирование/декодирование base58check. В зависимости от того, как вы предоставляете закрытый ключ (сжатый или несжатый), программное обеспечение решает, как создать открытый ключ и биткойн-адрес. Очевидно, биткойн-адрес будет отличаться для сжатых/несжатых ключей. С несжатыми ключами у вас есть 512-битный ключ публикации с компонентами x/y, тогда как сжатый ключ публикации может быть представлен только как компонент x. Программное обеспечение добавит префикс 04 для несжатого файла или 02 (если четный y) или 03 (если y нечетный) и будет использовать его в качестве входных данных для sha256/ripemd160 для создания хэша публичного ключа. На последнем шаге снова используется кодировка base58check с контрольной суммой.

privkey — ECDSA — биткойн-адрес

Пример (тестнет):

privkey Hex:   18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725
privkey WIF:   91msh178DnLBqFhbuYqazuUwWpKBkRQvgj8bggdWMp81nVp9PfM
privkey WIF-c: cNR4jZU2sR5goytD4wXT4aeKcbqGSekbxLxY69v8aryxTU1SMnJZ

pubkey hex без сжатия (04 + x + y):

04 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352 2CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6

pubkey сжат в шестнадцатеричном формате (02 + x, y = четный):

02 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352

соответствующие биткойн-адреса:

  (pubkey uncompressed): mfcSEPR8EkJrpX91YkTJ9iscdAzppJrG9j
  (pubkey compressed):   n3svudhm7bt6j3nTT9uu1A57Cs9pKK3iXW
Хорошая схема! Для полноты информации существует другой допустимый тип открытого ключа, отличный от сжатого и несжатого, который называется «гибридным». Он кодирует координаты xи y, а его длина составляет 1 + 64 байта (как несжатый публичный ключ), но байт префикса может быть либо , 0x07либо 0x06.
По сути, четность или нечетность байта префикса намекает на четность или нечетность yкоординаты, закодированной в ключе. Я не думаю, что гибридный ключ когда-либо использовался в основной сети, но, тем не менее, он является действительным публичным ключом и может отображаться в сценарии. WIF-кодирования гибридного закрытого ключа не существует, но любой может подписать и выкупить скрипт p2pkh с помощью такого ключа, и мы не узнаем, пока он не будет передан для траты. Включив его в вашу диаграмму, публичный ключ станет входом для третьего шага.
никогда не слышал об этих гибридных ключах, просто интересно, что такое приватный ключ в шестнадцатеричном представлении. Вы знаете какие-нибудь ссылки? Конечно, я хочу попробовать на testnet/regtest. Кстати: похожая диаграмма была в знаменитом « righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html » Кена Ширриффа. Это просто было против часовой стрелки - и не интуитивно для меня :-). Я сгладил его и добавил сжатую логику.
Закрытый ключ в виде числа в шестнадцатеричном формате точно такой же. Насколько я знаю, нет интерфейса для любого кошелька, который может обрабатывать гибридные ключи, поэтому вам придется создавать необработанную транзакцию самостоятельно. Это должно быть точно так же, как использование любого другого скрипта, содержащего контрольный знак. Кроме того, я не знаю, позволит ли даже политика testnet\regtest узлов такие расходы. Возможно, вам придется настроить политику на своем собственном узле и добывать ее самостоятельно.
Как генерируются сжатые PubKey?
СпросиСетьПолитика конфиденциальности1y, 0v