Topic: Анти ASIC/GPU/FPGA POW-алгоритм - page 5. (Read 1620 times)

Допустим, что асики для Неуловимого Джо никто создавать не будет. Но на GPU - то кто помешает многопоточно майнить?

    как я понимаю у вас есть только сама идея, но нет ни готового майнера, ни кошелька?

Вы не внимательно читаете. Я же четко написал что уже готово и что еще нужно сделать...

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

Ничто. Но только Вы на этом ничего не заработаете, потому что ASIC под этот алгоритм Вы создать не сможете даже за 100 тыщ миллионов. Потому что это - НЕВОЗМОЖНО. Код-самоизменяемый, а ASIC-и работают ТОЛЬКО со статическим кодом. Точка.

и где сам готовый майнер для добычи монет, или хотя бы его исходник

Не станет. Реверс инженер при всей своей грамотности способен раскрыть только ассемблерный вид исходного кода. Однако, если бы Вы тесно сталкивались с программированием, то знали бы, что даже обычный открытый код другому человеку понять трудно. Приходится сидеть месяцами, разбирать хитросплетения мысли автора и делать для себя кучу комментариев. А вот понять логику программы по ассемблерному коду - вообще проблема. Особенно, если речь идет о криптографии. А особенно, если нет никаких объяснений - как эта криптография работает. Не думайте, что все так просто, как написано в словосочетании "реверс-инжиниринг".

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

Вот видите, Вы даже такого очевидного, на картинке из 5 кружочков, объяснения не смогли понять. А как бы Вы, будучи грамотным реверс-инженером, смогли понять вот такую кашу из пересылок голых цифр по регистрам:

include io.asm
   data segment
        x db 'mov ax', '$'
   data ends
  stack segment stack
        db 128 dup (?)
  stack ends
   code segment
        assume cs: code, ds: data, ss: stack
 start: mov ax, data
        mov ds, ax
        lea dx, x
        outstr
        finish
   code ends
        end start



Каждый майнер берет Хэш предыдущего блока и его номер, добавляет к нему адрес своего кошелька, на который в первой транзакции будет генерироваться вознаграждение за найденный блок. Все эти числа он пропускает через обычный алгоритм хэширования и получает Головной Хэш (HEAD_HASH). Этот хэш у всех майнеров будет РАЗНЫМ из-за того, что в него включены разные кошельки разных майнеров. И получается, что им нужно стартовать процесс поиска подписи от РАЗНЫХ начальных данных. А значит, они не могут найти один и тот же хэш, каждый из них может найти только такой хэш, который подходит к его кошельку.

Дальше они начинают искать подпись. Поиск первого кандидата на подпись требует (например) 100 000 вычислительных операций, которые идут СТРОГО друг за другом. На каждом новом этапе новое найденное число в преобразовании становится СТАРТОВЫМ для последующих преобразований. Соответственно распараллелить вычисления на много ядер CPU или GPU НЕЛЬЗЯ!
После того, как майнер выполнит все эти 100 000 операций, он найдет первого кандидата на подпись. Но по статистике вероятность того, что этот кандидат подойдет прямо противоположна сложности, которая зависит от мощности сети. Думаю, что Вы должны знать - что такое "сложность" майнинга.
Таким образом ему нужно делать новые вычисления - новый этап. Для этого этапа стартовым значением будет то, которое он получил в качестве выходного на предыдущем. Теперь ему, чтобы получить нового кандидата на подпись нужно выполнить (опять таки - например) 300 000 вычислений.
Сделал. Получил. Проверил. Снова не подходит...
Ищем третьего кандидата. Опять - стартовым значением становится ВТОРОЙ найденный результат. И так повторяется до тех пор, пока не будет найдена удовлетворяющая задаче ПРЕ-ПОДПИСЬ.
Только пре-подпись нашли, дальше мы ее включаем в ЗАГОЛОВОЧНЫЙ блок данных, так называемый Хэдэр блока, и в этих данных уже есть все, что нужно прохэшировать для подписи блока, включая ПРЕ-ПОДПИСЬ. И этот блок данный хэшируем обычным способом. Результат хэширования - это и есть требуемая подпись для блока.
Все.

То есть, если сравнивать с обычным Хэшированием, которое выступает в качестве POW-алгоритма в сегодняшних криптовалютах, то разница в том, что майнер может ОДНОВРЕМЕННО выполнять хэширование от разных NONCE!
Например, на одном ядре у меня вычисляется хэш от nonce = 0
На втором от nonce = 1
На третьем от nonce = 2
На четвертом от nonce = 3
и т.д.
Это позволяет распараллелить вычисления по многим ядрам GPU или ASIC.

В моем же алгоритме ВООБЩЕ НЕТ nonce. Там вычисление идет одно за другим. То есть, как если бы я вместо входного nonce использовал выходной хэш от предыдущего рассчета. Понимаете?
Ну, то есть условно... начинаем считать первый хэш от nonce_0 = 0. Получаем hash_0 = 484857. Этот хэш я использую вместо nonce_1 при хэшировании номер 2. Получаю hash_1 = 9578090. Этот хэш я использую вместо nonce_2 в хэшировании номер 3 и получаю hash_2. hash_2 использую вместо nonce_3 и т.д.
То есть - пока не будет найден предыдущий хэш, новый вычислить я не могу. А это значит, что задачу выполнить можно ТОЛЬКО ПОСЛЕДОВАТЕЛЬНО. И никакие ядра на GPU или ASIC-ах здесь не помогут.

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

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

Еще один бич POW на процессоре это ботнеты. Как с ними бороться?

Анти ASIC/GPU/FPGA/CLOUD/MAINFRAME POW-алгоритм
Теперь майнинг может быть доступен каждому…

