вот чего получилось. из первой версии симулятора, с прикрученными pos и "бешенным" майнингом первые Х годов/Х' блоков.
Комиссии вообще не принимал во внимание, проще считать что они не уничтожаются (как в btc), и соответсвенно на объем денежной массы никак не влияют.
(странный в Go инкремент какой-то, в проверке if не дают пользоватся. просто выходит синоним для i=i+1 без практической пользы в применении)

В логарифме - отношение сложностей.
wDiff_base - это заданная начальная сложность. Наверняка она же есть в каком-то значении типа 0x00ffffff...f
и высчитывается ln не от самого числа текущей сложности (мощности), а от того, во всколько раз она меньше чем базовая
и в "отрицательную" зону она кажись зайти не может - даже если система "умерла", и мощность стремится к 0 (в сети один майнер на PIV), сложность до 0хffff... не поднимется, застынет на 0х00ffff.... с генерацией блока раз в 3 часа 


тот же пример про i7, и сложности-мощности подробнее (базовая мощность - 1Mh/s, базовая сложность 0x00ffffff)
Один i7, мощность 1 Мh/s, сложность 0x 00ff ffff, награда = 10 * ln(0x00ffffff/0x00ffffff) = 10 * ln(1) = 0
Восемь i7, мощность 8 Mh/s, сложность 0х001f ffff, награда = 10 * ln(0x00ffffff/0x001fffff) = 10 * ln( = 20,794
1024 i7-x, мощность 1Gih/s, сложность 0х 0000 3fff, награда = 10 * ln(0x00ffffff/0x00003fff) = 10 * ln(1024) = 69,315
и т.д.

Естественно сложность будет 256-битная (или 512-битная), но для дроби это абсолютно безразлично, так же и останется, меньше в Х раз чем базовая сложность.


И прибавлять единицу не обязательно. Можно красивые коэффициенты найти. Первоначальная награда Х, увеличение мощности в 10 раз добавляет Y, Y довольно просто считается.

Да не забивайте голову энергоэффективностью.
К сожаленью, всё вычисление блоков так устроено, что куча вычисленний уходит в пустоту.
PoW - это сама идея, молоти данные в поисках ненужного вообще никому, кроме самой системы Nonce.
Но остальное тоже не лучше - даже если всё оставлять на PoS, то и в PoS-блоках/транзакциях для защиты от спама, "ddos'a" и зафлуживания отправкой по 1 сатоши (если неправ, думаю Бальтазар поправит) всё равно придётся вводить на каждом ноде для всех потенциально опасных операций взаимодействия вычисления неких Nonce, которые долго искать и гораздо быстрее проверять.

С процентами ничего не поделаешь. Тут 2 варианта:

Либо эмиссия стабильна в абсолютном значении, и тогда естественно в процентном значении она постоянно уменьшается. (с учётом неизбежного вымывания части денег вследствии отправки на несуществующие адреса, физическом уничтожении файлов кошельков/паролей к ним и т.п.) со временем это означает нулевой прирост денежной массы, и её полную стабилизацию [В NVC|PPC как я понимаю
к этой стабилизации ещё системно ускоряются].
Даже если эмиссия ограничена каким-то коридором. Например 100 база, ±20% (т.е. 80 - 120), то это ничего не меняет. Да, если сначала эмиссия была ближе к минимуму диапазона, а по мере развития приблизится к максимуму, то это отсрочит время выхода на 0% роста, но и только. Отменить его ("стабилизец") наличие этих границ не позволит.

Либо эмиссия стабильна в процентном значении, и тогда в абсолютных величинах она естественно всё время повышается. В адекватной идеальной системе это повышение будет плавным и очень малым, на уровне общего роста. Но оно всё равно будет.
При такой эмиссии (в реальных, популистко/субъективных и т.п. системах) имеет смысл сравнивать только соседние периоды (ну по устоявшемуся порядку - года). Если взять любую, самую стабильно/успешную страну, и начать высчитывать её текущие инфляцию/эмиссию/рост от её показателей 1900 года - мы получим бешенные %. (Хороший пример тот же биг мак. Рост цены почти в 10 раз за полвека. Да был и кризис 70х, и нынешние разгулы кредитования - но это не отменяет факта, что есть и 1000% инфляции на фастфуд за пол века, и развитие экономики (подтасовки безусловно есть, но 50 лет назад несомненно их ввп был всё-таки меньше). Если представить эти 1000% инфляции на продукты в год, а не от точки отсчёта - это экономический коллапс, без вариантов.)


В запасном варианте с логарифмом социализм специфический 
Скажем формула выглядит как 10 базы + 10 за каждый_десяток_сложности (10 + 4,34294482 * ln(max_target/target) монет).
Мощность сети в 10 раз больше первоначальной. Каждый блок оценивается в 10+10=20 монет, за сутки генерируется 20*720=14400 монет.
Я при наличии мощности Х = базовой, получается имею 10% мощностей.
Итого, майню каждый десятый блок, с наградой 20; или в сутки 720 * 0,1 * 20 = 1440 монет
Мощность сети поднялась величины в 100 больше первоначальной. Каждый блок оценивается в 10+20=30 монет, за сутки генерируется уже 30*720=21600
Я при остаюсь со своей Х=базовой, и имею 1% мощности.
В итоге, майню уже лишь каждый сотый блок, но с наградой 30; или в сутки 720 * 0,01 * 30 = 216 монет
Но мощность сети выросла ещё на порядок, и уже в 1000 раз больше первоначальной. Каждый блок оценивается в 10+30=40 монет, за сутки генерируется уже 40*720=28800
Я всё ещё майню на мощностях Х, и имею лишь 0,1% мощности
Майню лишь каждый тысячный блок, но с увеличившейся наградой 40; или в сутки 720 * 0,001 * 40 = 28,8 монет

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


p.s. С++, я совсем чуток знаю. К сожаленью, на "академическом" уровне, лет 15 назад Страуструпа и Буча серьёзно читал/изучал (из практики был доступен только borland c++), а вот после ни одной среды разработчки всерьёз "не щупал"живу в таких диких краях, где открытие консоли Win+r, cmd, enter воспринимается 99% народом как программирование/. А в реальных проектах, один практик сотню теоретиков за пояс заткнёт

Ну тогда второй вариант из примера?
награда_блока_за_сложность = 10 + log₁₀(target0·÷target)  = 10 + ln(target0/target) ln(10) ≃ 10 + 0,43429448190325182765112891891661 * ln(target0/target)
Людям проще объяснить. суммарная мощность  1 Мх/с - награда 10, сложность 10 Мх/с - награда 20, сложность 1Гх/с - награда 40, сложность 1Тх/с - награда 70
(но в реализации к натуральным логарифмам один фиг приводить надо, всё равно код только через них считает, ибо ряды проще)


А с чередованием и соотношением PoS-PoW. Как я понимаю у PoS тоже есть своя сложность? Можно простейшие проверки ввести для PoS-блока, вроде
если текущий последний блок PoW? - повышаем сложность на m, (или в k раз (тут k, нечто вроде 1,00х тогда будет думается))
иначе* до этого был PoS */ - понижаем сложность на М, (или в K раз).

с этими мощностями, target'ом, сложностью уже крыша едет
человеческим языком предыдущий абзац - идут PoW-блоки, облегчаем генерацию PoS. Появился PoS - усложняем генерацию последующих. Ну и если скажем облегчение по -1 идёт, а усложнение на +5 (или облегчаем каждый раз на 0,1% а усложняем на 0,5%), то среднее устоявшееся соотношение PoW:PoS = 5:1



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


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

P.S. Не в курсе, для работы с исходниками биткоина/ppc/nvc что в винде лучше и проще, microsoft visual studio, или intel compiler? (этическая сторона дела, у какой компании воровать продукт не волнует   )

не нравится мне премайн, тем более огромный такой. но уж если его планировать, то
supply = 2000000.0 и смотреть на все объёмы проценты уже с ним

А может другую акцию какую-нибудь объявить а не раздачу премайна?
Например - неограниченая скупка трушек первый месяц старта: бит-цент, за 500 новых монеток. (ну курс прикинуть, чтоб тру было раза в 2 прибыльнее фармить чем бтц, тем более с нынешним приходом асиков туда - много ли на CPU нафармишь , а здесь-то как раз только для CPU майнер и будет, есть куда мощности приложить; и чтоб себя не разорить при этом, но тут думаю за пару месяцев фарма btc одной видюхой можно будет выплатные btc наколотить)

Может тогда к авторам алгоритмов обратиться? Как вы считаете, каковы перспективы переноса на openCL и т.п.? Или сразу в лоб "каковы по вашему мнению параметны, обеспечивающие наименьшую производительность на GPU)

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

Я не про то что PoW отключился, а то что инфляция после этого 2,8% осталась. А этого физически быть не должно, если годовое вознаграждение за PoS 1%.
Там же вообще и максимум в 1% получится только если все кошельки включены на генерацию PoS, и ни одной транзакции. Так что при одном PoS 2,8% - это явная ошибка в логике симулятора

P.S. самое неприятное - буквально же 10 строк кода и всё кажется абсолютно правильным, и вот где эта фигня скрылась так и не могу понять 

с coinAge сложнее. как я понял, это количество_монет*их_возраст (эдакий вариант человеко-часов).
И если с возрастом понятно - это всегда от Х1 до Х2 блоков {дней/часов}
А среднее количество монет прямо пропорционально их объёму вообще. (предложил бытак: среднее число монет в PoS-блоке = supply/2 * (1 число_блоков_за_60_дней)
Но это глюк симуляторный-то. У нас там либо PoS-монеты в 5 раз быстрее прокручиваются, из-за соотвественно большей скорости блоков, либо заморозка не "простимулирована", и одна сумма может месячную награду хоть 5 раз подряд за 10 минут получить.
Повторюсь, сейчас PoS-часть симулятора - это как банковский вклад с 1% награды, но по факту каждый год на 4% сумма возрастает  


Вот насчёт хешей, и их железных/CPU реализаций разведу руками. там всё на английском читать надо, а в этом я пас  

512 бит - это же не страшно. В конце концов, даже если формат блоков и их заголовков оставить полностью совместимым, можно будет старшие{младшие} 256 бит результата от хешей брать и всё.
Маразмом то это выглядит только если единичный расчёт хеша происходит, и нужна скорость. А у нас, в криптовалютах результаты вычисления всё равно миллиардами откидывают.

неужто все крипто-библиотеки такие жуткие - одни макросы 


p.s. На какое соотношение PoW|PoS блоков выйдет система, при стабильной работе, 29:1; 5:1, 2:1, 1:1 ?

не, в краткосрочном периоде она конечно плавать может, но для длительных промежутков нужно соотношение, к которому система будет динамически сложность PoS подгонять.
Иначе будет 100% доминации одного типа.
Простой пример. PoS-мощность пропорциональна всей денежной массе M. PoW-мощность равна сумме мощностей майнеров. Даже навскидку будет 3 периода:
1) старт первый(е) месяйы - экспотенциальный рост pow-мощностей. PoS-мощность практически нулевая из-за отсутсвия в природе достаточных сумм монет как таковых
2) первый год, стабилизация PoW, но денежная масса растёт очень быстро в арифметической прогресии (начальный майнинг буквально месяцы назад её было 0, и каждый месяц + М_м, инфляция пока бешенная). PoW-мощность практически неизменна, PoS-мощность растёт ровно с ростом денежной массы М.
3) окончание роста, инфляция постепенно падает на ~ +Пи%, PoW-мощность удваивается каждый год. (Итог - удвоение мощности-PoW, практически стабильная мощность-PoS)
То есть нужно эти мощности между собой как-то калибровать, и калибровка эта должна постоянно меняться, стремясь соотношение PoW:PoW-блоков привести к заранее прописанной константе.

Итого, навскидку, будут конструкции вида:
Смотрим период формирования последних блоков за неделю. Время₅₀₄₀. Корректируем текущую цель для PoW. target_pow  *= 168_часов время₅₀₄₀
Дополнительно можно учитывать поправку, насколько фактическое число блоков с самого старта системы отличается от расчетного
target_pow *= (время_жизни_системы_в_минутах 2) число_блоков
(не знаю точно ли это нужна ли вообще эта глобальная поправка. В BTC|LTC|PPC|NVC она есть где-нибудь?)
ну и напоследок if (target_pow > maximum_target) target_pow = maximum_target
Смотрим долю PoS-блоков за прошедшую неделю. p = число_pos_блоков_в_последних_5040_блоках 5040
Скажем условились, что в среднем каждый четвёртый блок должен быть PoS
target_pos= p * 4
и напоследок if (target_pos > maximum_target) target_pos = maximum_target

Всё, таргет майнеров подстраивается под скорость появления блоков; таргет pos подстраивается под свою долю в этой черед pow-блоков, соответсвенно и под генерирующее количество монето-лет, и под текущую сложность pow.


Заточенность под windows - это огромнейший плюс. Если брать массовость - то именно наличие windows-реализации, это необходимое и достаточное условие существования.