Генератор/чекер криптовалютных кошельков.

DevOps · 18.03.2023

ledsan сказал(а):
я не спец в кодах но он говорил что использует при генерации приватного ключа какое-то смещение еще акцент делал на то что почему раньше до этого не додумались

Я весь прошлый год изучал эту тему и работал с ней. Вариантов "выработки " данных много, начиная от виртуального устройства с параметрами компьютеров 2009-2011 (для поиска потеряшек) до конкретно составления параметров генерации
Правда осенью дал себе слово больше не лезть в эту тему :-)

А так, ЖПТ вот подсказывает генератор

ЖПТ:

using System;
using System.Threading.Tasks;
using NBitcoin;

class Program
{
    static void Main()
    {
        var network = Network.Main;

        // Устанавливаем количество потоков, которые будут использоваться для генерации адресов
        int threadCount = 4;

        // Создаем задачи для каждого потока
        var tasks = new Task[threadCount];
        for (int i = 0; i < threadCount; i++)
        {
            tasks[i] = Task.Factory.StartNew(() =>
            {
                // Генерируем новый мнемонический код и приватный ключ для каждого потока
                var mnemonic = new Mnemonic(Wordlist.English, WordCount.Twelve);
                var seed = mnemonic.DeriveSeed();
                var hdRoot = new ExtKey(seed);
                var privateKey = hdRoot.Derive(new KeyPath("m/44'/0'/0'/0/0")).PrivateKey;
                var address = privateKey.PubKey.GetAddress(ScriptPubKeyType.Legacy, network);

                Console.WriteLine($"Адрес кошелька: {address} (поток {Task.CurrentId})");
            });
        }

        // Ожидаем завершения всех задач
        Task.WaitAll(tasks);
    }
}

DevOps · 18.03.2023

Не стал ждать вечера чтобы понять, как писал выше, можно ли генерить 500К адресов и приватных ключей в минуту.
На одном потоке 100К генерится около 25 секунд. На 6 ядерном процессоре можно использовать 10 потоков (ядро - 2 потока, 2 оставляем в запас для системы) что выдаст 1 440 000 000 адресов и приваток в сутки. Как проверять писал выше по топику, можно также сделать асинхрон но тогда мощность генерации с проверками упадет минимум вдвое на шарпе (тут уже нужен питон, он смкоростней или просто я тормоз)
Пруф

PS Ошибся в рассчета, выход не 1 440 000 000 а 2 880 000 000 приваток и адресов в сутки минимально. Если комп "взрослей" то до 10 лярдов в сутки уже не фантастика
PPS Расход памяти удивил, даже до 50 мегабайт не вырос
PPSS Сразу чтобы было понятно, любая генерация таким образом дает 100% - НОЛЬ. Вы никогда не сгенерите кошелек который был создан ранее. Тут нужны иные алгоритмы и подходы. Я слишком поздно это понял поэтому потерял кучу ресурсов, а потом попросту уже был слишком занят чтобы разрабатывать решение которое дает хоть небольшой шанс

DevOps · 18.03.2023

Вот тут ежедневная выкладка блокчейна, только адреса с балансами. Обычный блокчейн и кастомный (теневой)
Качаете утром, разбираете и сравнивате с тем что нагенерено за ночь. Никаких доступов, апи, и запросов, все можно делать на локальной машине

LOYCE.CLUB | List of all Bitcoin addresses with a balance

All about Bitcointalk statistics and data developed by LoyceV!

addresses.loyce.club

ledsan · 18.03.2023

DevOps сказал(а):
Не стал ждать вечера чтобы понять, как писал выше, можно ли генерить 500К адресов и приватных ключей в минуту.
На одном потоке 100К генерится около 25 секунд. На 6 ядерном процессоре можно использовать 10 потоков (ядро - 2 потока, 2 оставляем в запас для системы) что выдаст 1 440 000 000 адресов и приваток в сутки. Как проверять писал выше по топику, можно также сделать асинхрон но тогда мощность генерации с проверками упадет минимум вдвое на шарпе (тут уже нужен питон, он смкоростней или просто я тормоз)
Пруф

