Topic: TrueCoin <-- правильная монета - page 5. (Read 19792 times)

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

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

Ну по-факту получается ведь не весь хэш, а младшие 64 бита.
(b64 % 5), ((b64/5) % 5), ((b64/25) % 5) и во всех этих итерациях результат зависит от всех битов;  подбирать хэш блока не только по старшим битам для сложности, но и по 64 младшим для получения "форы" в следующем блоке безумием будет.
Вот только эти деления по модулю не совсем случайные получаются, всё-таки для целых не выполнится 2^m == 5ⁿ; но думаю от того что какая-то цепочка 100 раз повторится, а другая 99 особо никто не пострадает, случайные отклонения в реальности будут гораздо больше.

Хэш предыдущего блока - это не очень удачный выбор "случайного" числа. Потому что его выбором можно манипулировать в некоторых условиях.

Хотя вообще, сама идея разработки GPU-враждебного алгоритма довольно сомнительна. Потому что ботнеты, как форма централизации, намного хуже асиков.

Я и так могу скзать, без сильного изучения opencl и high computing, самым узким место в области высокопроизводительных вычислений является оперативная память!
Сколько там на чип влезает? 6-8GB кеша в топовые процессоры? (это дорогие, типичные представители радуются и 2-мя), и готовых алгоритмов берете тот же scrypt и подстраиваете параметры под требуемое потребление памяти (litecoin - всго 128кб). Активный random access к большому объемы памяти убьет скорость GPU (думаю хватит и 1 гб для начала)
От ASIC вас это не спасет, но разница в роизводительности между CPU->ASIC будет не четыре порядка! А видеокарты по любому останутся за кадром... их можно добить обилием double/quad float арифметикой (правда не факт что это заметно поможет) или увеличением размера компилированного кода больше нескольких мегабайт (у видеокарт размер памяти под код - кажеся 1мб)

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

p.p.s. PoW на основе пустых вычислений - имхо тупиковый путь. Подумайте над чем-нибудь другим.



yacoin - используют scrypt ПОДСТРАИВАЮЩИЙ параметры алгоритма в зависимости от сложности (т.е. потребление памяти растет - правда что будет когда типичного компа не будет хватать...)

Ну QtCreator'ом компилирую, может из-за него ещё эта проблема с линковкой.

Пока такой вариант:
http://pastebin.com/b5HvSuBW

эффективный гпу-майнер сотворить мозг поломать надо будет  а так под 64 битной ОС заметно шустрее бегает, чем под 32 (ну ещё может тормозит виртуалка, и 64->64 выходит эффективней чем 32->64)
Сначала хотел вариант выбора каждой хеш-функции от результата предыдущей итерации, но потом подумалось что смогут абьюзить вариантом фпга(гпу) под один алгоритм и с откидыванием сразу промежуточных результатов реализовать быстрый подбор хешей вида функция_k->функция_k->функция_k.
Так что остановился на случайной цепочке, зависимой только от хэша предыдущего блока.

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


"волшебные байты" - это некие константы в сетевом коде?

Ну да, решил просто клон-в-клон биткоин форкнуть. С изменённым принципом начисления награды/ретаргета, (это уже натренировался вроде). Ну и осталось хеш-функции заголовка блока заменить/расширить.
Надо идею фактически показать людям-то, может кому из стартапов понравится, и реализуют таки в нормальном виде/либо этот подберут до ума окончательно довести.

p.s. sphlib в оригинале не хотел линковщик подсоединять... повтыкал ifdef __cplusplus extern "C" { ... } и вроде как подхватилось. Интересно, такое в дальнейшем к непредсказуемым траблам может привести?

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

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

Ukigo, а вы ничего не слышали, а каких-либо форках, переписанных под win/visual studio 

А то пока моё единственное достижение - так и не смог скомпилировать готовые исходники bitcoin'a в ехе-файлы 

Трудно придумать "честный" PoS, в валюте у которой PoW - эмитент инфляции; с энергоэффективностью дела вообще печально, и не возразишь.

С NVC хоть понятно  если/когда асики под scrypt сделают и/или курс вырастет, PoS блоки вообще львиную долю генерируемых монет будут выдавать.


Ukigo, думаю из-за этой пурги форков, как раз просто очередной клон с изменённым механизмом эмиссии 100% обречён на провал. Хоть мизерный шанс остаться в живых имеет как раз only-cpu форк, без первоначальной привязки к какой-либо планке биржевого курса и отсутствием обещаний/надежд для толпы майнеров нафармить золотые горы в первоначальный период десятка перерасчётов сложности.

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

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

