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

[Dmitrii Storm]

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

для удачной атаки на сеть надо обладать вычислительной мощью хотя бы процентов 30 от общей мощи сети.

 

30%? Вы уверены в этом?

Ничего, что такая атака называется "Атака 51%"?

Не смущает?

Ни на какие мысли не наводит?

Edited 17 Dec 2024, 11:17 by Dmitrii Storm

[Provok]

"Атака 51%" - это условное название. Сами подумайте, почему именно 51%, а не 50,5% или 50,45%? Ведь даже 50,001% больше половины. Она означает, что большая часть сети под контролем, и на достаточно большом промежутке времени твоя цепь будет гарантированно длиннее цепи соперников, вот и все.

Здесь же надо провести единичную атаку, а не взять всю сеть под контроль. Успешность предполагаемой атаки на сеть зависит от контролируемой вычислительной мощности, таким образом, имея 30% сети можно с вероятностью 30% произвести успешную атаку. Нахождение блока процесс вероятностный, таким образом, если удачно выпадут кости, можно быстро найти несколько блоков, опередив остальных. Естественно, остальные при этом должны не знать об атаке, а принять случившееся за естественный ход вещей, "ну попал блок в орфан - бывает".

В среднем, из 3-х таких атак 1 будет удачной, поэтому даже 30% мощности в одних руках - недопустимая централизация.

Edited 17 Dec 2024, 11:41 by Provok

[Dmitrii Storm]

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

имея 30% сети можно с вероятностью 30% произвести успешную атаку. Нахождение блока процесс вероятностный, таким образом, если удачно выпадут кости, можно быстро найти несколько блоков, опередив остальных.

Слишком  много удачи и счастливых совпадений. Это так не работает, к счастью.

Для примера возьмем BitcoinSV прямо сейчас:

Один пул обеспечивает 40% хешрейта.

Означает ли это, что этот пул может переписать блокчейн BSV по своему усмотрению в любую сторону? Нет.

 

Означает ли это, что блокчейн BSV постоянно находится под атакой 51%? Нет.

 

Всё остальное - фантазии. Про 30% шанс и удачу.

 

Источник картинки и циферок

 

Приведу простой и понятный пример из реальности.

 

Во время взлома сети Биткоина в 2010 году и последующего хардфорка для исправления этой беды понадобилось 4 часа и 25 блоков для того, чтобы победить хакнутый блокчейн и заменить его другим, без следов взлома. При полном и подавляющем перевесе сил добра в хешрейте сети на тот момент. Там даже не 51% был, а чуть ли не 75% хешрейта. 4 часа!

Полное и подробное изложение тех событий:

Спойлер

ХАРДФОРК БИТКОИНА.

 

 

15 августа 2010 года неизвестный хакер смог сгенерировать 184,4 млрд BTC на высоте 74 638 блока, взяв за точку старта адрес с 0.5 биткоина.

 

Об этом рассказал ведущий в то время разработчик Bitcoin Владимир Ван Дер Лаан.

"Это была самая худшая проблема из когда-либо возникавших", — вспоминает он.

 

Хакер обнаружил, что часть кода для проверки операций не работает, если создать запредельно крупные транзакции.

 

Из ничего было создано 184 467 440 737,09 биткоинов для трех разных адресов. Два адреса получили 92,2 миллиарда биткоинов каждый (а если точно = 92233720368.54 биткоинов на каждый адрес), и третий адрес получил 0,01 BTC - это оплата за проведение транзакции (fee).

 

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

 

Учитывая, что предусмотрено кодом Биткоина выпустить только 21 млн BTC, то действия киберпреступника создали в  8784  раз больше криптовалюты, чем возможно.

Это могло уничтожить Биткоин и пошатнуть весь крипторынок, если бы ошибка не была бы устранена.

 

Проблему обнаружили сразу, и в течение 5 часов код был исправлен с помощью Сатоши Накомото, Гэвина Андерсена и других разработчиков первой криптомонеты.

 