PS Ошибся в рассчета, выход не 1 440 000 000 а 2 880 000 000 приваток и адресов в сутки минимально. Если комп "взрослей" то до 10 лярдов в сутки уже не фантастика
PPS Расход памяти удивил, даже до 50 мегабайт не вырос
PPSS Сразу чтобы было понятно, любая генерация таким образом дает 100% - НОЛЬ. Вы никогда не сгенерите кошелек который был создан ранее. Тут нужны иные алгоритмы и подходы. Я слишком поздно это понял поэтому потерял кучу ресурсов, а потом попросту уже был слишком занят чтобы разрабатывать решение которое дает хоть небольшой шанс

Сделай генерацию по сид фразам заранее заготовленным т.е. есть сидка в ней 12 слов эти слова перебираются во всех последовательностях получится примерно 18-20 миллионов валидных комбинаций ну и не для битка а для кифира и иже с ними ерс-20.
почему это интересно, если сгенерировать много миллионов сид фраз то будет много сидок содержащих одни и теже слова только в разных последовательностях, таким образом можно заранее нагенерировать уникальных сид фраз и перебирать все возможные последовательности и чекать во всех чейнах кефира благо их полно

ledsan · 18.03.2023

DevOps сказал(а):
Вот тут ежедневная выкладка блокчейна, только адреса с балансами. Обычный блокчейн и кастомный (теневой)
Качаете утром, разбираете и сравнивате с тем что нагенерено за ночь. Никаких доступов, апи, и запросов, все можно делать на локальной машине

LOYCE.CLUB | List of all Bitcoin addresses with a balance

All about Bitcointalk statistics and data developed by LoyceV!

addresses.loyce.club

Вроде на блокчейн ком есть txt с всеми адресами содержащие балансы

ledsan · 18.03.2023

ledsan сказал(а):
Сделай генерацию по сид фразам заранее заготовленным т.е. есть сидка в ней 12 слов эти слова перебираются во всех последовательностях получится примерно 18-20 миллионов валидных комбинаций ну и не для битка а для кифира и иже с ними ерс-20.
почему это интересно, если сгенерировать много миллионов сид фраз то будет много сидок содержащих одни и теже слова только в разных последовательностях, таким образом можно заранее нагенерировать уникальных сид фраз и перебирать все возможные последовательности и чекать во всех чейнах кефира благо их полно

я такое на зенке сделал, автор топика помогал все это реализовать но тема заглохла из за того что зенка начинает со скоростью 480-700 адресов в секунду а спустя час два падает до неприличных 20-60 так и не смогли решить эту проблему

DevOps · 18.03.2023

ledsan сказал(а):
я такое на зенке сделал, автор топика помогал все это реализовать но тема заглохла из за того что зенка начинает со скоростью 480-700 адресов в секунду а спустя час два падает до неприличных 20-60 так и не смогли решить эту проблему

Я из за этого и юзал студию 1000 адресов в секунду это ни о чем, да и как Вы отметили - производительность падает со временем работы скрипта

DevOps · 18.03.2023

Zedx сказал(а):
Вот тут не понял, почему не может быть снова сгенерирована уже имеющаяся сид фраза? Вероятность конечно крайне мала, но всё же...

Есть моменты....
Честно, описать тонкости создания генераторов, методы которыми элиптические кривые шифрует данные и откуда берутся рандомные значения - это потянет на полновесную статью и наверное даже не одну.
Для "потеряшек" (первые кошельки которым по 50 биткойнов давали) это вообще и близко не работает
НО, соглашусь, шанс есть но на новых кошелях. Хотя, можно конечно "напрячься" но для меня эта тема сейчас - ТАБУ
Кстати - по поводу обработки уже сгенеренных, не все так плохо, скорость добиться возможно, выше по топику писал, в крайнем случае лярд в стуки на каком нибудь бюджетнике

ledsan · 18.03.2023

Zedx сказал(а):
Ну генерировать быстро в многопотоке не проблема, т.к. это чисто математическая функция, гораздо медленнее будет идти процесс проверки баланса, потому что тут уже нужно обращаться к блокчейну и это будет требовать большего времени выполнения.

как он говорит чекается в редисе и с этим ваще нет проблем

DevOps · 18.03.2023

Zedx сказал(а):
Сделал многопоток - у меня 8 ядер, одно оставил для системы, на 7 оставшихся ядрах 100.000 приваток сгенерилось за 85 секунд. Т.е. за сутки в моём случае получится сгенерить 101.647.058 ключей
Посмотреть вложение 104760

