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

[Storan]

да моя идея проста. из вашего первого поста. Стабильно низко-инфляционная валюта
на 20й год - денежная масса больше на Х% чем на 19-й.
на 120й год - денежная масса больше на Х% чем в 119-й 

(причём PoS эмиссия суммарно не должна превышать инфляцию - в противном случае для держателей средств валюта становится дефляционной).

Просто повторюсь. [Бешенно, потом плавно] эмитируем N лет, а после замедляемся и (а) стабилизуемся, (б) - потихоньку сжимаемся.
Эти идеи уже воплощены. (а) - NVC, (б) - BTC.

Если задача создать такую систем - то никаких формул выдумывать не нужно. Максимум, создать почти копию биткоина с PoS, где pos-блоки не будут генерировать проценты, а сразу будут жить поножным кормом с комиссий, как в оригинале PoW, по прошествии 12-20 лет.

p.s. а как в Go деление по модулю выглядит? хочу промежуточные данные на экран хотя бы раз "в день" выводить не чаще, иначе ощущение что ядерный взрыв рассчитываешь, по скорости обработки 
if (!(block%720)){...} - такая конструкция нужна


p.p.s и да, как будет выглядеть функционированние криптовалюты даже слабо-инфляционной не говоря про стабильную/сжимаемую денежную массу никто пока точно не скажет. Попросту ниже 10% эмиссии нет ещё нигде (даже в старейшем "дефляционном" биткоине)

[1713473628]

1713473628

[1713473628]

1713473628

[1713473628]

1713473628

[Storan]

Code:

package main

import (
"os"
"fmt"
"strconv"
"math/rand"
"math"
)



var block = 0//block count ( for genesis block = 0 )

var maxBlock = []int {
262980,
525960,
788940,
1051920,
1314900,
1577980,
1840850,
2103840,
2366820,
2629800,
2892780,
4733640,
4996620,
5259600,
}


var percent_year = 0.0314159
var percent_day_multi = math.Pow(1+percent_year, float64(1.0/365.0))
var percent = (percent_day_multi - 1) / 720.0

var PoS_percent = float64(0.01);

var Coin = int64(1000000)
var Cent = int64(10000)

var mplus, wMplus, sMplus float64

var wDiff = float64(1.0)
var sDiff = 0.0001

var supply = 0.0//moneysupply
var fees = 0.0

var wHour = 29//PoW blocks' rate per 1 hour
var shour = 1// PoS blocks' rate per 1 hour

// 1st year - hyper-maining.
var nblock_like_premine = 1000000
var bonus_premine = float64(20);


var cepochka_ostatok = float64(0);
var freq_pos = float64(0.2);
var max_pos2pow_dobavka = float64(0.25);

var ncount_pow = 0;
var ncount_pos = 0;

func main() {
rnd := rand.New(rand.NewSource(755875))
for {
x := 0.0;
if block < nblock_like_premine {x=1.0 - float64(block)/float64(nblock_like_premine)}
wReward := bonus_premine * x + supply * percent;
sReward := float64(0);
if rnd.Float64() < freq_pos{ // PoS-block
age_block := rnd.Int63n(60*720) + 30*720
coin := (0.3 + rnd.Float64()*0.4)*supply/(60*720*freq_pos) // 60 - srednij vozrast v dnyah, 720*freq_pos - blockov v den'. 0.3+rnd*0.4, v pos zadeistvovany 30%-70% vseh sredstv
coin_age := coin * float64(age_block) / float64(maxBlock[0]) //pseudorandom  coin_age in days
sReward = float64(coin_age) * PoS_percent
cepochka_ostatok += wReward - sReward // nedoemmissia, ili izlishki
// fmt.Println("Age:", age_block, "Coin:", coin, "PoS: ", sReward)
ncount_pos++
}else {// PoW-block
if cepochka_ostatok > 0{ // razmazywaem nevvedenyu emissiu iz pos po sledujshim pow
if cepochka_ostatok > wReward * max_pos2pow_dobavka{
cepochka_ostatok -= wReward * max_pos2pow_dobavka
wReward += wReward * max_pos2pow_dobavka
}else{
wReward += cepochka_ostatok;
cepochka_ostatok = 0
}
}
ncount_pow++
}

if sReward == 0{
supply += wReward
}else{
supply += sReward
}

// if block%(maxBlock[0]/10) == 0{
// fmt.Println("moneysupply: ", strconv.FormatFloat(supply, 'f' , -1, 64), " at block #", block, "year #", block / maxBlock[0])
// fmt.Println("PoS_blocks =", ncount_pos)
// fmt.Println("PoW_blocks =", ncount_pow)
// fmt.Println("==========================================================")
// }
block++
if block > maxBlock[10] { break }
}
fmt.Println("moneysupply: ", strconv.FormatFloat(supply, 'f' , -1, 64), " at block #", block, "year #", block / maxBlock[0])
fmt.Println("PoS_blocks =", ncount_pos," PoW_blocks =", ncount_pow)
fmt.Println("==========================================================")

os.Exit(0)
}

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

[Storan]

Эх, ещё одна идейка, в порядке бреда:

Награда за блок - положительная обратная связь со сложностью генерации этого блока, как пример:
wReward = 10 * ln (wDiff_base / wDiff);

в переводе на человеческий язык:
*) майнинг на базовой сложности - награда 0
*) увеличение сложности в 1000 раз, прибавляет ~69 монет к награде за блок

схема примитивная конечно, но посылы следующие:
накопление монет в системе на старте, возрастает с появлением новых участников (мощностей);
если/когда система попадает в реальную экономику (хотя бы на уровнеь битков 11-12-го года), именно реальный интерес к валюте (увеличение мощностей) увеличивает её эмиссию;
всё ещё продолжающееся развитие микроэлектроники позволяет надеяться, что и при стабильном состоянии системы уже и с "огромным" охватом, будет постепенное наращивание мощностей -> незатухание эмиссии.