Для этого пришлось также перезапустить блокчейн, что привело к хардфорку и разделению сети на две разные цепи, два разных блокчейна.

 

Изменения, внесенные в код Биткоина, кроме прочего, отклоняют любую транзакцию, которая содержит более 21 миллиона биткойнов на выходе.

 

4 часа две цепи блокчейна Биткоина соревновались между собой за право считаться настоящей цепью. Часть майнеров продолжала майнить на взломанной цепи. Но в конце концов "исправленная" цепь обогнала "хакнутую".

 

На высоте 74 691 блока цепь с внесенным корректировками признали истинной, поэтому неуместные 184,4 миллиарда  биткоинов просто исчезли.

 

Взломанная сеть с почти 200 млрд BTC просуществовал около 9 часов.

 

Самое смешное в том, что хотя хакерская транзакция со 184,4 млрд BTC исчезла из блокчена навсегда, 0,5 BTC, которые были ею израсходованы, существуют до сих пор. Судя по всему, этот пол-битка пришли из "крана" и с тех пор не израсходованы.

 

Источник данных

 

Edited 17 Dec 2024, 14:22 by Dmitrii Storm

[Provok]

 @Dmitrii Storm Вы вообще о чем спорите? Где я писал про переписывание блокчейна в любую сторону? Один свеженамайненный блок отправить в орфан, быстро намайнив новую цепочку от предыдущего блока, и все. При чем тут вообще атака 51%? Другое дело, что если какой-то пул спалится на том, что он намеренно отправляет чужие блоки в орфан, то от него уйдут все майнеры, поэтому пулы так делать не будут. Но мы тут про теоретические возможности говорим. Теоретически, любой из первой тройки пулов на Вашей диаграмме может так делать.

 

Как Вы думаете, почему даже на битке многие до сих пор требуют больше 1 подтверждения, чтобы финализировать транзакцию? Во времена моей молодости битковая транзакция вообще считалась финализированной только после 6 подтверждений.

Edited 17 Dec 2024, 14:31 by Provok

[Polone]

9 минут назад, Provok сказал:

 @Dmitrii Storm Вы вообще о чем спорите? Где я писал про переписывание блокчейна в любую сторону? Один свеженамайненный блок отправить в орфан, быстро намайнив новую цепочку от предыдущего блока, и все. При чем тут вообще атака 51%? Другое дело, что если какой-то пул спалится на том, что он намеренно отправляет чужие блоки в орфан, то от него уйдут все майнеры, поэтому пулы так делать не будут. Но мы тут про теоретические возможности говорим. Теоретически, любой из первой тройки пулов на Вашей диаграмме может так делать.

 

Как Вы думаете, почему даже на битке многие до сих пор требуют больше 1 подтверждения, чтобы финализировать транзакцию? Во времена моей молодости битковая транзакция вообще считалась финализированной только после 6 подтверждений.

А помню такой момент. Был год наверное 2014 или 2015 точно не помню и у меня подвисла транзакция в блокчейне. Но, как то всё это было очень странно. Она горела красным цветом - НЕ ПОДТВЕРЖДЕНО.  Потом появилось 1 подтверждение, потом 2 подтверждения, потом 3 подтверждения иииии... вдруг опять красным загорелась надпись НЕ ПОДТВЕРЖДЕНО. И так за сутки несколько раз. Не помню чем всё это закончилось, подтвердилась или вернулась на адрес. Но, такого больше я не видел. (Может мне изменять память, но кажется тогда я поставил маленькую комиссию, не знаю связано ли с этим или нет).

[Dmitrii Storm]

21 минуту назад, Provok сказал:

Во времена моей молодости битковая транзакция вообще считалась финализированной только после 6 подтверждений.

Это не так давно было, кстати. В 2017 году. Может и позже тоже, не помню уже. Но осенью 2017 - точно. Там тогда творилось вообще всякое: DDoS атаки на сеть Биткоина, постоянные форки, срачи, разборки. Весёлое было время.

[Old Miner]

В 13.12.2024 в 17:09, Lenchik сказал:

