2 ^ 256 закрытых ключей

[FontSeli]

~Даже если у двух конкретных ключей один хэш, им может соответствовать разный набор P2PK и raw multisig выходов, поскольку при их создании не используется функция hash160. ~

Темный лес. Я всегда думал что если хэш одинаковый то и ключ полностью одинаковый, иначе были бы отличия в хэше. Не понимаю.

[Balthazar]

~Даже если у двух конкретных ключей один хэш, им может соответствовать разный набор P2PK и raw multisig выходов, поскольку при их создании не используется функция hash160. ~

Темный лес. Я всегда думал что если хэш одинаковый то и ключ полностью одинаковый, иначе были бы отличия в хэше. Не понимаю.

Ни одна хэш функция, даже будучи криптографической и не имеющей багов, не может взять энтропию из воздуха.

[zasad@]

~Даже если у двух конкретных ключей один хэш, им может соответствовать разный набор P2PK и raw multisig выходов, поскольку при их создании не используется функция hash160. ~

Темный лес. Я всегда думал что если хэш одинаковый то и ключ полностью одинаковый, иначе были бы отличия в хэше. Не понимаю.

Ни одна хэш функция, даже будучи криптографической и не имеющей багов, не может взять энтропию из воздуха.

Можно както объяснить на пальцах, чтобы простому обывателю тоже было понятно.

[igor72]

Я всегда думал что если хэш одинаковый то и ключ полностью одинаковый, иначе были бы отличия в хэше. Не понимаю.

Тут дело не в том, что хеш-функция может быть неидеальна и давать коллизии, а в том, что размерность хеша меньше размерности ключа (20 байт против 32). То есть это как пытаться 20 яблок положить в 10 корзин - по одному в корзину поместить никак не получится. Поэтому на каждый немультиподписной адрес приходится в среднем 2⁹⁶ приватных ключей. Если представить емкость размером с Землю, заполненную горохом, то количество горошин примерно и будет равно количеству приватников, "отпирающих" каждый адрес ). И тем не менее, я не слышал, чтобы были найдены хотя бы два ключа, дающих одинаковый хеш.

[Balthazar]

Тем не менее, я не слышал, чтобы были найдены хотя бы два ключа, дающих одинаковый хеш.

В биткойне такого действительно не было. Но случалось в альткойнах, авторы которых брались за изобретение хэш функции с нуля, не имея соответствующего образования. К примеру, хэш функцию в IOTA взламывали.

[FontSeli]

~Даже если у двух конкретных ключей один хэш, им может соответствовать разный набор P2PK и raw multisig выходов, поскольку при их создании не используется функция hash160. ~

Темный лес. Я всегда думал что если хэш одинаковый то и ключ полностью одинаковый, иначе были бы отличия в хэше. Не понимаю.

Ни одна хэш функция, даже будучи криптографической и не имеющей багов, не может взять энтропию из воздуха.

Ну вот теперь все значительно понятнее стало)))

Я всегда думал что если хэш одинаковый то и ключ полностью одинаковый, иначе были бы отличия в хэше. Не понимаю.

Тут дело не в том, что хеш-функция может быть неидеальна и давать коллизии, а в том, что размерность хеша меньше размерности ключа (20 байт против 32). То есть это как пытаться 20 яблок положить в 10 корзин - по одному в корзину поместить никак не получится. Поэтому на каждый немультиподписной адрес приходится в среднем 2⁹⁶ приватных ключей. Если представить емкость размером с Землю, заполненную горохом, то количество горошин примерно и будет равно количеству приватников, "отпирающих" каждый адрес ). И тем не менее, я не слышал, чтобы были найдены хотя бы два ключа, дающих одинаковый хеш.

Вот теперь стало немного понятнее, спасибо. Нужно почитать еще будет об этом.

[TechPriest]

Значение HASH160 для всех типов адресов (legacy, P2WPKH-in-p2sh, bc1-P2WPKH) вычисляется одинаково, поэтому формат адреса не имеет никакого значения. Это просто разные способы записи одного и того же хэша в "человекопонятном" виде, и не более того.

