Post
Topic
Board Идеи
Re: Анти ASIC/GPU/FPGA POW-алгоритм
by
flamehowk
on 09/12/2019, 18:51:32 UTC
В каком кто ищет диапазоне - это их личные половые проблемы. Решение все равно распределено равновероятно по всей области значений. Так что считать надо вероятности.
Опять ошибаетесь - это не их личные проблемы, это строго заложено в алгоритме, которого Вы не понимаете. Так что считать вероятности, когда вместо них имеются предопределенности абсолютно не разумно. Smiley

Берем вашу же постановку задачи:
900 пользователей майнят соло, 100 пользователей майнят в пуле. Значит вероятность найти блок у пула = 10%, у одного соломайнера = 0.1%. Вероятность впустую сжечь электричество у пула = 90%, у соломайнера = 99.9% Вопросы есть?
Конечно же есть. Ваша "вероятностная" математика не выдерживает никакой критики. При использовании моего алгоритма вероятность найти блок у пула нужно сравнивать не с ОДНИМ отдельно взятым майнером, а со всеми остальными майнерами - то есть с 900 человекам. Следовательно их вероятность = 90% против 10% у Вашего пула.
Но я понимаю, что Вы не понимаете о чем идет речь и потому не можете переключиться от типичных представлений. Но потому я и придумал новый алгоритм, чтобы решать старые проблемы, а не оставить все как есть.

Давайте я в последний раз попытаюсь Вам объяснить...

Сейчас обсуждаем обычный майнинг, к которому Вы привыкли.
Возможные значения nonce лежат в поле от 0 до 4294967295
Каждый отдельный майнер для нахождения хэша должен перебрать все значения nonce от 0 до 4294967295.
Каждый майнер, который находится в пуле, перебирает только часть этого диапазона, например для первого майнера это 0 до 1000000000, для второго майнера это от 1000000001 до 2000000000, для третьего майнера это диапазон от 2000000001 до 3000000000, а для четвертого это диапазон от 3000000001 до 4294967295.
Таким образом каждый майнер, который состоит в пуле перебирает в 4 раза меньше значений. Значит затрачивает в 4 раза меньше времени. Значит - целый пул найдет блок быстрее.

Теперь рассмотрим майнинг на моем алгоритме.
Возможные значения лежат в поле от 0 до 115792089237316195(…)584007913129639935 (полное число занимает 78 знаков)
НИ ОДИН майнер не может их перебрать. НИКОГДА.
Поэтому каждый майнер ищет в своем узком диапазоне который предопределен его Заглавным Хэшем, который зависит от адреса его кошелька.
Таким образом один майнер будет искать в диапазоне, например от 0 до 10, другой в диапазоне от 1000000 до 1000010, третий в диапазоне от 540 до 550 и так далее. Как ни крути, а каждый майнер, в пуле он или нет, будет иметь АБСОЛЮТНО равные возможности найти подходящий хэш, что и все остальные. Пул здесь не играет никакой роли.

Кто будет писать в эту базу данных? Сами майнеры? Что помешает майнеру с ип адресом 1.1.1.1 записать в базу значение якобы своего ип адреса 2.2.2.2 ?
Вы зря впадаете в такое паническое настроение. Вся Ваша проблема в том, что Вы просто не понимаете алгоритма, который я описал. Но я ведь не заставляю Вас его учить. Не понимаете и ладно. Не нужно делать из этого для себя проблему.
Ответ на Ваш последний вопрос очень прост - тот же, кто пишет и БЛОКЧЕЙН. А кто пишет блокчейн Вы знаете? Программа.
А вот на последний Ваш вопрос я Вам отвечу очень просто. НИКТО не помешает. Но именно на этот адрес он и получит все сообщения, и если он будет не корректен, то сообщения уйдут в пустоту и майнер, который соврал насчет своего IP адреса просто будет исключен из сети.
Неужели Вы этого не понимаете?
И каким образом отдельно взятая нода сможет проверить подлинность записей в этой БД?

На самом деле, для проверки соответствия между IP и идентификатором кошелька достаточно, чтобы нода, смайнившая блок, включала свой IP в заголовок блока. Тогда любая нода, получившая блок, сможет напрямую по IP постучаться к ноде, IP которой прописан в блоке, и спросить её идентификатор кошелька. Тогда и никакой БД не надо. Есть только одна проблема: при достаточном количестве нод в сети, майнящая нода, выплюнувшая в сеть блок, ляжет под количеством запросов с каждой ноды, верифицирующей поступивший блок.
Вот, сразу видно, человек понимающий в сути дела. Все верно. Поэтому и нужно применить решение, которое позволит от этой проблемы избавиться. Технически на основе такой базы можно даже создать алгоритм анонимизации в сети, который не будет эту сеть избыточно нагружать и при этом будет гарантировать довольно высокую степень анонимности. Но это уже... совсем другая сказка. Если захотите - этот вопрос можно будет отдельно обсудить, если дело дойдет до его конкретной реализации в коде. А сейчас пока дело все еще стоит на вопросе ЗАМЕНЫ POW-алгоритма.
Так что предлагаю сосредоточиться именно на этом.