А вы проверьте это на практике. Программа для поиска по публичному ключу есть для старших паззлов. Попробуйте её использовать на искусственном примере и на одной видеокарте. Потом сосчитайте сколько надо времени для расчета на сотне, полторы видеокарт. И вы увидите что это невозможно.

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

 

Итак, исходные данные для 66-го пазла (взято отсюда)

• диапазон приватного ключа: 2⁶⁵ ... 2⁶⁶ - 1
• публичный ключ: 024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd
• приватный ключ для проверки корректности работы программы: 000000000000000000000000000000000000000000000002832ED74F2B5E35EE

Я воспользуюсь программой keyhunt, одним из режимов работы которой является поиск приватного ключа из ограниченного диапазона по известному публичному ключу.  Для этой задачи в программе применяется алгоритм Baby-step giant-step (BSGS). Особенностью этого алгоритма является зависимость скорости работы от объёма выделенной оперативной памяти, то есть, алгоритм требует больших объёмов ОЗУ и больше подходит для процессоров. Да-да, я вообще обойдусь без GPU, всё будет происходить на CPU AMD Ryzen 5 3600, работающем на фиксированной частоте 4.1 ГГц.

 

Запускаю keyhunt с такими параметрами:

./keyhunt -m bsgs -S -t 12 -f puzzle66.pub -k 1024 -b 66

Пояснения по параметрам:

 

-m bsgs

Задаёт режим bsgs.

 

-S

Перед тем, как начать собственно вычисления, программа генерирует фильтры Блума, что занимает немало времени. -S позволяет сохранить фильтры Блума на диск и при следующем запуске не генерировать их заново, а подгрузить уже готовые, что значительно экономит время.

 

-t 12

Количество потоков. У меня 6-ядерный 12-поточный процессор, я их все и задействовал.

 

-f puzzle66.pub

Путь к файлу, хранящему публичный ключ.

 

-k 1024

Этот параметр определяет занимаемый алгоритмом BSGS объём оперативной памяти, чем больше выделить памяти, тем выше производительность. У меня 32 ГБ ОЗУ, поэтому задал -k 1024, согласно таблице:

2 G   -k 128
4 G   -k 256
8 GB  -k 512
16 GB -k 1024
32 GB -k 2048

 

-b 66

keyhunt знает о пазле, поэтому вместо указания нижнего и верхнего пределов диапазона приватного ключа, можно просто указать номер паззла.

 

Поехали!

[+] Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
[+] Threads : 12
[+] K factor 1024
[+] Mode BSGS sequential
[+] Opening file puzzle66.pub
[+] Added 1 points from file
[+] Bit Range 66
[+] -- from : 0x20000000000000000
[+] -- to   : 0x40000000000000000
[+] N = 0x100000000000
[+] Bloom filter for 4294967296 elements : 14722.65 MB
[+] Bloom filter for 134217728 elements : 460.08 MB
[+] Bloom filter for 4194304 elements : 14.38 MB
[+] Allocating 64.00 MB for 4194304 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_4294967296.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_134217728.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_4194304.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_4194304.blm .... Done!
[+] Thread Key found privkey 2832ed74f2b5e35ee    ~231 Pkeys/s (231515513969320482 keys/s)
[+] Publickey 024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd
All points were found000000000
[+] Thread 0x2833ec00000000000

 

В листинге можно увидеть найденный приватный ключ: Thread Key found privkey 2832ed74f2b5e35ee и он совпадает с приватным ключём из исходных данных.

 

И вот мы подошли к тому, ради чего это всё затевалось - время. Сколько времени было затрачено на поиск приватного ключа? Ответ: 120 секунд. Всего лишь 2 минуты на весьма скромном шестиядерном процессоре. Более того, большую часть этого времени -  78 секунд заняла подгрузка фильтра Блума с диска, а на вычисление ключа затрачено всего 42 секунды. Замечу, что фильтр Блума хранился на HDD, использование SSD, особенно с интерфейсом NVMe,  должно значительно сократить время загрузки фильтра Блума.

 

Вывод:

