Программы для вычисления приватного ключа

[alevlaslo]

Вот еще только что сгенерился адресок: 11111411............................

если намеренно такой запрашивать, то генерация 2 года

1111121xye......

11111L1RUBedy..... это воообще огонь, троякое понимание Руб на едУ, Руб Еду и РУ беды

А тем временем 130 пазл уже содержит баланс под миллион баксов, достаточно всего 3700 ноутбуков, чтобы найти ключ за год

на падающем рынке фермы с такими картами стоят копейки

да и сейчас на таких профита нет вроде, можно скупить

ого, а чего ж она тогда работает и чем же искать тогда?

 

#130, 129bits private key [2¹²⁹,2¹³⁰-1], 1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua 13.0BTC

Expected time: several years on 256 Tesla V100 (Not possible with this program without modification)

[alevlaslo]

В теме есть человек? Невозможно только для гарантированного нахождения или для рандомного тоже?

[Old Miner]

23 минуты назад, alevlaslo сказал:

Невозможно только для гарантированного нахождения или для рандомного тоже?

Эта программа не занимается случайным поиском. В диапазоне [2¹²⁹,2¹³⁰-1] искать не может в принципе, если только не модифицировать исходный код.

[alevlaslo]

@Old Miner как же не занимается, одну и ту же задачу решает разное время как и Ванити, сравните на простейшей

 

а это взято из мануала самой проги:

Изменено 13 апр 2024, 14:33 пользователем alevlaslo

[Lenchik]

@alevlaslo Если ключ действительно случайный, то случайный поиск ничего не дает по сравнению с последовательным перебором. А чтобы случайный поиск не повторял одни и те же ключи, нужно создавать базу данных пройденного и сравнивать новые сгенерированные ключи с базой.  То есть алгоритм усложняется, значит и скорость падает.

Если ключ придумал человек, то можно и прикинуть куда он его поставит в диапазоне. Скорей всего не в начало и не в конец. И тут можно разделить диапазон на части и искать сначала в более вероятной части. 

 

Приведенный вами график не от программы, это типовой график вероятности. Обратите внимание, если при 50 процентах вероятности, внизу два, то при 4 совсем не 100%. О чем я как то и писал выше. Если вероятность нахождения асиком, в соло, блока 50% за четыре года, то 100% вероятность совсем не восемь лет, а больше. 

[alevlaslo]

@Lenchik спасибо, но вы так и не ответили: имеется ли хоть какая-то вероятность нахождения ключа 129 бит без модификации проги?

или она даже не посылает прыжки в некоторые части диапазона?

[Lenchik]

@alevlaslo О какой проге речь? Я всегда пишу только последовательный перебор, так как это обеспечивает самую высокую скорость. Проги для пазлов работают по интервалам, то есть весь диапазон делится на части, а в прогу вписывается конкретный интервал, но ищут они всё равно последовательно.

 

И почему 129 бит? Приватный ключ имеет длину 256 бит. 

[alevlaslo]

@Lenchik наверное чтобы платили за мод, вот само прога: GitHub - JeanLucPons/Kangaroo: Pollard's kangaroo for SECPK1

[Lenchik]

@alevlaslo Зачем ей мод? Если случайный перебор ничего не дает в плане производительности.

 

Кенгуру вроде как должна ускорять поиск если известен публичный ключ. То есть насколько то из публичного ключа можно просчитать варианты эллиптического алгоритма сзади наперед. Получится таблица. К ней примерять просчитанное в обычном порядке. 

Я еще не проверял, дает ли такой алгоритм преимущество перед обычным на CUDA. Там есть некоторые особенности. Если обычный алгоритм будет выполнять каждое ядро отдельно, то "кенгуру" таблица будет в общей памяти видеокарты и ядра могут получать к ней доступ только по очереди, а это очень сильно затормозит поиск. 

Вот когда проверю сам, тогда и скажу.