Но это же разные адреса? А то получается, что как-будто 3 адреса из одного публичного ключа  - это один и тот же адрес, но тогда они могли бы конвертироваться друг в друга (как, скажем, в лайткоине адреса на 3 и M)

Адреса это элемент инструкции по трате которая заключена в Scriptpubkey или в случае P2SH - хэш скрипта ,который необходим для сверки, когда хозяин адреса решит потратить свои средства.

Это очень важно для осознания. В любой криптографии с открытым ключом у нас есть пара privkey - pubkey . И адреса это просто разные методы хэширования и превращения оригинального публичного ключа (о чем писали выше неоднократно).
Поэтому, в какой то мере, одному публичному ключу соответствуют сразу несколько адресов в разных системах. Отличие составляет лишь P2SH, так как адреса "3" получаются не прямо из публичного ключа, а из redeem script-a, и при одинаковом публичном ключе они могут отличаться.

Это кстати очень хорошо видно по Electrum: при использовании функции "Swap", Electrum просит указать в каком формате необходимо превратить импортируемый приватник: p2pkh, p2wpkh, p2wpkh-p2sh .

[igor72]

Адреса это элемент инструкции по трате которая заключена в Scriptpubkey или в случае P2SH - хэш скрипта ,который необходим для сверки, когда хозяин адреса решит потратить свои средства.

Это очень важно для осознания. В любой криптографии с открытым ключом у нас есть пара privkey - pubkey . И адреса это просто разные методы хэширования и превращения оригинального публичного ключа (о чем писали выше неоднократно).

Спасибо, я, благодаря A-Bolt, уже все осознал ).

Поэтому, в какой то мере, одному публичному ключу соответствуют сразу несколько адресов в разных системах. Отличие составляет лишь P2SH, так как адреса "3" получаются не прямо из публичного ключа, а из redeem script-a, и при одинаковом публичном ключе они могут отличаться.

P2SH вообще к ключам не привязан, в redeem скрипте может быть и 15 публичных ключей, и ни одного.

Это кстати очень хорошо видно по Electrum: при использовании функции "Swap", Electrum просит указать в каком формате необходимо превратить импортируемый приватник: p2pkh, p2wpkh, p2wpkh-p2sh .

Не только в "Sweep", но и при простом импорте (кстати, Electrum почему-то явно не предлагает выбрать, как трактовать введенный приватник, что новичков, не заметивших кнопку "info", постоянно ставит в тупик).

[indaxis]

Закрытых ключей меньше 2^256 штук. Если точнее, то твердолобая реализация конечно же может использовать можно любое число на отрезке [0, 2^256 - 1], но безопасными в качестве ключей являются только числа меньше 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141. Потому что бОльшие значения могут иметь соответствие более чем одному публичному ключу. Поэтому, практически все библиотеки при загрузке ключа первым делом проверяют, чтобы загруженное значение было меньше 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141.

ну так это число 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 и есть 2 в 256
переводим в dec получаем 115792089237316195423570985008687907852837564279074904382605163141518161494337
делаем логарифм - получаем 2 в 256.

не понимаю, то ли ты ошибся, то ли я.

[~DefaultTrust]

Закрытых ключей меньше 2^256 штук. Если точнее, то твердолобая реализация конечно же может использовать можно любое число на отрезке [0, 2^256 - 1], но безопасными в качестве ключей являются только числа меньше 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141. Потому что бОльшие значения могут иметь соответствие более чем одному публичному ключу. Поэтому, практически все библиотеки при загрузке ключа первым делом проверяют, чтобы загруженное значение было меньше 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141.

ну так это число 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 и есть 2 в 256
переводим в dec получаем 115792089237316195423570985008687907852837564279074904382605163141518161494337
делаем логарифм - получаем 2 в 256.

не понимаю, то ли ты ошибся, то ли я.

Ты ошибся.
2^256 = 16^64 = шестьдесят четыре английские буквы фэ.