Привет всем.
Я несколько лет думал над тем - как сделать алгоритм POW, который будет устойчив не только против ASIC-устройств, но и против GPU-майнеров.
И я его разработал!
Вчера ночью я успешно провел генерацию и подтверждение первой локальной цепочки подписей для подтверждения блока (смотрите скриншот ниже). Поэтому с сегодняшнего дня я буду публиковать описание алгоритма и части кода на С++.



Основное решение.

Единственная причина, которая не позволяет криптосообществу решить проблему специализированных устройств – это приспособленность современных POW-алгоритмов к параллельным расчетам.
Отсюда выходит идеальное решение – алгоритм расчетов должен быть последовательным и устойчивым к любой возможности выполнить расчеты параллельно.

Первый принцип - циклические вычисления.

Мы должны отказаться от хэширования, которое сейчас является основным алгоритмом расчета для подписи блока. Предлагаю заменить его Кольцевой Битовой Функцией (КБФ), потому что она идеально выполняет все требования к POW-алгоритму.

Требования к POW-алгоритму:
1) односторонняя функция;
2) тяжело вычислить;
3) легко проверить;
4) только последовательные вычисления.

Приведу пример КБФ для 32-битного числа.



Вы видите, что через 8 раундов таких вычислений мы снова получаем начальное число. Так как вычисления идут по кольцу, мы можем их использовать для POW-алгоритма. Например, с 1-го по 7-ой раунд - это поиск результата вычислений. 7-ое число – это найденная подпись. А 8-ой раунд - это проверка верности вычислений!
При этом данная функция является односторонней, то есть обратное преобразование возможно только путем полного перебора.
Таким образом для данного вида вычислений, которые я назвал "Кольцевой Битовой Функцией", выполняются все 4 требования к POW-алгоритму.

Размер колец в КБФ может быть разным. Это зависит от комбинации ротаций и сдвигов, которые мы применяем. Некоторые комбинации не создают кольцевых функций, поэтому необходимо предварительно проверять – какая комбинация работает.

Приведу несколько рабочих примеров для 32-битных чисел:

 
239 rounds
NewNum = (num >> 1) ^ (num <<< 1)

55117 rounds
NewNum = (num >> 1) ^ (num <<< 1) ^ (num >>> 3)

131069 rounds
NewNum = (num >> 1) ^ (num <<< 1) ^ (num >>> 13)

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

Второй принцип – олимпийские кольца.

Одна кольцевая фунция может нам дать только одну подпись. Но для того, чтобы подобрать "красивую" подпись, нам нужно высчитать много кольцевых функций. Четвертый принцип POW-алгоритма требует, чтобы все кольцевые функции были связаны. Так как вычисления в кольцевой функции односторонние, то при поиске "красивой" подписи мы двигаемся по кольцу в одну сторону, а при проверке – в другую. Если мы начнем высчитывать новое кольцо от старой подписи по тому же алгоритму, то будем двигаться по тому же кольцу. Чтобы создать новое кольцо от старой подписи нужно изменить алгоритм на другой. В этом случае цепочка вычислений будет похожа на олимпийские кольца (только более длинная – она будет состоять из сотен или тысяч колец). Смена алгоритма вычислений на каждом кольце поможет нам увеличить устойчивость нашего алгоритма против ASIC-устройств.



Третий принцип – двухступенчатая подпись.

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

1 этап.
На основании подписи предыдущего блока, номера блока и адреса кошелька майнера выполняется хэширование (например SHA256).
Полученный хэш служит стартом для основного вычисления при поиске "красивой" подписи.

2 этап.
Найденная подпись является только pre-подписью.
Pre-подпись служит стартовым числом для хэширования, которое на вход принимает все остальные данные блока – корень Меркла, счетчик цепочки, штамп времени и т.д.
Полученный хэш мы считаем подписью блока.
Таким образом, майнер не сможет высчитать хэш блока до тех пор, пока не найдет корректную pre-подпись. Но найдя ее уже нет смысла высчитывать разные хэши от разных входных данных.

Четвертый принцип – самопрограммирование.

Последний принцип позволяет максимально защитить вычисления от ASIC устройств. В его основе лежит идея, что каждое входное число одновременно является программой, по которой оно будет преобразовано. Таким образом каждый новый расчет будет выполняться по уникальной программе, что не позволит использовать ASIC-устройства для ускорения вычислений.
Для этого необходимо разбить стартовое число на группы по несколько бит, и к значению каждой группы привязать определенную последовательность преобразований. Наилучшим образом это будет показано на примере сильного одностороннего алгоритма хэширования Mystique, который я разработал специально для усиления операций хэширования при вычислении блока. В нем используются различные преобразования чисел, примеры которых Вы можете видеть на картинке ниже. Данный алгоритм будет рассмотрен отдельно, так как он является дополнительным решением.



Проблема решена.

Все. Проблема защиты POW-алгоритма от ASIC/GPU/FPGA и прочих специальных устройств решена. Для большей силы алгоритма в нем будут использоваться 256 битные числа.

Что уже сделано.

На данный момент весь POW-алгоритм разработан и проверен. Основной код алгоритма реализован на C++ локально.



Что нужно сделать.

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

Нужно придумать название для новой криптовалюты.

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

BTC (кошелек биржи)
(только больше 0.001 BTC, иначе сумма не будет зачислена на адрес кошелька)
3FZfkLeap33gn1ixvWxW5sydNnMQq6ocKK

ETH (кошелек биржи)
(только больше 0.01 ETH, иначе сумма не будет зачислена на адрес кошелька)
0x86030796685228dd901b44f429846c02e7438c27

WAVES (собственный кошелек)
(любая сумма)
3PFHurMJgTG5ynJfkEf3fEAXQb5qbNFjEVy