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

[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. Там есть некоторые особенности. Если обычный алгоритм будет выполнять каждое ядро отдельно, то "кенгуру" таблица будет в общей памяти видеокарты и ядра могут получать к ней доступ только по очереди, а это очень сильно затормозит поиск. 

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

[incubus666]

В 26.12.2023 в 21:42, Lenchik сказал:

Идею использовать QR подсказал мне ulex2006, что позволило сократить время перебора до ноля. Но программа для поиска написана.

 

Работает быстро RTX2070 + i7-3770K:

 

 

Интересующиеся этой темой люди могут попробовать её работу. Программа не имеет цифровой подписи Майкрософт, по этой причине может появиться предупреждения о том, что она может нанести вред компьютеру. Никакого вируса в ней нет. 

Программа ищет по шаблону 

0000000000000000000000000000000000XXXXXXXXXX00000XXX

Где X те символы она перебирает. По другому не умеет, она для этого ключа написана.

 

Алфавит base58

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

От 1 до z. В десятичном виде было бы от 0 до 57. Минимальный знак 1. Поэтому я его и вписываю на недостающие места, а не потому, что он кому-то приснился.

Счетчик работает без затей, в плюс. Справа младшие разряды, слева старшие.

 

Для примера берем ключ:

KxUAWf8fsqic3j17e4FgXJCtVqwyMDjoVrwTSsABcd55Aici2KBQ

12BnFZwvThDrurDVHHNgu1j8FkMFem7KQg

Его адрес вписываем в качестве аргумента в Start.bat

Ключ изменяем согласно шаблона.

 

KxUAWf8fsqic3j17e4FgXJCtVqwyMDjoVrwTSsABcd55Aici2KBQ
0000000000000000000000000000000000XXXXXXXXXX00000XXX
KxUAWf8fsqic3j17e4FgXJCtVqwyMDjoVrwTS1111111Aici2111 - найдет очень быстро
KxUAWf8fsqic3j17e4FgXJCtVqwyMDjoVrwT11111111Aici2111 - 1 час полный перебор. Если найдет, то быстрее
KxUAWf8fsqic3j17e4FgXJCtVqwyMDjoVrw111111111Aici2111 - два с половиной дня
KxUAWf8fsqic3j17e4FgXJCtVqwyMDjoVr1111111111Aici2111 - на моем железе примерно пять месяцев полный перебор

 

Ключ вписываем в файл Key.txt и запускаем через Start.bat В файле Key.txt перед ключом и после него не должно быть ничего, пробелов, перевода строки. Обработчика, выбрасывающего непечатаемые символы в программе нет, и она выдаст сообщение о неправильной длине ключа.

 

PriKeyWIFC_CUDA_10_3.zip 718.17 \u043a\u0411 · 25 загрузок

 

 

 а если вставить вот так ключ 

KxUAWf8fsqic3j17e4FgXJCtVqwyMDjoVr111111111111111111

программа найдет правильный приватник 

[Lenchik]

53 минуты назад, incubus666 сказал:

программа найдет правильный приватник 

Программа перебирает только указанные позиции. Остальные не перебирает.

У вас хэш потерян, а без него скорость поиска существенно ниже. Нужно из каждого варианта вычислять адрес, а это долго.

[incubus666]

9 часов назад, Lenchik сказал:

Программа перебирает только указанные позиции. Остальные не перебирает.

У вас хэш потерян, а без него скорость поиска существенно ниже. Нужно из каждого варианта вычислять адрес, а это долго.

Спасибо за подробности, а можно изменить программу так чтоб она искала именно вот в таком формате  то что единицы программа перебирала? с тоже скоростью 

KxUAWf8fsqic3j17e4FgXJCtVqwyMDjoVr111111111111111111

Изменено вчера, 12:28 пользователем incubus666

[Lenchik]

@incubus666 Без хэша нужно каждый вариант просчитывать по эллиптическому алгоритму, а это требует много ресурсов. И не забывайте про геометрическую прогрессию. У вас 18 символов не хватает. То есть количество вариантов такое, что время перебора будет почти бесконечность. 

За счет известной структуры ключа количество вариантов будет не 58^18, а меньше, но все равно очень большим. 

[incubus666]

2 часа назад, Lenchik сказал:

@incubus666 Без хэша нужно каждый вариант просчитывать по эллиптическому алгоритму, а это требует много ресурсов. И не забывайте про геометрическую прогрессию. У вас 18 символов не хватает. То есть количество вариантов такое, что время перебора будет почти бесконечность. 

За счет известной структуры ключа количество вариантов будет не 58^18, а меньше, но все равно очень большим. 

Добрый вечер спасибо за разъяснения теперь я понял. Если вам не  трудно вы не могли бы сделать программу на cuda чтоб например я скармливаю ей список из например 1 миллиона hex а программа внутри себя конвертирует их в биткоин адреса сжатого формата (compres) и если найдёт совпадение с адресом который лежит в базе адресов в фаиле BTC.txt запишет результат в новый фаил , у меня есть подобная программа но она на питоне и это занимает кучу времени и ресурсов цп ,так как ядра cuda работают намного быстрей у меня RTX3050 я думаю что это облегчит многим затраты , ну и конечно если что-то найду то конечно поделюсь!!!!!! 

[Lenchik]

@incubus666 У меня есть просто конвертор. То есть он берет из одного файла ключи и записывает в другой файл адреса, ничего не сравнивая. Написана на C++, так как узкое место в данном случае файловая система. То есть скорость ограничена скоростью чтения и записи диска. При использовании данных, хранящихся на диске, CUDA ничего не даст в плане производительности. 

[incubus666]

13 минут назад, Lenchik сказал:

@incubus666 У меня есть просто конвертор. То есть он берет из одного файла ключи и записывает в другой файл адреса, ничего не сравнивая. Написана на C++, так как узкое место в данном случае файловая система. То есть скорость ограничена скоростью чтения и записи диска. При использовании данных, хранящихся на диске, CUDA ничего не даст в плане производительности. 

Почему тогда все программы  которые ищут в диапазонах создают сетки по приблизительно 65 миллиардов hex и сравнивают с базой причем поиск идет у меня по 700 mil/s

[Lenchik]

@incubus666 Конвертор я писал по заказу. Что просили, то и написал.

Программы создают "радужную таблицу" и ищут методом "кенгуру". Но это если известен публичный ключ. По адресу так не ищут. На CUDA такой метод может и не дать прибавки. В видеокарте обращение к памяти происходит намного медленнее чем расчет на ядре CUDA.

 

А если вы о программах которые ищут невесть что и невесть как, так покажите хоть одного человека который с их помощью что-то нашел. Эти программы написаны для рекламы программиста который их написал. Либо они платные и программисты единственный человек который получит пользу от такой программы.