Данный эксперимент показал, что после попадания в мемпул транзакции, тратящей выход пазла № 66 и, следовательно, открытия публичного ключа, соответствующего этому выходу, вполне реально до нахождения блока успеть найти приватный ключ и создать конкурирующею транзакцию с большей комиссией. И для этой задачи не требуется задействовать значительные вычислительные ресурсы.

Edited 17 Dec 2024, 16:27 by Old Miner

[Polone]

38 минут назад, Old Miner сказал:

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

 

Итак, исходные данные для 66-го пазла (взято отсюда)

• диапазон приватного ключа: 2⁶⁵ ... 2⁶⁶ - 1
• публичный ключ: 024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd
• приватный ключ для проверки корректности работы программы: 000000000000000000000000000000000000000000000002832ED74F2B5E35EE

Я воспользуюсь программой keyhunt, одним из режимов работы которой является поиск приватного ключа из ограниченного диапазона по известному публичному ключу.  Для этой задачи в программе применяется алгоритм Baby-step giant-step (BSGS). Особенностью этого алгоритма является зависимость скорости работы от объёма выделенной оперативной памяти, то есть, алгоритм требует больших объёмов ОЗУ и больше подходит для процессоров. Да-да, я вообще обойдусь без GPU, всё будет происходить на CPU AMD Ryzen 5 3600, работающем на фиксированной частоте 4.1 ГГц.

 

Запускаю keyhunt с такими параметрами:

./keyhunt -m bsgs -S -t 12 -f puzzle66.pub -k 1024 -b 66

Пояснения по параметрам:

 

-m bsgs

Задаёт режим bsgs.

 

-S

Перед тем, как начать собственно вычисления, программа генерирует фильтры Блума, что занимает немало времени. -S позволяет сохранить фильтры Блума на диск и при следующем запуске не генерировать их заново, а подгрузить уже готовые, что значительно экономит время.

 

-t 12

Количество потоков. У меня 6-ядерный 12-поточный процессор, я их все и задействовал.

 

-f puzzle66.pub

Путь к файлу, хранящему публичный ключ.

 

-k 1024

Этот параметр определяет занимаемый алгоритмом BSGS объём оперативной памяти, чем больше выделить памяти, тем выше производительность. У меня 32 ГБ ОЗУ, поэтому задал -k 1024, согласно таблице:

2 G   -k 128
4 G   -k 256
8 GB  -k 512
16 GB -k 1024
32 GB -k 2048

 

-b 66

keyhunt знает о пазле, поэтому вместо указания нижнего и верхнего пределов диапазона приватного ключа, можно просто указать номер паззла.

 

Поехали!

[+] Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
[+] Threads : 12
[+] K factor 1024
[+] Mode BSGS sequential
[+] Opening file puzzle66.pub
[+] Added 1 points from file
[+] Bit Range 66
[+] -- from : 0x20000000000000000
[+] -- to   : 0x40000000000000000
[+] N = 0x100000000000
[+] Bloom filter for 4294967296 elements : 14722.65 MB
[+] Bloom filter for 134217728 elements : 460.08 MB
[+] Bloom filter for 4194304 elements : 14.38 MB
[+] Allocating 64.00 MB for 4194304 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_4294967296.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_134217728.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_4194304.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_4194304.blm .... Done!
[+] Thread Key found privkey 2832ed74f2b5e35ee    ~231 Pkeys/s (231515513969320482 keys/s)
[+] Publickey 024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd
All points were found000000000
[+] Thread 0x2833ec00000000000

 

В листинге можно увидеть найденный приватный ключ: Thread Key found privkey 2832ed74f2b5e35ee и он совпадает с приватным ключём из исходных данных.

 

И вот мы подошли к тому, ради чего это всё затевалось - время. Сколько времени было затрачено на поиск приватного ключа? Ответ: 120 секунд. Всего лишь 2 минуты на весьма скромном шестиядерном процессоре. Более того, большую часть этого времени -  78 секунд заняла подгрузка фильтра Блума с диска, а на вычисление ключа затрачено всего 42 секунды. Замечу, что фильтр Блума хранился на HDD, использование SSD, особенно с интерфейсом NVMe,  должно значительно сократить время загрузки фильтра Блума.

 

