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

А-а-а, на этот форум кроме наших проникли и человеки? 

Вопрос же с подвохом. Нужны CPU-мощности, а у майнеров-на-PC в сегодняшнем их понимании, мощности GPU-шные.

В продолжение холивара: имхо, опыт xUSSR 90х-00х годов, со всей очевидностью показал что при нулевой стоимости софта/отсутствии саппорта по нему же, в домашних компах и малом бизнесе невозможно существование ничего кроме винды - и очевидно из-за доступности и качества продуктов для рядового потребителя. Так что, если бы не жадность мелкомягких в ценах на свои продукты, они давно бы могли стать всеохватывающими мировыми монополистами.

Могу продолжить список:
Oracle (Sun) Solaris
Apple OS X...
Из "удобоваримого" и юзабельного это всё ...
Причем OS X лучше всего...

Собиратель программы из исходников в моём исполнении прям по пословице "заставь дурака богу молиться, он весь лоб расшибёт"

вроде ubuntu самую последнюю поставил, аж бетку 13-ю... Один фиг, QT creator ругается на старые пакеты, не находит QMainWindow.

З.Ы. А эти С-шный набор алгоритмов нельзя в виде библиотеки скомпилировать, и потом подсовывать симулятору/проекту на любом языке?

С майнингом тогда можно сделать так. каждые ~500'000 блоков, PoS-генераторы, голосуют за варианты по добавлению/замене хеш-алгоритмов в цепочке вычисления PoW-блоков. Но это слабая страховка вообще-то. Как я понял, в том же битке, как при появлении fpga, так и при слухах о запуске проектирования/начале поставок асиков, никто не мешал текущей команде разработчиков объявить что с блока Х/даты Ч вычисление переходит на другое - пример ша2(ша3(...)). Но никто не захотел/или им не позволили такой поворот осуществить. С точки зрения хард-форка, это ничем не отличается от допустимых блоков в 0.7/0.8 версиях - старые кошели никак не смогут работать с новыми условиями существования цепочки блоков и точка.

p.s. а нелюбимый linux запускается в каком-то варианте на windows virtual pc? Что-то две "сборки" качнул, на этапе установки всё и тормозится, хотя "родные" винды хр-2к-me нормально устанавливались и включаются.

Хочу добится, чтобы в итоге true в том числе и под visual studio "портирован был" так сказать. Плюс, да простят мну поклонники Only-crossplatform-GNU, но такое ощущение, что bitcoin-qt написан на java, такой в нём запуск тормознутый и появление окна из трея; если для новой валюты под винду удастся сделать "почти дефолтный" нетормозной кошель - это возможно для успеха будет не менее важно всех хороших идей, вложенных в создание.
Но с текущим вниканием в ппц/бит, наверно действительно будет проще пока mingw поставить.


А как понять идею параллельного майнинга? Если возможно искать nonce m способами - как только для одного из вариантов создаётся очень быстрый код на GPU, или вообще FPGA - остальные считай автоматически вымирают, не выдержав конкуренции.

По-моему с майнингом другая проблема более чем реальна - как только криптовалюта выходит за круг гиков/анархистов и т.п. и внедряется в массы; то если правительства/элиты/корпорации вдруг не "убивают" её (валюту) целиком, то уж майнинг/сбор_комиссий своими мощностями полностью под контроль могут забрать. Как раз для извлечения доходов.
Тем более в инфляционной валюте. Представить, что владеешь 30% мощностей генерации True, которая обеспечивает хорошую часть мировых платежей - это же получение буквально "нахаляву" 1% от мирового оборота финансов. В дефляционных-то наоборот, когда эмиссия по-факту кончится (если при этом валюта не умирает), все сбереженцы будут беречь своё добро. Мало транзакций -> мало комиссии -> PoW-майнинг уныл.

А в МС2 как я понял развивают идею нескольких хеш-функций?

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


P.S. странное какое-то Go, что даже в математических "примитивах", самописное точнее системных библиотек.

P.P.S. boost - это что-то unix'овское или сторонняя библиотека которую можно добыть? visual studio ругается что знать такого не знает.

a зачем root(а,n); чем math.Pow(а,1/n) плох?

и в конце getWdiff, не лучше ли diff вычислять через деление long double (образно diff := float80(&targets[0]) / float80(bits) , не знаю как правильно с точки зрения синтаксиса описать)
Хотя конечно заметную погрешность целочисленное деление только при малых diff будет заметно давать 1 -> 2 -> 3 ... а 1000 и 1000.13321 уже по сути равны