ну и абстрактный пример:
пусть i7-4770 выдаёт при майнинге 1Mh/s, и это базовая мощность системы.
ниже подразумевается что сложность уже пересчитана под текущие мощности
майнит один i7: награда_за_блок = 10*ln(1) = 0;
майнят два i7: награда_за_блок = 10*ln(2) = 6,931;
майнит десяток i7: награда_за_блок = 10*ln(10) = 23,026;
майнит тысяча i7, достигли 1Gh/s: награда_за_блок = 10*ln(1000) = 69,078;
умельцы подключили gpu, эквивалентная мощность 1Th/s: награда_за_блок = 10*ln(1000000) = 138,16;
нашествие асиков, эквивалентная мощность 1Ph/S: награда_за_блок = 10*ln(1000000000) = 207,23;
будущее, мощность системы достигает эксахеша: награда_за_блок = 10*ln(1000000000000) = 276,31.

[Storan]

В логарифме - отношение сложностей.
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, которые долго искать и гораздо быстрее проверять.

[Storan]

да точно Target - это то про что я и говорил.

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


К сожаленью, выход от майнинга одинаков не будет

Если кто-то имеет 1Gh/s, а другой 1Mh/s - первый будет получать 99,9% тут уж ничего не поделаешь.

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

[Storan]

С процентами ничего не поделаешь. Тут 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% народом как программирование/. А в реальных проектах, один практик сотню теоретиков за пояс заткнёт

[Storan]

Вы про ту кривую, что у них в wReward присутствует math.Pow(wDiff, float64(0.16666666666666666))?

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


Данный корень n-й степени и логарифм одновременно вообще станно использовать. одной рукой "урезаем" награду на Х, другой тут же добавляем Y.


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

[Storan]

Ну тогда второй вариант из примера?
награда_блока_за_сложность = 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? (этическая сторона дела, у какой компании воровать продукт не волнует   )

[Storan]

Премайн в 2млн? это RIP на старте, без вариантов 

Вон, вокруг NVC сколько какахо-метания было, из-за залога на биржу сотни к.

по коду:
я в формуле логарифма накосячил, было 10 + 1 * за_каждый порядок_мощности.
если 10 + 10* считать, то правильный коэффициент конечно же var coef = float64(4.3429448190325182765112891891661)

дважды увеличение индекса (block) - это вроде попеременного подсчтёта PoS и PoW блоков ?

а что переменные fees, txFees пытаются подсчитывать?

[Storan]

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

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

[Balthazar]

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

[Storan]

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

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

[Storan]

Ukigo, как до жирафа только сейчас дошло.
В последней версии симулятора где-то логическая ошибка.
После того как PoW вырубается, и остаётся один PoS, инфляция вообще не может превышать 1% никоим образом. а она почти 3%.

Что-то с PoS-куском начислений неладно.




P.S. rnd := rand.New(rand.NewSource(int64(time.Now().Nanosecond()))) - для разных рандомов при запусках

[Storan]

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

Случайность , да можно инициализировать от времени и/или от PID процесса симулятора.
Это я переделаю в след. вариантах.

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

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

[Storan]

Итак:

в начале каждого цикла for{
wReward = 0
sReward = 0


но это ещё не всё.
coinAge := rnd.Int63n(89970) + 30
это строка должна зависить от supply.


проверку правильного PoS предлагаю считать так. отключаем PoW прям через год (262980), и смотрим прирост денежной массы годика за 3, не больше
1 -> 2, и 2 -> 3 - везде должно быть меньше 1%, в идеале (0,25%-0,5% всё-таки валюта расчётов, а не сбережений). Но если суммарно с одним PoS прирост больше 1%, мы не PoS расчитываем, а какую-то ерунду.

coinAge := rnd.Int63n(89970) + 30 - показывает 4% между вторым и третьим годом чистого PoS, значит это ерунда 


upd.
ок, отвлекать не буду, это на самом деле важнее хорошую хэш-функцию найти.

[Storan]

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


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

[Storan]

У нас же PoS и PoW по очереди работают... Зачем инфляцию в PoW снижать?
Вернее так: награда за PoW - это и есть расчётная целевая инфляция. Когда проходит PoS-блок, он эту награду фактически отменяет, заменяя своей 1%. Так что в реальности как бы поднимать % не пришлось

Hash = Skein-256(BMW-512(Groestl-512(Block_Header))) 
Анализ Кессак по-русски можно. Может ещё кто подключится заодно. Не может ведь 99% форумчан интересовать один только курс BTC и его изменения 

[Storan]

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

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


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

[Balthazar]

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

[Storan]

Она должна стабильно работать при ЛЮБОМ
 соотн. от скажем 28:2 до 2:28 или типа того

не, в краткосрочном периоде она конечно плавать может, но для длительных промежутков нужно соотношение, к которому система будет динамически сложность 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.

Смотря на каком языке либа написана )
для передовых хэшей выбор либ ограничен. (

Keccak стал стандартом и терь его напишут
 на чем угодно.
остальные кандидаты - как получится...
 
На Go есть BLAKE, Keccak , Skein.
Но нет майнера. (

На Python есть майнер, но pyskein написан
 для 3.x версии (

BMW нет ни на Go ни на Python.
И все равно нужны функции на C++ (C).
Для клиента.
К сож. конкурсные исх. на C заточены
 под Windows и нам не годятся.

Транкировать 512 -> 256 наверное можно
но не хотелось бы...

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