про хранение имелось ввиду опционально если имеет смысл.
Например для случая роста появления новых адресов с деньгами куда быстрее чем рост вычислительной мощности.
Откуда вы знаете что завтра-послезавтра не будет 4 миллиарда кошельков китайцев по 0.001 битка?
Так мало того! Они еще и перемещать их будут постоянно, генерируя каждый китаец чуть ли не каждый день новых 4 миллиарда кошельков.
В этом варианте легче будет тупо подождать с уже имеющимися:-)
Кроме того рост скорости интернета и вместительности накопителей не надо отрицать.
А вы конечно против иметь у себя базу допустим 10^-9 всех возможных адресов, со временем?
Насчет подстраивания под ГСЧ хреновые выглядит ничуть не лучше. Важно то что мало найти то что там как-то вот оно так не случайно он работал. Там потом куча математических действий, ситуация огого как не тривиальной становится в результате, и просто не разрешимой. Почитайте про эти хэши, смена всего одного бита или байта поменяет целиком весь хэш напрочь, то есть и адрес тоже.
Даже если там есть несколько стабильных байт у всех вариантов на входе и ее вычленить чтобы меньше считать - это уже нетривиальная математическая задача. А то что там типа числа были не совсем случайными на входе и поэтому нам не придется много перебирать, ну это уж извините совсем загнули. Это более чем не тривиально.
То что байты начальные приватного ключа были как-то полуслучайно получены, они один фиг не каким-то вариантом строго определяющим их порядок были получены. Фокус это использовать крайне нетривиален и для самых серьезных математиков, а не так просто как вы описываете словно задача школьника, словно там вместо случайных чисел тупо одно и тоже число писалось, причем у всех:-) Или типа -7-7-7-7-7-7-1-1-1-1-1-9-9-9-9-9- такого.
Единственное подспорье - уязвимости в криптосистемах, позволяющие не совсем тупо перебирать всё подряд, а обращать особое внимание на некоторые области в огромных
массивах.
Ну правильно, чтобы не говорить пустословно о мифически недоумных хакеров не воспользовавшихся ситуацией с несовсем хорошим генератором просто возьмите и сделайте парочку всего экспериментов. Точнее три:
1. сделайте большой набор случайным образом сделаных чисел псевдослучайных, и посчитайте количество во всем массиве чисел отдельно 0, отдельно 1, и так до 255--- да неужели каких-то реально больше чем других? Попробуйте сделать выборку большего размера, проверьте еще раз.
2. проверьте на наличие сходных цепочек в том же массиве или в новом. Можно усложнить до поиска +/- схожих по каким то параметрам. --- опять же ничего не выйдет
Есть еще подобные тесты, но так же если подключив высшую математику тесты можно сделать и вовсе сразу на функцию распределения проверку. И на поиск корреляций.
3. А теперь попробуйте в исходной строке их которой считается хэш заменить всего один символ, всего лишь, поменялся весь хэш? Вы знали точно каким образом он поменяется? Ничего что там выбираются разные функции в зависимости от данных?( если не ошибаюсь) Ничего что там море море сдвигов в вычислениях и ваш один случайный байт сделает не теоретически а практически не выполнимой задачей раскрутить это в обратную сторону?
Еще раз повторю, даже если там будет допустим более вероятно число от 0 до 127 чем от 128 до 255 и таким образом нам легче предположить что там 0 в этом бите особо много это не даст прямо колосального прироста, к тому же ситуацию быстро исправят, ну и вообще-то генераторы случайных чисел обычно проверяют всетаки люди, и достаточно хотя бы такой примитивной проверки чтобы никакие биты не считать более вероятными чем другие. таким методам проверки генератора случайных чисел учат даже в школе.