а где все эти функции смотреть хотя бы? (и скачать ещё по возможности. надеюсь при закидывании в VCS оно подхватится хотя бы на уровне подстветки синтаксиса. а то в браузере не доходит просто до меня смысл кода вообще)

А дальнейшие нули найдутся полюбому. Это же нарушение стойкости будет, если в i-м байте результата 1 чаще чем 0 встречается

second - для последних 5040 блоков - время в секундах от "старта" системы до появления этого блока (в идеале для последнего блока = №блока*120)
delta_time - количество секунд между последними 5040 блоками (ну т.е. в идеале это должно быть близко к 120 * 5040 = 604800

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



================================================
и похоже запихивать в симулятор всё-в-одном было с моей стороны ошибкой.

Проще несколько работающих разновидностей делать:
 один, оперирует строго 2х минутными блоками и заданным соотношением pow|pos блоков, меняя по составленному алгоритму pow_target, % - и расчитывая только денежную массу.

другой - вообще на эмиссию как таковую не смотрит, а тестирует калибровку target'ов, чтобы блоки подгонялись под 2 минуты (У Бальтазара в NVC ведь сделано как-то "мгновенное" изменение мощностей, и неплохо кажись. Правда PoS там явно рассчитан на жизнь не в стадии роста системы, а в стадии стабильности. Поскольку у инфляционной валюты стадия роста это практически вся её жизнь - как-то расчёты PoS-мощности нужно подкорректировать, или полностью перерабатывать даже)

http://pastebin.com/REZUfBQ1

только пока редактировал/исправлял такую кучу-малу сделал. к реальному коду меня подпускать нельзя 

===========
ну и на денежную массу конечно внимания не стоит обращать в этом глюкодроме, когда target у pow скачет от 0 до максимума - там и награда за блок соответственно такая же неадекватная выходит.

У меня со симулятором какой-то  полнейший затык. А как "по стандарту" сейчас везде сложность пересчитывают? По фиксированным N блокам, или по фиксированному T "реального" времени?

Чё-то пересчёт по блокам начинает жуткие фортели выдавать, когда PoW-мощность "мгновенно" падает после предшествующего роста быстрого. И время для следующих блоков в десятки раз от номинального иногда возрастает.
То ли действительно так и должно быть если по блокам считать, то ли симулятор глючит жесточайше 

А как компилятор - настроен на максимальную скорость?

Так вполне себе значения. 000000F.... базовая сложность - и её уже соло-майнер переваривает на "норму"

p.s. на чем хоть выполнялось, сколько потоков?

попробую вечерком симулятор для го сбацать:

пока идеи такие
первые 30 дней отключено PoS. потом считаем что где-то половина средств "размазались" довольно равномерно, и начали участие в PoS-генерации, эта "половина" соответсвенно будет постоянно расти с ростом М
Усреднённая PoW-мощность будет расти каждый год примерно в (1+10/year) раз. (первый год - в 11 раз, 2-й в 6 раз, 10й - в 2 и т.д. с замедлением скорости роста). "Мгновенные" дневные колебания от этой величины будут равномерно распределены в диапазоне -25% +25%
Время появления блоков будет вычисляться по-чесному, через геометрическое распределение. с учётом pow-pos мощностей, и их же target'ов.
pow-pos target'ы будут рассчитываться каждый раунд

pow-эмиссия включает в себя награду за логарифм сложности + пи% годовых ко всей денежной массе
pos-эмиссия состоит из 1% к монето-годам затрачиваемым на блок.


вопрос. как в Go корректно объявить массив на 5040 элементов?

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

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

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

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


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

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

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

 4) Aes назвать нельзя - будут путать с AES )

  Объявим потом конкурс с призом - и пусть
  сообщники решают как назвать.
 Это удачный маркетинговый ход ИМХО.
 Надо будет почитать про крауднейминг,
 чтоб все сделать правильно.

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

 Еще мы могли бы раздавать из премайна
баунти за развитие проекта
 как это делал CoinHunter-1 ( пока его не сменил второй безумный царь Solidcoin'a )

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

 Для чего еще можно исп. премайн ?

  5)PoS можно запустить после раздачи премайна, надо только проверить в тестнете все.
 В общем я за простую раздачу премайна,
 без связывания получателей какими-то условиями ( той его части что не баунти за равитие).