В личку кинул генератор. Только нагетс прицепите (NBitcoin)
И что то видно с кодом, не может на 7 ядрах так мало выдавать, пруф показывал, у меня 6 ядер, работал в потоке

DevOps · 18.03.2023

Генератор:

using NBitcoin;
class Program
{
    static async Task Main(string[] args)
    {
        List<string> list = new List<string>();
        string result = string.Empty;
        Console.Write("Введите количество итераций за раз : ");
        string iter = Console.ReadLine();
        int iteration = int.Parse(iter);
        Console.Write("Введите количество циклов : ");
        string cilce = Console.ReadLine();
        int cikl = int.Parse(cilce);


        //System.Threading.Thread.Sleep(5000);
        Console.WriteLine("Начата генерация...");
        for (int c = 0; c < iteration; c++)
        {
            var key = new Key();
            var address = key.PubKey.GetAddress(ScriptPubKeyType.Legacy, Network.Main);

            Console.WriteLine("Bitcoin Address: " + address);
            Console.WriteLine("Private Key: " + key.GetBitcoinSecret(Network.Main));
            string addr = address.ToString();
            var k = key.GetBitcoinSecret(Network.Main);
            string k1 = k.ToString();
            result = addr + "   $ " + k1;
        }
    }
}

DevOps · 18.03.2023

Вообщем, 1М в минуту выбил при проверке в минуту по базе 1* на локальной машине по базе с сылке сверху которую указывал
Лярд проверок в офлайне без всяких апи для биткойна возможен, в сутки.
Вопросы в Телегу, а то и так заспамил тему

_HEDELKA_ · 18.03.2023

Zedx сказал(а):
Причина медленной работы была в том, что у меня сначала генерилась сид фраза, а уже на основе неё ключи. Если оставить генерацию ключей напрямую, то скорость заметно выросла - 100.000 ключей в одном потоке заняло 27.6 секунд, на 7 ядрах 6.7 секунд. Таким образом за сутки на 7 ядрах можно нагенерить примерно 1.3 миллиарда ключей

Ну если что-то есть добавить, то можно и сюда, тема как раз про эту тему )

Хм интересненько, у меня 16 оперативы я могу запустить и в 50 потоков

DevOps · 19.03.2023

Zedx сказал(а):
Не, дело не в оперативе, (у меня 32гб), а в количестве ядер процессора. Задачи распараллеливаются на ядра, т.е. в моём случае 4 физических ядра = 8 логических, 1 ядро оставляем для работы системы, на 7 оставшихся раскидываем нашу задачу. И это всё как отдельный скрипт на C# (без зенки).
В зенке эта же самая задача (генерация 100.000 ключей) заняла 15.6 секунд (против 6.7 секунд) - в 2.3 раза медленнее.

Кстаи по ZP и VS. Никак не разберусь в причине некоторых особеностей. Как пример - то что Вы указали по генерации. Отдельным консольным скриптом скорость реально в разы больше. А вот, например в моей недавней теме (тык) по работе с большими данными, наоборот, именно ZP показал кратную производительность хотя код идентичен, поэтому пришлось переписывать код с консоли в ZP.
Мистика :-)

DevOps · 19.03.2023

Zedx сказал(а):
Ещё есть нюанс, что в ZP можно всё это запустить ещё и в несколько потоков, т.е. распараллеливание на несколько ядер в консольном приложении и ZP даёт 6.7 против 15.6 секунд соответственно. Т.е. запуск в ZP в несколько потоков должен дать прирост производительности. В общем нужно разобраться в многопоточности ZP и сделать тесты.

Да не вопрос, сейчас попробую многопоток накидать и забенчить, у меня правда Лайт версия, но это не проблема

DevOps · 19.03.2023

Zedx сказал(а):
Ещё есть нюанс, что в ZP можно всё это запустить ещё и в несколько потоков, т.е. распараллеливание на несколько ядер в консольном приложении и ZP даёт 6.7 против 15.6 секунд соответственно. Т.е. запуск в ZP в несколько потоков должен дать прирост производительности. В общем нужно разобраться в многопоточности ZP и сделать тесты.