Вывод:

Данный эксперимент показал, что после попадания в мемпул транзакции, тратящей выход пазла № 66 и, следовательно, открытия публичного ключа, соответствующего этому выходу, вполне реально до нахождения блока успеть найти приватный ключ и создать конкурирующею транзакцию с большей комиссией. И для этой задачи не требуется задействовать значительные вычислительные ресурсы.

Круто. Всё по полочкам разложили. О чём я и говорил, о чём я и переживал. Уверен что и 67 могут стырить. Поэтому при наличии приватного ключа от 67, требуется способ в обход мемпула. 

[korbengtr]

В 17.12.2024 в 08:05, Polone сказал:

Если моя исходящая транзакция имеет 1 подтверждение, можно ли в таком случае сделать с этого же адреса ещё одну транзакцию, но с большей комиссией и успеть "перебить"первую транзакцию? Возможно ли это после 1 подтверждения ?

где-то читал ,надо минимум 3 подтверждения,что бы  нельзя было  отменить транзакцию.

[Polone]

1 минуту назад, korbengtr сказал:

где-то читал ,надо минимум 3 подтверждения,что бы  нельзя было  отменить транзакцию.

Я писал чуть выше, что в 2015 году, моя транзакция, имея 3 подтверждения, отменялась у меня на глазах до статуса - Не ПОДТВЕРЖДЕНО. Что это было, я не знаю. Транзакция висела больше 24 часов и периодически доходила до 3 подтверждений и отменялась. Это было один раз и больше такого я не видел никогда.

[Helber]

Только что, Polone сказал:

Я писал чуть выше, что в 2015 году, моя транзакция, имея 3 подтверждения, отменялась у меня на глазах до статуса - Не ПОДТВЕРЖДЕНО. Что это было, я не знаю.

Орфаны?

[Polone]

55 минут назад, Helber сказал:

Орфаны?

Orphan (orphaned block) — добытый и подтвержденный блок, не включенный в основную цепочку блокчейна. Добывший его майнер остается без награды.

Наверное да, вот это как вы сказали - орфан. Нашёл определение в интернете. Очень похоже на тот случай и год совпадает. Пишут что это приходилось на 2015.

Edited 19 Dec 2024, 08:30 by Dmitrii Storm
Polone, не увлекаемся игрой со шрифтами

[Helber]

@Polone , я когда-то читал, что орфаны при биткоин-майнинге встречаются не так редко, буквально по 1-2 раза в неделю, а то и чаще.

[alnsam]

Всем привет!

 

Пардон муа, если врываюсь с мелочью в Ваш спор или диспут, но может быть Вы знаете какой-нибудь онлайн сервис для решения головоломок (пазлов)?

 

В сети нашел только:

https://btckeys.ru/btcgenerator/
https://2gen.ru/
https://privatekeyfinder.io/bitcoin-puzzle/random-keys/67

В целом норм, но скорость не радует, я понимаю, что написано это все на js, но все же может быть что-то более эффективное в плане КПД найдется? Пока на работе штаны просиживаешь хотелось бы время проводить с большей пользой. GPU подбор не подойдет, видеокарта там совсем печальная (встроенная).

Edited 19 Dec 2024, 15:46 by alnsam

[polym0rph]

8 часов назад, korbengtr сказал:

где-то читал ,надо минимум 3 подтверждения,что бы  нельзя было  отменить транзакцию.

Вот хорошая статья на эту тему со всей математикой по количеству необходимых подтверждений.

[korbengtr]

23 часа назад, alnsam сказал:

Всем привет!

 

Пардон муа, если врываюсь с мелочью в Ваш спор или диспут, но может быть Вы знаете какой-нибудь онлайн сервис для решения головоломок (пазлов)?

 

В сети нашел только:

https://btckeys.ru/btcgenerator/
https://2gen.ru/
https://privatekeyfinder.io/bitcoin-puzzle/random-keys/67

