TrueCoin <-- правильная монета

[Storan]

С начальной гипер-инфляцией на ум пока два варианта приходит:
а) первые N блоков прибавка +М к награде. (Скажем reward += 100 - block_number/2000 даст в первых 200'000 блоков суммарный довесок в (0+100)/2*200000 = +10кк монет)

б) первые N блоков выпускать с абсолютно нормальной наградой, но с удвоенной частотой. За "одинарный" период времени по факту получится двойное накопление средств в системе. Из плюсов - эмоционально приятней соло-майнинг (в 2 раза больше находок). Им минусов - засорение блокчейна ненужными по сути заголовками (ежеминутного вала транзакций первые месяцы после старта системы явно не будет).



Тут ещё вопрос технического плана возникает. А возможно ли в форках на основе кода биткоина, организовывать "сборку мусора" в блок-цепи? Поясню что имеется в виду. Берём какую-нибудь красивую большую цифру. Пусть 100'000. Как только цепь достигает №200'000 -> все транзации до блока №100'000 считаются абсолютно истинными, и клиенты "выкидывают" старые блоки от 0 до 100'000 склеивая новый "супер-блок №100'000", в котором запечатлено итоговое состояние жизни системы на блоках 0-100000, с выкидыванием всех промежуточных транзаций (т.е. путь монеты в виде генерация(25)->A1(20)->A2(->A3 заменяется на генерация(->A3, ну и естественно все такие атомарные транзакции на один адрес суммируются и в итоге остается лишь одна транзакция на каждый задействованный адрес) , и этот новый блок соотвественно становится стартовым для системы. Все транзакции созданные после 100'000 блока, и ссылающего на блок с меньшим номером - при проверках входов перенаправляются на новый стартовый №.
Цепь достигает №300'000 - повторяется всё то же с блоком №200'000 с вырезанием диапазона 100'000-200'000, и т.д.
От потеряных кошельков это не спасёт разумеется - эти транзакции на зависнувшие адреса так и будут кочевать с супер-блока в супер-блок, увеличивая размер БД, но хотя бы на заголовках экономия будет всегда.
Ну и конечно никто не мешает для безопасности, да и просто параноикам иметь некие server-edition программы кошельков, которые будут всю первозданную цепочку блоков хранить и использовать.

[1715054828]

1715054828

[1715054828]

1715054828

[1715054828]

1715054828

[1715054828]

1715054828

[1715054828]

1715054828

[Storan]

Еще момент помните вашу формулу :

Code:

Reward = K * math.Log(difficulty) + 1.0 

Я вот думаю :
 какую вывести подобную( или др.) формулу,
 чтобы :
1) при высокой трудности майнеры
 на Асиках и т. п. оборуд.
 субсидировали маленьких майнеров.
 то есть чтобы награда за блок
 была обратно пропорциональна хэширующей
 мощности майнера.
 это была бы еще одна экономическая инициатива НЕ строить FPGA/ASICи

2) а при низкой трудности (скажем меньше
 100000) все майнеры получали бы поровну
, вне зависимости от своего MH/s

