I forgot '1' at the beginning of the number:

last 56 bit of the private key#57:
but there are only 55 bits

Correct-->

last 56 bit of the private key#57:

0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000011110101100100101110010010000011110010 1011101011000011100

HEX  00000000000000000000000000000000000000000000000001eb25c90795d61c

It uses only cpu. If the search space is very limited, it is like you know already many bit of 256.
I'm saying:

for example, if you provide me:
1) a public key
2) the first 198 bit of the private key

then I can recover the last 58 bit of the key. Nothing more.

There is no magic, 58 bit is not so much. That is the meaning of the sentence: "the search space is very limited".
My code runs on a cpu. So I can use efficiently the Ram of my pc. Gpus are good for hashing computations, cpus are good for elliptic (multi integer precision, 256 bit in this case) computations.


I'll try a little explanation:

If I know already the first 255 bit, then the search space is 2 (the value for the right key ends with 0 or 1).
if I know already the first 254 bit, then the search space is 2^2 = 4
if I know already the first 246 bit, then the search space is 2^10 = 1024

With so small number, any cpu can in less than 1 sec retrieve the correct private key with brute force.

Now we talk about the key #57 of  the puzzle transaction. We all know that the first 200 bit are 000000.....00001
then I search only the last 56 bit (between 2^56 and 2^57 - 1). With brute force I would need to use 2^56  different private keys to generate 2^56 public keys. Too much time. But If I knew only the address and not the public key, that would be the only way.

But If I know the public key too, then I can exploit an algebraic property of the elliptic curve (of all elliptic curves, not only the secp256k1).  Then instead of doing 2^56 "computations", I need only to compute a list of 2^28 public keys, put it in Ram, then generate another list of 2^28 public keys and do a comparison between the 2 lists. In this way I get 2^58 combinations (that's the way the Baby Step Giant Step algorithm works). If you look at the links I provided in the previous post you can understand it better.


Input data:

private key #57 :

public key
(I got it from https://www.blockchain.com/btc/tx/95b77d69302fbc805f1a6e97a3f0d27159017341e5f2d40ec79785d830fe9d59 -->
PUSHDATA(33)[02a521a07e98f78b03fc1e039bc3a51408cd73119b5eb116e583fe57dc8db07aea], look at this answer to understand how to get the y coordinate too)

Output data:

last 56 bit of the private key#57:

Now, for the next private key #58:

Input data:

private key #58 :

public key

Output data:

last 57 bit of the private key#58:

вы описание то читали?
в brainflayer, всё уже придумано, не нужно изобретать велосипед, используется фильтр Блума, загоняете адреса в hex формате в фильтр и всё, генерация и проверка происходит на лету независимо от кол-ва проверяемых адресов, правда чем больше адресов тем больше и вероятность ложного срабатывания фильтра, но это не критично до 100-200 млн.

Да, в многопоточном режиме в 3 раза быстрее. Попробуйте https://yadi.sk/d/qMh5yB0w3LGcBQ (архив, один экзешник и криптобиблиотека, требуется .Net framework 4.5).

10 000 - число вариантов
Случайные строки - генерирует случайные строки длинной 100 байт в файл, заданный ниже (D:\\output.txt)
Генерировать случайно - генерирует случайную строку в 100 байт а из неё адрес, выводит в текстовое поле
Генерировать из файла - читает из заданного файла строки и из них генерирует адреса - сколько строк - столько адресов. Выводит в поле. Разделитель между приватным ключем и адресом можно задать, по умолчанию стоит " | ".
Попробуйте если что.

ну почему же не "ткнуть", прийдется конечно скомпилировать на linux, но раз есть непреодолимое желание этим заниматься то справитесь  ,  50-80к  в секунду будет генерить, правда в hex формате

https://github.com/ryancdotorg/brainflayer

Сейчас накидал утилиту (использовал Bitcoin Address Utility C#)  так 10 000 за минуту из произвольного сида делал. Т.е. миллион за 100, в сутки миллионов 14. Так что у вас на питоне быстрее. Хотя может дело в деталях, под дебаггером, включена проверка на валидность и прочее.

есть конечно, но зря время потратите, тема была актуальна в году так 2013, а после того как amaclin прошёлся там вообще ловить нечего   , и вот почему: https://www.youtube.com/watch?v=5NQg9gYBxIY

Имеется в виду использование слов в качестве seed?

- что за процессор такой? Вряд ли чтение пару десятков мегабайт текста (надеюсь, под фразой не подразумевается многострочный текст?) Значит медленный алгоритм генерации в этом самом "libbitcoin-explorer".

ExploitAgency's fork of (ocl)vanitygen doesn't have a prefix limit (and it supports 80+ altcoins). You can get it here: https://github.com/exploitagency/vanitygen-plus

Nobody. It's impossible, man.

Lol.
Trying to crack the Bitcoin richlist?

How many characters are you trying to generate for? Anything over 9 would probably need a decent sized GPU farm. And anything over 11 would either require a massive farm or just not even worth it.