В целом норм, но скорость не радует, я понимаю, что написано это все на js, но все же может быть что-то более эффективное в плане КПД найдется? Пока на работе штаны просиживаешь хотелось бы время проводить с большей пользой. GPU подбор не подойдет, видеокарта там совсем печальная (встроенная).

Даже на телефоне работает    https://bitcoin.oni.su/puzzle/

[alnsam]

В 20.12.2024 в 15:34, korbengtr сказал:

Даже на телефоне работает    https://bitcoin.oni.su/puzzle/

Тут тоже самое и как мне кажется скорость так себе на том же https://2gen.ru по шустрее, но в любом случае спасибо, попробую еще и этот сервис. 🙂

[Polone]

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

Тут тоже самое и как мне кажется скорость так себе на том же https://2gen.ru по шустрее, но в любом случае спасибо, попробую еще и этот сервис. 🙂

На этих сервисах даже нельзя диапазон поиска изменить. Уменьшить.

[alevlaslo]

@alnsam можно просто прокачивать визуализацию как фокусники для вольта, чтобы без программ просто при генерации адреса в кошельке получился пазловый

Матчасть такова: уплотнение пустоты - это сознание, уплотнение сознания - это материя, уплотнение материи - это страдание, уплотнение страдания - это красота души

Edited 22 Dec 2024, 08:01 by alevlaslo

[Polone]

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

@alnsam можно просто прокачивать визуализацию как фокусники для вольта, чтобы без программ просто при генерации адреса в кошельке получился пазловый

Матчасть такова: уплотнение пустоты - это сознание, уплотнение сознания - это материя, уплотнение материи - это страдание, уплотнение страдания - это красота души

Уж лучше сразу в Перу на аяхуаску, либо на соли в Купчино.👅😁

[korbengtr]

6 часов назад, alnsam сказал:

Тут тоже самое и как мне кажется скорость так себе на том же https://2gen.ru по шустрее, но в любом случае спасибо, попробую еще и этот сервис. 🙂

Если вам нужна скорость,то придется обзавестись хорошим оборудованием   и программы на CUDA.А все браузерные переборы работают  (+/ -) одинаково.В вашем случае,можете запускать в нескольких браузерах ,установить шаг перебора,можете установить стартовое число(которое подскажит интуиция) т.е полет фантазии не ограничен.

[alevlaslo]

3 часа назад, Polone сказал:

Уж лучше сразу в Перу на аяхуаску, либо на соли в Купчино.👅😁

Тоже работает

[Sefa]

Всем привет! Подскажите, где-то натыкался на статью или описание проги на гихабе по алгоритму поиска публичного ключа к определенному адресу. Обладает ли кто-то такой информацией?

[Dmitrii Storm]

7 часов назад, Sefa сказал:

Всем привет! Подскажите, где-то натыкался на статью или описание проги на гихабе по алгоритму поиска публичного ключа к определенному адресу. Обладает ли кто-то такой информацией?

 

Публичный ключ - это и есть адрес. Его искать смысла нет, он и так всем известен, оттого и зовётся публичным.

Ключей всего два: публичный и закрытый. Они и рождаются парами. К каждому публичному есть один закрытый. Для поиска закрытых ключей рабочих программ нет, а то как бы всё изменилось.

[Lenchik]

В 24.12.2024 в 19:09, Sefa сказал:

Всем привет! Подскажите, где-то натыкался на статью или описание проги на гихабе по алгоритму поиска публичного ключа к определенному адресу. Обладает ли кто-то такой информацией?

Хотя дело это бесполезное, но можете сами написать. Преобразование публичного ключа в адрес происходит с помощью алгоритма ripemd160 

Скачиваете исходники от BitcoinCore. В них находите файлик ripemd160.cpp, ну и хедер к нему ripemd160.h 

Пишете main  со счетчиком. Проверяете что все работает. После этого переводите код в CUDA, отлаживаете. Строите ферму циклопического размера и в путь. 

Edited 25 Dec 2024, 15:35 by Lenchik