От формулы такое думаю получить невозможно. Если слегка модифицировать сам принцип майнинга только.
Например. Во всех существующих форках по сути каждый пул - это соломайнер. Для тру можно изначально сам майнинг организовать системно только в составе "обобщенного p2pool" со сложностью шар где-то в 4096 раз меньше чем текущее у сети (в принципе он может функционировать  PPS / PPLNS). И этот супер-п2пул уже может делить между всеми майнерами (сиречь обычными пулами, p2pool'ом, соло-майнерами) награду по своему разумению. Половину награды всем поровну "за участие", оставшуюся половину пропорционально супер-шарам; или что-то подобное.
Осталось только придумать механизм, запрещающий соло-майнинг в терминах биткоина. То есть все пулы, соломайнеры 2-го порядка, должны принимать в качестве правильных только те блоки, что сформированы в составе этого супер-пула.


По гипер-инфляции. Может в формуле награды К побольше задрать? Скажем +10 за удвоение мощности системы. Всё-таки первые года, после начальной приживаемости, мощность будет подниматься как раз при удорожании монет, и соответственно система будет пытаться "сбивать цену" увеличивая эмиссию.
Была ещё жуткая идея, комиссии за транзакции не просто передавать майнерам, а ещё скажем удваивать с них доход. А передаёт 1000 Б, на комиссию отдаёт 0.5, С подтверждая транзакцию получает с неё 1. Правда трудно рассчитать, что будет в ситуации когда цены уже стабилизированы и экономическая жизнь кипит - настоящую инфляцию возможно такая "халява" в комиссиях вызовет.

P.S. В международной теме каждый второй пост вида премайн -> скам? Печально что саму систему инфляции и платежей не обсуждают

[Storan]

100'000 за блок, при сложности 10^9... это эксахэши Eh/s когда пойдут где-то?

С логарифмом такого не сделаешь, слишком "горизонтальный" график, при больших значениях х (мощностей).

Может заменить функцию на квадратный корень: reward = sqrt(difficulty) ? Получится вместо логарифмического +R за каждый порядок сложности; увеличение награды в ~3 раза, за каждый порядок сложности. Гораздо более сильная обратная связь с реальным курсом монет, и более плавная.


(по х миллионы сложности, по у - награда... видно что логарифм стартует как ракета, затем чуть ли не горизонтален, а корень увеличивает награду более плавно)

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


p.s. На вкус и цвет фломастеры разные. Я полный профан в ономастике, эстетике и т.д., поэтому судить о вариантах, явно не моё 

[Storan]

Я правильно понимаю, эти итоговые 5% получаются так сказать "суммированием" собственно инфляции, и доп. эмиссии от сложности?

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

Как я понимаю в теории, практически для любого алгоритма можно запрограммировать фпга, создать асик; и они будут ad hoc гораздо энергоэффективней . Вопрос в том, сколько будет стоить их проектирование и производство. С двойным ша основная проблема имхо в том, что склепанные кооперативом на коленке, по жуткому большому техпроцессу, в сравнении с CPU|GPU - асики при этом жестоко рвут их в hash/s.
Естественно, если такие гиганты как Intel/AMD/Nvidia разработают асики, и начнут их выпекать на своих/арендованных передовых линиях, то они заведомо будут быстрее их же CPU/APU/GPU. Но если такие монстры электроники обратят внимание на валюту, то это де-факто уже состоявшееся признание, и проблема на чём майнят явно отойдёт на третий план.

[Storan]

Я все еще верю что и на GPU BMW
 оч плохо ускоряется. Это кстати можно проверить - в той бумаге (ссылку я давал)
 есть готовые проги на CUDA для BMW
 у кого есть такая видяха - может проверить
 и сравнить c CPU- что быстрее и насколько.
на OpenCL BMW реализации я не нашел.

Это где pdf была, работа университетская по вычислениям BMW? Так там где-то сссылки на программы/исходный код присутствуют?
У меня конечно не Fermi стоят, а обычна low-end gtx550ti, но проверить можно попытаться. На существующих ша-дважды/скрипт майнерах 40М/70к выдаёт, результаты всё-таки отличные от процессорных.

[Storan]

Да уж. получить Cuda SDK задача довольно не простая. регистрация, заявки в группах, всё на инглишь. Буду ждать результата.

Кстати по тому исследованию, они использовали 9400GT, в которая воддерживала cuda v1.0, нынешние 600-е уже c cuda v3.0 работают. Что там изменилось именно в отношении рассчёта хеш-функций только спецы конечно могут знать, но какое-то ускорение применимое к этой области за 3-4 года могло произойти на аппаратном уровне.


===============================================================================================================
А так ли на самом деле важно, у какой абсолютной величины "стабилизируется" М в первые 2-3 года существования? Всё равно ведь, существенно раньше этого (максимум через год после старта) появятся какие-то курсы и обменники true:btc, true:usd и увеличение мощностей от майнеров-фермеров, а следовательно и мощностная эмиссия будет в первую очередь зависеть от возможной прибыльности майна.

Ну и период пост-первоначального удорожания при ставновлении валюты никак не убрать. Допустим на определённом этапе жизни системы стабильный неспекулятивный курс достигнет 1true=1usd, ясно же, что в первые месяцы никто в такую стоимость "верить" не будет, и курс будет 1usd = 0,..01true; т.е. какая бы гипер эмиссия не была, как только true приживётся - её монета подорожает. (usd сдесь рассматриваю как самую универсальную меру стоимости в мире в наше время)

И с этой точки зрения, самая примитивная стратегия - пускаем всё на самотёк, возможно стабилизирует курс на осмысленных значениях значительно раньше, чем не слишком удачные попытки заранее подогнать агрегат М под нужную величину в ручном режиме (и прогоны в тесте/симуляторе тут мало помогут, будущие точные значения доверия+мощности не просчитаешь, только с потолка значения брать )

================================================================================================================
В английский драфт добавить бы уточнение к пункту про PoS, что после запуска его награда будет меньше целевой инфляции 2%-3%. PoS включится для стабильности/эффективности системы, а не для начала фазы "а теперь все копят монеты".

[Storan]

Стремясь очень быстро обуздать инфляцию, можно к несчастью обнаружить что желания сбываются  
Догадайтесь, какая "инфляционная" формула награды даёт такой +% эмиссии по годам?

1	2500,00%
2	100,00%
3	50,00%
4	33,31%
5	12,51%
6	11,12%
7	10,01%
8	9,13%
9	4,17%
10	4,00%
11	3,85%
12	3,67%

=====================================================
с кудой заминка. сволочная нвидиа через небольшое число минут делает устаревшим залогинивание на сайт, и всё отрубает. В итоге я со своим дрянным интернетом не успеваю за этот промежуток выкачать их библотеку. Но голь на выдумки хитра, попробую сейчас с авто-рефрешем вкладки "nvidia developer zone", может получится.


=====================================================
правильный ответ к таблице: BTC
и значит подобная плавная функция для похожего спадания инфляции будет выглядеть примерно так:
k=№_текущего_блока/(N_лет * число_блоков_в_году)
награда_за_блок = XXХ / e^k.
Здесь экспонента вместо двойки в степени, ради упрощения расчётов.

[Storan]

Ага,  а нам надо чтобы награда зависела
 от времени ( номер блока) и от трудности
 (ваша идея).

 или быстрое получение  невысокой инфляции
 плавно падающей от 10% до 2% (к 55 или 88 году).
 (это второй вариант оттуда же )
НО не то и другое вместе ((

НО прогресс с этим есть.

--------
А что будет с вашей формулой (с экспонентой)
после 12 лет - в году 55 и в 88 ?

Да с экспонентой в знаменателе больше юмора было. Это же чистой воды биткоин, только с максимально возможным сглаженным падением награды за блок (а не нокаутирующими скачками как у оригинала), и натуральным основанием (вместо двойки).

Code:

 w1, _ := math.Lgamma(8.0 * wDiff + 888.0)
 w2, _ := math.Lgamma(root(float64(block), 2) + 1.0)
 wReward = math.Abs((w1 * w2) / 100000000.0)

Суперфаворит - выдает до 700% гиперинфляции
 и затем скромно "худеет" .
Прирост в 2-3% здесь не используется,
 все получается автоматом.

В этой схеме есть место для PoS :
после гиперинфляции его можно включить
 начиная с 16% награды и снижая ее плавно до 1%
 в 55 году.
Это скорректирует недостатки фигуры.

От логарифма гамма-функции мозги плавятся. Я вот в экселе прикинул - эта жуть Lgamma(x) ассимтотически стремится к величине x * ln(x)... Мы же не физические формулы выводим, может на такой, всё же гораздо более простой вариант заменить? (ну т.е. будет  x:= 8.0*wDiff+888.0; w1, _ := math.Log(x) * x; y = root(float64(block),2)+1.0; w2, _ := math.Log(y)*y;

По-моему, самое главное к 5-10 годам "разумные" проценты, а годам к 20 "правильные" проценты подогнать. Просто к концу первого года числа совсем уж "гадальные" будут. Например неизвестно, сложность будет всё ещё 100 или уже 100'000.
Но в поздние сроки, годам к пяти можно на нынешнюю мощность сети биткоина уверенно ориентироваться, с поправками на менее эффективные cuda,openCL,FPGA,... Мощности можно прикидывать хотя бы потому, что если и за пять лет проект не развился, то его легче похоронить, чем бухгалтерским балансом в процентах.

Умоляю, ненадо 16% PoS, зачем средство платежей превращать в средство накопления   Пусть лучше фигура с недостатками будет.

P.S. с вышенаписанными формулами в лого-гамма-функциях, при сложности 20, и сроке майна 10 дней (7200 блоков) награда за блок будет 0,02 монеты... К итоговой награде надо константу десяточку хотя бы накидывать, а то не пойдёт народ копейку в час майнить  (Хотя если убрать премайн, и выкупать монетки по 1$ за десяток...  3$ за двое суток майна всей системы  )

[Storan]

Я уже прикинул в симуляторе. На поздних годах х*ln(x) отлично заменяет ln(Г(х)) (что естественно). В начальные годы на первый взгляд различия есть, но там из-за рандома и без изменения формулы проценты 2) 180%-250% 3) 80%-120% и т.п. меняются, так что не факт что реальные отличия в процентах будут столь кардинальны.

да вот, из экселевской таблички всё можно увидеть

Code:

x	ln(Г(х))	x*ln(x)
1E+00	0	0
1E+01	12,80182748	23,02585093
1E+02	359,1342054	460,5170186
1E+03	5905,220423	6907,755279
1E+04	82099,7175	92103,40372
1E+05	1051287,709	1151292,546
1E+06	12815504,57	13815510,56
1E+07	151180949,4	161180956,5
1E+08	1742068066	1842068074
1E+09	19723265828	20723265837
1E+10	2,20259E+11	2,30259E+11
1E+11	2,43284E+12	2,53284E+12
1E+12	2,6631E+13	2,7631E+13
1E+13	2,89336E+14	2,99336E+14
1E+14	3,12362E+15	3,22362E+15
1E+15	3,35388E+16	3,45388E+16
1E+16	3,58414E+17	3,68414E+17
1E+17	3,81439E+18	3,91439E+18

Отличие в два раза - до аргумента=10... это буквально первые 100 блоков системы. x=100 - это уже лишь четверть разницы; две недели жизни системы. и т.д.
Причём отличия-то эти не в аналогичного размера проценты эмиссии переходят в итоге, а просто в денежную массу, генерируемую в первые годы жизни системы.
С аргументами 8*wDiff+888, sqrt(block), прогнав по 20 раз первые года на этих почти синонимах получилось усредненная денежная масса по первым годам:
ln(Г(x)) : 155k; 480k; 950k; 1530k; 2230k; 3m
x*ln(x) : 215k; 700k; 1300k; 2130k; 3m; 3,9m
Как и ожидалось, гамма-функция постепенно догоняет х*ln (в абсолютных величинах разрыв растёт, а если смотреть соотношение -всё ближе и ближе друг к другу значения).
Принципиально разницы разумеется вообще никакой - один и тот же процесс в эмиссии. Но, по субьективным ощущениям простая функция тут лучше чем сложная.

Напоследок, +1 монетой за блок можно всё-таки одаривать. С теми же аргументами 8*wDiff+888, sqrt(block), и +1 к награде:
x*ln(x) : 480k; 1220k; 2160k; 3,2m; 4,3m; 5,6m
Проценты в последнем случае на 2й, 3й, 4й года получаются при этом ниже - но связано это в первую очередь с эффектом высокой базы, за первый год практически в 2,5 раза больше монет создалось.

[Storan]

Может не обращать внимание на процент 2-го года? В принципе он так гуляет только из-за того, что сильно может разнится майнинг в год первый. Может это и правильно? Майнило целый год лишь дясяток cpu - получи мизерную базу денежную и как следствие огромную инфляцию на следующий год, при реальной раскрутки валюты. Если валюта стартанула как ракета, сразу распространившись, было выпущено большое число монет в первый же год - да, возможно на второй год инфляция упадёт даже до двузначной, ну так видимо это будет инфляция уже работающих платежей/торговли.
Вдобавок, такой майнинг лишь силами нескольких одиночек  вхолостую, почти гарантировано избавляет от "призрака Сатоши" - десятков процентов первоначально намайненых монет, непонятно каким образом зависших, и самое печальное возможно всё-таки хранимых, и лишь у нескольких индивидов.

Моё эволюционировавшее в данном топике восприятие криптоплатежей, теперь полностью склоняется к большой пользе эмиссионых процентов, получаемых опосредовано из мощности; они гораздо адекватней сухих алгоритмических +pi% год, этому алгоритмическому "печатному станку" наплевать, что там в реальности происходит с валютой. А вот "мощностная эмиссия" и её изменение - это самое прямое следствие популярности валюты, и распространенности монет в сделках, и обменного курса.


Смысла отдельно тестировать одни и те же коэффициенты для Ln(Г(х)) и х*ln(x) нет. С учетом "рандомных" мощностей, по прошествии месяца со старта, эти формулы становятся буквально одинаковы (с точки зрения реагирования системы, и начисления в %).
Да, в абсолютных значениях x*ln(x) будет всегда чуть больше, потому что оно своеобразная асимптота сверху логогаммы, но на больших значениях оба этих варианта будут неотвратимо сближаться.
/ x*ln(x) > ln(Г(х)), где х>0;    lim x->oo, x*ln(x)/ln(Г(х))=1 /

[mech]

Тема интересная, где можно получить клиент?

[Storan]

Тема интересная, где можно получить клиент?

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

[Storan]

Может "смухлевать"? 
В первые годы добавить ещё одну функцию к награде.
образец идеи:

Code:

x := wDiff + 1000.0
w1 := math.Log(x) * x + 1.0
y := float64(block)
 w2 := math.Log(y) * y + 1.0
ycur := float64(block) / float64(year);
guile := 20.0
ygui := 3.0;
w3 := guile * ycur / ygui;
if (ycur > ygui) {w3 = guile * (2.0 - ycur/ygui)}
if (ycur > ygui*2) {w3 = 0}
 wReward = math.Abs((w1 * w2)) / 100000000000.0 + w3;

(продемонстрирован совсем черновик. 3 года линейный рост от нуля до 20, следующие 3 года спад с 20 до 0).

общие свойства этой функции-добавки: в промежутке [0;X ) - растёт, в промежутке (X;N] - уменьшается, >N == 0
X: это 1-3 в годах; N: 4-7 лет.

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

[RoadTrain]

Можно в двух словах, как награда PoS рассчитывается у вас?

[Storan]

...
Чет я засомневался : достаточно ли просто вычитать PoS% из poW% , или тут более сложная
 зависимость ? <-- чтобы вычислить %% реальной
(целевой) инфляции" ?

Ну здесь "идеальная" формула проста сама по себе... [%эмиссии_PoW*(число_PoW_блоков)+%эмиссии_PoS*(число_PoS_блоков)]/(общее_число_блоков)=%итоговой_эмиссии.
Но тут главнее не переборщить с зажиманием. Вон японцы 20 лет экономили, а счас рубанули сплеча - для роста экономики в ближайшую пятилетку удвоим денежную массу и точка 

Пора попробовать написать майнер для Skein(BMW())

Понимая, что в практичных вопросах (вроде тупо  скачать 1гб библиотек у нвидиа, и скомпилировать cuda-miner) я полный профан; вопрос дилетанта - как насчёт того чтобы этот майнер поддерживал C++ AMP? Как я понял, это некая библиотека/надстройка над С++, где сам компилятор определяет, возможно ли распаралелить функцию на GPU (включая всё новомодные встроенные APU ati|Intel HD) и соответсвено ускорить, где это возможно, скорость простейших хеш-вычислений.

[Storan]

 C++ AMP нам не поможет ( он под Win).
 А большая часть койно-софта (даже та что
 работает под Win) собирается на *nix

 Я буду издеваться над cpuminer,
 там как и в моих экспериментах
 с проверкой скорости хэширования
 чистый C - надо переписать несколько функций и все !
 Но есть маленькие трудности -
1) клиент все еще не форкнут,
 а там надо будет наверное оборачивать
 skein/BMW из библиотеки на C в C++
 части клиента.

2) после написания майнера надо его проверить, и где брать для него getwork ?
Это что еще и пул придется написать ?

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

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

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