Вообщем, обернул код в Paralell и на 10 потоках генерация 100 000 адресов с ключами 9 секунд. На больших потоках не тестил, нет смысла у меня I5
Пруф

Если поставить потоков больше чем позволяют ядра, переключения контекста крадет скорость
На 20 потоках при генерации каждым по 5000 потеря уже секунда
Уменшал до 5 потоков по 20 000 - те же 9 секунд.
Можно конечно забустить камень и добавить гигагерц, но это уже без меня :-)

ЗЫ - Теперь захотелось забенчить сколько дает консоль во многопотоке
UPDATE Тот же код на консоли дает 5,6 секунд на генерацию 100 000, что грубо 1 миллион в минуту
Пруф

ledsan · 19.03.2023

а в чем сакральный смысл добить именно биток?
в нем как минимум не один формат адреса да имонет на нем мало.
толи дело ерс-20 адрес один а чейнов полно следовательно шансов больше так как один сгенерированный адрес из приватника можно чекнуть в десятках чейнов глядишь где то стрельнет.

DevOps · 19.03.2023

ledsan сказал(а):
а в чем сакральный смысл добить именно биток?
в нем как минимум не один формат адреса да имонет на нем мало.
толи дело ерс-20 адрес один а чейнов полно следовательно шансов больше так как один сгенерированный адрес из приватника можно чекнуть в десятках чейнов глядишь где то стрельнет.

Библиотека дает возможность генерить данные для любой крипты. Можно генерить для Эфира, Голда, Собаки (забыл как он называется). Сакрального смысла нет, это просто бенч и исследования работы библиотеки и сравнения скоростей исполнения.Не более чем технические тесты по вопросам который тут задавали. С тем же успехом можно генерить все что угодно.

ledsan · 19.03.2023

DevOps сказал(а):
Библиотека дает возможность генерить данные для любой крипты. Можно генерить для Эфира, Голда, Собаки (забыл как он называется). Сакрального смысла нет, это просто бенч и исследования работы библиотеки и сравнения скоростей исполнения.Не более чем технические тесты по вопросам который тут задавали. С тем же успехом можно генерить все что угодно.

за с буксами закончу попробую вашу технологию)))

DevOps · 21.03.2023

Zedx сказал(а):
Ещё раз перепроверил свой код, с ZP сильная разница получилась. Через parallel.for в консоли выходит на 7 потокаx в среднем 6 секунд, в ZP уже 17 секунд.

Главное не генерация, можно через бибилиотеки отдать генерацию на аутсорс GPU, но "узким"местом остается именно ообработка. Конечно в голове есть идея как максимально "бесболезненно" разогнать проверки без постоянного чтения/записи но честно лень заниматься этим, так как это уже считай готовая разработка, а я не вижу в ней смысла для себя :-)

Будет время, потестю, скину бенчи

ledsan · 21.03.2023

DevOps сказал(а):
Главное не генерация, можно через бибилиотеки отдать генерацию на аутсорс GPU, но "узким"местом остается именно ообработка. Конечно в голове есть идея как максимально "бесболезненно" разогнать проверки без постоянного чтения/записи но честно лень заниматься этим, так как это уже считай готовая разработка, а я не вижу в ней смысла для себя
Будет время, потестю, скину бенчи

Я выше описывал методу поиска через перебор полный заранее заготовленных сид фраз, можно сделать типа майнинга поднять сервак на котором будет крутится бд в которой будут сжатые сидки что бы места меньше занимало, с этого сервака клиент берет пакетом с самой старой датой обращения определенный диапазон сидок и начинает обрабатывать, генерирует кошелек и чекает на баланс локально (заранее загруженные в реддит адреса с балансами разных монет чейна ерс-20) после чека делается запись даты чека в БД.
вопрос честности конечно потом как попилить найденное))

ledsan · 21.03.2023

у меня если я не ошибаюсь выходило что порядка 20-22М сжатых и проиндексированных сидок на диске до 140-150мб занимали в mysql

DevOps · 21.03.2023

ledsan сказал(а):
у меня если я не ошибаюсь выходило что порядка 20-22М сжатых и проиндексированных сидок на диске до 140-150мб занимали в mysql

Неплохо

Генератор/чекер криптовалютных кошельков.

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Client

Кто просматривает тему: (Всего: 2, Пользователи: 0, Гости: 2)