Насчет NVC текущий план - PoS/PoW  ~= 3/1. Сделать принудительное чередование или ограничить длину цепочки блоков одного типа можно, но это требует обдумывания. Пока склоняюсь к тому, чтобы не добавлять подобных диктаторских условий.

А PoS может выступать лишь в роли необязательного "дополнительного рубежа" защиты?

Скажем № PoW-блоков всегда чётные, 0---2---4---6---8---10-...; транзакции подтверждаются шестью pow'ами.
Между ними(PoW) могут встраиваться PoS-блоки, т.е. аналог предыдущей цепочки будет выглядеть 0-1'-2'-3'-4'---6'---8'-9'-10'-... При этом транзакция "засветившаяся" в блоке 0, по-прежнему полностью подтвердится в блоке 10, но цепочка 0-10' будет "весомей" чем 0-10.

Сложность для PoW-блоков рассчитывается именно по ним самим, чтобы сетью находилось N PoW-блоков в сутки. Сложность PoS-блоков косвенно будет зависеть от резкого изменения PoW-мощностей сети, но при устоявшейся мощности у PoW в принципе будет тоже предоставлена сама себе, и корректироваться для нахождения 0,9N-0,95N PoS-блоков в сутки.

Понятно, что дурное дело нехитрое и реализовать можно. Вопрос, добавит ли такой PoS защиты от дабл-спенд атак?

А кто сказал, что PoS непременно обязан быть чистым? Гибридного вполне хватит, если создать надлежащие условия.

Ну как экс-трушечки поживают, надежда на воплощение ещё осталась?

Да проверок и не надо, вместо x = Z1 * wDiff + Z2; w1 := math.Lgamma(x) или w1 := math.Log(x)*x сокращаем до w1 := x.
Цифровой социализм итак останется: как майнил 1 монету в сутки, так и будет продолжать эту же 1 монету майнить своей старой мощностью, несмотря на все изменения суммарной мощности/сложности системы.

Насчёт only-CPU сегодняшние я бы тоже не зарекался так сильно, тенденции последнего десятка лет от процессоростроителей (и амд, и интел) - это многоядерность cpu и всё большее встраивание в него же gpu. Не исключено, что лет через 5-10 "чистые х86-CPU-программы" вообще перестанут существовать. Ещё на уровне компилятора: можно любую функцию быстрее выполнить на gpu-части, которая есть везде - перекидываем её вычисления туда; другой кусок кода просто распараллеливается - аналогично раскидываем на 16 cpu-ядер, и т.д.

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

Понимаю, что шаг вперёд - два назад это невесело, и скорости разработки не добавляет. НО...
Немножко отвлёкшись и поглядев на 10-ти миллионную сложность битка подумалось: для мощности использовать "усиление" х*ln(x) {ln(Г(х))} - это идеологически неправильно. При быстром росте мощности, даже в устоявшейся системе это даст гигантский рост награды за блок. Нужно осмысленное ограничение, например максимум для w1, должно быть w1 = x;

А то уж совсем маразматическая ситуация была. Майнит десяток пулов с 100Mh/sec получает каждый условно по 690, подключается ещё один новенький с такой же мощностью - теперь каждый из одиннадцати получает по 700. Вырастала не только суммарная награда в системе, но и награда каждому майнеру.

Попробую разобраться и чего-нить накорябать. Так шальная мысль возникла когда читал про это GPGPU - возможно гибридные майнеры на процессоре с задействованием встроенной графики, будут быстрее чистого cpuminera. Задача явно не первостепенная, но если получится - будет неплохой рывок, почти "халявный" прирост мощностей для cpu-майнинга.

P.S. Про совместимость статья занятная... Но если программист на С пишет в xxi веке нечто вида
struct template
{
    int new;
    struct template* class;
};
ему надо отрывать руки, а потом яйца.... или наоборот 

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

Вроде любой пул - для системы выглядит как простой соло-майнер; т.е. код пула нужно будет писать гораздо позднее, когда сеть разрастётся, чтобы много мелких для установившейся сложности майнеров могли стабильно включать свои мощности, а не играть в лотерею. Так что, как я понимаю, для проверки соло-майнинга достаточно реализации -server у кошелька, и наличия консольного майнера обращающегося к нужным локальным портам, и перемалывающего нужные хеши.

P.S. У С/С++ различие только в виде вызова функций уже в скомпилированных библиотеках кажись? Или по-другому, неужто в С++ компиляторе нельзя "под себя" скомпилировать си-шные исходники?