[Storan]

Совместимость C и C++ это магия ж)
http://en.wikipedia.org/wiki/Compatibility_
of_C_and_C%2B%2B

В статье написано так :

Code:

Система C++AMP позволяет переносить вычисления на GPU (видеоускорители) без внесения большого количества изменений в программы. Код, который не может запуститься на GPU, например, из-за своей сложности, будет автоматически запущен на центральном процессоре с применением SIMD (SSE) инструкций. Реализация системы от Microsoft (единственная на настоящий момент) включена в Visual Studio 2012 и включает в себя отладчик и профилировщик. Поддержку других платформ и оборудования могли бы реализовать компания Microsoft или другие в будущем.

То есть BMW не ускорится на GPU (по причине
 именно своей сложности)

В то же время я не верю, что этот AMP
будет быстрее работать на CPU, чем cpuminer.

Потом у меня все равно нет Win ,
так что если хотите - можете попробовать написать майнер для AMP (только вам придется
 найти свою библиотеку для Skein и BMW,
 ибо моя найденная либа - под Юникс).

Тут дело не в опенсорсе или моей Юниксомании
 (предполагаемой) , а в том что проще
 кое-что дописать кое-где, чем изобретать
 велосипед почти с нуля.

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

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

[Storan]

Code:

 x := wDiff + 100.0
 w1 := math.Log(x) * x + 1.0
 y := float64(block)
 w2 := math.Log(y) * y + 1.0
 ycur := float64(block) / float64(year)
 guile := 20.0
 ygui := 3.0
 w3 := guile * ycur / ygui
 if ycur > ygui {w3 = guile * (3.0 - ycur/ygui)}
 if ycur > ygui*2 {w3 = 0.0}
 wReward = math.Abs((w1 * w2)) / 100000000000.0   + w3

Эта система формул еще лучше

Пора попробовать написать майнер для Skein(BMW())

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

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

[Storan]

Да проверок и не надо, вместо 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-ядер, и т.д.

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

[Storan]

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