Bitcoin Forum

Local => Альтернативные криптовалюты => Topic started by: Ukigo on March 25, 2013, 11:09:40 AM



Title: TrueCoin <-- правильная монета
Post by: Ukigo on March 25, 2013, 11:09:40 AM
Сделать что-ли свой форк ???

 Свойства будут такие :





Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on March 25, 2013, 03:24:27 PM
PoS без майнеров придумывать не надо, он уже придуман и вполне себе живет без майнеров.

Защититься от спама без комиссии очень просто, у меня есть немного недодуманный концепт. :)


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on March 25, 2013, 04:10:00 PM
Майнинг необходим и PoW тоже. Потому что являются идеальным механизмом децентрализованного распределения монет.

У конкурентов работа такая, потому и утверждают :)

Суть проста - добавить в транзакцию поле nNonce, и требовать от автора генерацию PoW-хэша для нее, вместо текущего txid. При этом таргет расчитывать с использованием существующей формулы расчета приоритета, и для включения в блоки выбирать наиболее соответствующие условиям транзакции (приоритет со временем меняется, так что требования к хэшу отправленной транзакции тоже будут смягчаться со временем). Это сделает спам практически невозможным, но не создаст трудностей для нормальных юзеров. Потому что спамеру, чтобы перевесить легитимного юзера с нетбучным процем в плане скорости создания транзакций, потребуется мощная и дорогая ферма на GPU.

Если нужно избавиться от комиссий, то это единственный выход.


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on March 25, 2013, 05:46:19 PM
PoS-генерация не создает инфляцию.

maaku имеет в виду, что ПоС Sunny' НЕ
 соотв. НИ одной из существ. схем описанных в биткойн-вики.
Ну и что, никто же не запрещает разработать свою собственную схему. Да и вообще... Не хочу принижать значение теоретических исследований, но реально работающее решение (пусть и с недостатками) лучше самой красивой теории, пока она не имеет воплощения на практике.


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on March 25, 2013, 07:39:36 PM
Что ваще тогда с него можно поиметь полезного ?
Независимость от парней с асиками/видеокартами/что-то еще по списку.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 25, 2013, 09:04:02 PM
Не знаю, насколько реально воплощение. По поводу (2) и (3); если удастся найти хешируюший алгоритм, "идеально" подходящий под архитектуру arm - то это решением и будет по сути.
(а) - это всё ещё бешено растущий рынок именно интернет-гаджетов - планшеты и смартфоны
(б) - arm всё-таки архитектура именно цп, и написанный на ЯВУ, этот алгоритм без проблем перекомпилируется на весь зоопарк х86 ноутбуков-десктопов-серверов.
(в) раз нужна инфляция и вклад мелких участников - заранее прописать в алгоритме диапазоны изменения сложности; а не число_блоков_за_время. Завёл на своём планшетике майнер - хоть вас 100 будет таких гиков, хоть миллиард пользователей - каждый за день свою монетку нагенерит.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 26, 2013, 02:25:05 PM
А вам не кажется, что удвоение денежной массы каждые 10 лет - слишком уж большая инфляция?

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


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


Title: Re: TrueCoin <-- правильная монета
Post by: rPman on March 27, 2013, 07:54:41 AM
Единственное (основное) условие заставить что-либо делать/не делать людей - это личная выгода/не выгода.

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

Как заставить народ не хранить деньги -физически уничтожайте их :), без условий, периодически в % от всего объема.

И да, вы действительно верите что именно ваш форк составит хотя бы конкуренцию уже существующим bitcoin (он просто первый) и litecoin (он просто второй, а так же у него есть очень хорошая поддержка в виде бабла и ддосеров)?


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 27, 2013, 10:49:34 AM
а вот совсем простая
жесткая схема №3 :

 В этой схеме "рост" не измеряется.

 1) раз в неделю баунти увеличивается
  в среднем на 0.04% ( что примерно соотв.
  >2% годовых - надо посимулировать
  считая сложные проценты понедельно,
  чего пока не делал ;) ).

 2) процент прироста баунти плавно уменьшается первые 129600 блоков
 ( около 6 мес ).
 
 3) по достижении блока № 129600
  % прироста баунти достигает 0.02%
 и потом остается постоянным навсегда.
 ( примерно эквивалентно > 1.2% в год )
 
 Это выглядит как инфляционная монет,
 но на практике скорее будет небольшая
 дефляция ( степень ее будет зависить
 от популярности форка и притока в него свежих денег извне).
 Но дефляция должна быть много меньше чем в Биткойне.

 Все эти выкладки не учитывабт влияния
 PoS (если он конечно будет ;) ).



(1) Видно что вы не математик  ;)  x^(365,25/7) = y. x - недельная инфляция, у - годовая инфляция, ^ - возведение в степень; и ничего ни в какие симуляторы загонять не надо; можно в виндовом калькуляторе считать.
Может устоявшуюся целевую инфляцию (годовую) взять каким-нибудь "красивым" числом - например, е или π, или что-то подобное?

(2)-(3) Пол года - не слишком ли короткий срок? Особенно учитывая большой премайн - выходит слишком подозрительно, "с запашком". Хотя бы годик гипер-инфляцию нужно (ну скажем за первый год удвоение-утроение награды за блок), а на второй плавное понижение до целевой константы прироста. Ведь всё равно, если форк выживет в валюту - соотношение коины/мега-хеши у первых майнеров будет больше, чем у майнеров в устоявшейся системе (надеюсь понятно расписал; да я на старте майнил лишь по 10 коинов, но с затратой своим 1Mhash/s. Сейчас /прошло n годиков/, за найденный блок получают 50 коинов, но затраты на нахождение выросли до 1Ghash/s; вроде награда в 5 раза выросла, но по сути на ту же мощность в 200 раз упала ;D).


Title: Re: TrueCoin <-- правильная монета
Post by: rPman on March 27, 2013, 11:04:49 AM
Невозможно говорить о таких вещах как инфляция, спрос, обороты,.. если не учитывать аналитику из 'реального мира'. Форк же чисто математически крутится только на основе своих ограниченных данных - количество участников, энергетическая мощность, активность использования и комиссии, при этом половина из этого подвержена манипуляциям.

Хорошим подспорьем были бы механизмы по привязке хотя бы к 'большому брату' типа bitcoin, для обеспечения p2p-обменника (настоящего), но эти данные очень подвержены манипуляциям, поэтому настоящим спросом и объемом торгов такие считаться не могут.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 27, 2013, 12:33:04 PM
Ну эта "инфляция" именно внутрисистемная же будет. А про "реальный мир" и в применении к старшему бит-у говорить-то ещё очень рано, никакая устоявшаяся валюта, даже по отношению к фиатным не может такие скачки курса иметь.

Почему мало смысла специально привязывать нью-труе-коины, к бит-ам? - а у биткоинов родовая болезнь, которую он навряд ли когда преодолеет. Огромная сумма биткоинов непонятно где находящаяся. И огромна она в том смысле, что скорее всего даже превосходит и намного, биткоины "светящиеся" в транзакциях/участвующих в обороте. А поскольку новых поступлений в системе будет всё меньше, и невосполнимые потери битков будут всегда, то значимость этого дамоклова меча "мутных" первоначальных накоплений никогда не пропадёт.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 27, 2013, 05:55:42 PM
Здесь будет пост про варианты PoW
 для TrueCoin. Он будет переписываться
 иногда.

1) Почти классический вариант :
  Hash = keccak256(Grøstl-512(Block_Header))

2) схема с измененным Scrypt.

 Другие хэшфункции удорожат и отсрочят
разработку спец.
 ASIC/FPGA и избавят TrueCoin
 от скачков мощности на первых порах.
 к сожаления оба варианта НЕ CPU-only.
 Однако под них нет OpenCL майнеров (пока).
 
В порядке бреда. Можно всех пять финалистов sha-3 запихать в цепочку. И к хэшам ещё какую-нить гадость подмешивать.
псевдокод:
sha = sha2(Block_Header);
my_prng.init(sha);
hash1 = Blacke(Block_header) + my_prng.rnd();
hash2 = Groestl(hash1) * my_prng.rnd();
hash3 = JH(hash2) + my_prng.rnd();
hash4 = Keccak(hash3) * my_rpng.rnd();
final_hash = Skein(hash4);
// тут как пример гадости - свой примитивный гпсч, который инициализируется от входящего {блока;nonce}, и в случае проверки для заданного блока естественно выдаст те же "случайные" значения.
Вдобавок, не обязательно соблюдать порядок хеш-функций.
псевдокод:
f[] = {Blacke, Groestl, JH, Skein};
hash[0] = Keccak(Block_Header);
for (i=0;i<N;++i)
{
    hash[i+1]=f[hash[ i ]&3](hash[ i ])
}
final_hash=Keccak(hash[N]);
Идея - в каждой следующей итерации хеш-функция определяется исходя из хэша, полученного на предыдущем этапе; ни порядок, ни то какие функции встретятся для этого блока в ходе расчёта финального кэша предсказать невозможно.
Может и ошибаюсь, но кажется для асиков/фпга именно наличие нескольких алгоритмов и "случайность" их применения могут серьёзно ударить по производительности.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 27, 2013, 09:19:25 PM
Само по себе наличие неск. хеш-функций
просто увеличивает стоимость АСИК.
А вот хаотичность их порядка,
должна создать для его производителей
 большие трудности.
Groestl из них самый тяжелый в железе (был).
К тому же для него доказана и
 стойкость против коллизий и полная случайность и еще чего-то там )

Мне почему-то кажется ( но может я ошибаюсь ) что более случайные функции
 (SHA-3 финалисты) могут снизить вариацию в майнинге.
Ну я на это (у АСИКов) и расчитывал. Стоимость проектирования - раз, стоимость создания - два, энергоэффективность - три. Всё должно ухудшится, по сравнению с биткоиновским алг^2.

Жаль в английском не понимаю, но судя по переведённому и обсуждениям на тему финалистов ша-3 - в последнем раунде криптостойкость уже и не принимали во внимание, на сегодняшний день она у всей этой пятёрки одинаково сверхнадёжная. А победитель выбирался по косвенным параметрам "для практики" - скорость выполнения/потребления памяти, переносимость, "масштабируемость" и т. п. В крайнем случае можно попытаться нарыть финальный документ/статью про отсеивание в sha-3 round2->round3. Наверняка там всех финалистов аргументировано выдвинули.

А что обозначает понятие "вариация в майнинге"?


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 28, 2013, 09:39:53 AM
Только As кажись, а то ZhopaCoin конечно оригинально, но не взлетит точно  ;D


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 28, 2013, 10:38:08 AM
по схеме №4-(2)
Я так понял в числах, для устоявшейся системы, выглядеть будет примерно так?

Целевая "эмиссия", I:
I = PI
эмиссия_в_сутки (множитель), Id:
Id = (1 + PI/100)(1 / 365) // забудем про високосные года  :D

"условная" денежная масса в день-0, M0:
M0 = ??????    // какая-то константа, "виртуальные в квадрате" монеты, которых в системе реально никогда не появится, но с которые эмиссионный алгоритм будет создавать уже реальные монеты.

Денежная масса в i-той итерации (в i-ый день), Mi:
Mi =  M0 * Idi
для компьютерной реализации, удобней через экспоненту:
ln(Mi) = ln(M0) + i*ln(Id) // здесь нат. логарифмы начальной денежной массы и инфляции в день - заранее вычисленные константы
итого
Mi=exp(const1 + i*const2)


Прирост денежной массы в i-ый день, p:
p = Mi * (Id - 1)

награда за блок в i-ый день, br:
br = p / число_блоков_в_сутки


Для злосчастного премайна запуск системы устанавливается в "отрицательной" день, и со своей наградой за блок
И кстати, прикольная вещица выходит. Допустим сделав "реальных" 100к, можно (и скорее всего нужно) агрегат Mo установить в десятки м - в итоге система генерации будет считать, что имеется достаточно "виртуального премайна", генерировать на него % - но как таковых этих "стартовых" коинов в системе никогда не было, и самое главное - они никогда "вдруг из воздуха" и не появятся.


P.S. Вот кстати как полезно с циферками баловаться. Только сейчас, прям как до жирафа дошло - что по сути в биткоине внутренняя инфляция (годовая) ниже 10% опустилась буквально в конце того года, после уполовинивания награды. А опуститься в значении инфляции ниже планки инфляции от Aes, биток сможет только после очередного уполовинивания до 12,5. Так что все предыдущие восторги от "дефляционной валюты" никакого основания под собой не имели; и почувствовать "реальную" нулевую инфляции в битке можно будет только через 4 года. Ну а серьёзно говорить о том, что эмиссия биткоинов меньше роста экономики, похоже можно будет только при награде в 3,125.
 


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 28, 2013, 12:22:24 PM
Если хотите напишите, калькулятор. ???
Цель - подобрать такой ежедневный процент
прироста награды, чтобы в итоге за год
число монет выросло на PI %.
Это посчитать несложно, поэтому я не спешу.

У меня сегодня голова никакая.
Завтра почитаю про PoS.
В стиле NVC и классическую теорию (их 4.5 варианта есть)
вот ЭТИ совместные системы (PoS+PoW) рассчитать
 с созданием целевой инфляции будет
 сложнее намного.



да зачем писать? (тем более я не умею  ::)). это же в уже самых простых калькуляторах есть всё.
Пи(), делим на 100, плюс 1. - годовой процент в виде множителя
извлекаем корень 365-й степени - дневной процент в виде множителя (Id)
(минус 1), умножить на 100 - число в виде процента (реально нигде не нужно кстати в расчетах. на то он и процент, что1+х/100 как множитель используется, х/100 - как доля)
итого:
дневной процент, для пи()% годового,  и без учёта високосных годов = 0,00847502874946021070767384532574%

/*
Id = 1.0000847502874946021070767384533;
Id-1 = 8.4750287494602107076738453257351e-5;
ln(Id) = 8.4746696391883457199911744200889e-5;
*/

...
Будет более выстроенная система начнем англоветку и там нам расскажут,
 почему ничего не будет работать и как надо ... )
Кстати, если включить в случайную цепь хеш-функций "добавить" ГОСТ Р 34.11-2012, можно весь батхерт из WoP/хеширования/майнинга слить именно на неё, и потом под давлением общемировой общественности убрать, оставив остальное как задумал  ;D


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 28, 2013, 02:31:11 PM
Ну, да, для  такой статической схемы
 достаточно высчитать константы,
 а вот для PoS программулька-калькулятор
 пригодится...

 С вас - вывод формул,
 с меня - кодирование симулятора
 на Go. Идет ?

 Осталась фигня - придумать подходящий PoS ;)
 
 ГСЧ там по-моему лишний.
 Там же детерминизм заложеный в хэшфункциях.
 а вывод ГСЧ (хоть XORь его, хоть склеивай)
 даст в рез. случайный результат.
 
 Также схема хеширования, где порядок
 хэш-функций выбирается случайно может
 создать трудности.
 Когда хэш блока будет проверяться потом
 придется перебирать несколько вариантов.

Какая цель изменению вознаграждения в PoS - добиться чтобы независимо от количества участвующих stake-coin'ов за год они создавали +Х% от всего агрегата монет? Или +Z% только от участвующих в транзакциях (этот выбор кажется странновато-спекулятивным)?

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 28, 2013, 06:17:12 PM
например такая цепочка :
 Hash = Skein256(keccak512(Groestl-512(Block_Header)))

Полный детерминизм и нет потерь энтропии.
Но это -только PoW-блоки.

С PoS частью завтра буду разбираться.
Наш PoW дает инфляцию.
А PoS подсистема может оказывать на денежную массу сложное влияние.

И наша задача - все это настроить,
 так чтоб СУММАРНАЯ итоговая "инфляция"
 вышла на PI % в год.

Надеюсь я все объяснил ясно ;)


Инфляция "прилагается" ко всей денежной массе,
так как у нас не Биткойн и его не будут придерживать + нам желательно чтоб все койны обращались...

С инфляцией понятно. Уточняющие вопросы по PoS:
    Зная что у нас нет центра, могут ли рядовые клиенты:
  • узнать суммы сгенерированных в системе PoW и PoS монет за прошедшие сутки;
  • можно ли за PoS блоки назначать динамическую награду;
  • можно ли часть награды, передать в следующий блок;

(ну и для идиота непонимающего основы) как вообще происходит PoS генерация? - ищется самое большая из "одобряющих" days*coins, и эта сущность самолично подписывает блок? Или системой как-то "собираются" days*coins кусочки, пока не наберётся "пул из них" с суммарной наградой в Х coins?
[/list]


Title: Re: TrueCoin <-- правильная монета
Post by: rPman on March 29, 2013, 03:58:09 AM
От сюда (https://bitcointalk.org/index.php?topic=114712.msg1667508#msg1667508) и выше/ниже по теме.

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 29, 2013, 12:20:27 PM
Мысли.
Если % за PoS, равны-больше чем % в общем генерируемой системой, то становится экономически выгодно "хомячить".
Поэтому делать один PoS - это валюта сбережения, тот же NVC вполне эту задачу осуществляет.

Принимая идею rPman'a о невозможности нахождения в цепочке двух PoS-блоков подряд, вырисовывается примерно такая схема:

Награда за PoS "символическая", около 1% годовых. Каждый PoS блок, помимо начисления coin себе, оставляет информацию об остатке (block_reward - coin), переходящих в награду следующему блоку.
Вопрос, что делать с PoS,  у которых своя награда превышает текущий block_reward (в связи с частыми 2х минутными блоками, и соответственно существенным размазыванием суточной эмиссии на мелкие части, такая ситуация в первые месяцы вполне реальна).
Пока в голову пришло 2,5 варианта:
(а) дробить исходные коины, чтобы блок подписало такое количество, что их награда block_reward; остаток продолжает дальше ждать следующих PoS-генераций.
(б) "рисовать" лишние коины, полностью выплачивая награду, превышающую текущий block_reward
(в) полностью выплачивать награду, передавая на дальнейшие PoS-блоки получившуюся недостачу. Поскольку % генерации PoS, меньше чем % у всей системы - эти излишки будут гаситься очень быстро (на практике практически гарантировано уже следующим PoS-блоком).

Про умных людей с теориями - в анонимной криптовалюте очень сложно определить "правильные" транзакции. Упоминаемое там везде VT/V, - это в реальности   деньги-товар, деньги-услуга. А у нас транзакция - это в общем случае просто перевод средств с одного адреса на другой. Если заставить одного человека (домохозяйство) иметь в системе лишь один адрес - то тогда без сомненья, все транзакции можно считать правильными. Но это будет как минимум не анонимная валюта, с наличием центров "идентификации" при регистрации.
Таким образом транзакции в анонимной валюте - показывают только возможный потолок от экономических транзакций. А вот их доля - никакому расчёту не поддаётся, их может быть и 1%, и 99% от потолка.



Ukigo, как вам такая схема премайна:
выписываете в 0 блоке генерацию скажем 100к на свой адрес "основателя".
Заранее в интернациональной теме определяются правила раздачи премайна с этого адреса - к примеру, первая тысяча пользователей, оставивших запрос в этой теме получает по 100 монет. Условия получения - регистрация на форуме до даты запуска проекта + наличие N сообщений (допущения: 100 монет - награда примерно за 10 блоков на старте; число выплат 1000 - сколько не лень будет мониторить ту тему лично и заниматься выплатами. Естественно этим должен заниматься будет сам основатель или очень доверенное лицо - даже единственный левый перевод или невыплата по правильному запросу может подорвать доверие к стартапу полностью).
Если на этом адресе останутся средства к моменту начала генерации PoS-блоков, а они сгенерируют %%, плюс любые переводы/donate на этот адрес - то уже эти вторичные средства полностью поступают в "собственность" основателя.
Если не рассматривать проект как скам/пирамиду, а считать сёрьёзной валютой с долгосрочным вложением - то даже майн на целероне первые месяцы существования Aes можно будет получить гораздо больше, чем от бешенного личного премайна в мертворожденном форке.



P.S. где бы про методики расчета годовой/месячной инфляции для фиата почитать? Хочу заранее агит-график нарисовать, для тех кто будет кричать что рост денежной массы - это априори вселенское зло. Пусть глазами увидят, как зверски этот М-агрегат рос и будет расти первые 8-12 лет существования в биткоине  ;D


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on March 29, 2013, 04:48:25 PM
PoS без PoW запустить можно и оно будет работать, будет безопасным в плане даблспенда, но есть проблема. А именно, чистую PoS-систему можно задосить генерацией очень большого количества инвалидных блоков (потому что проверка PoS блоков более ресурсоемка, что и создает плечо атаки). Это ничего не даст финансово, но парализует систему. И пока неясно, как решить эту проблему. Кстати, это является одной из причин, почему PPC/NVC являются гибридами.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 29, 2013, 06:24:55 PM
Написал англоветку насчет правильной теории
 денег - пока там не совсем та обратная связь коей хотелось бы...
https://bitcointalk.org/index.php?topic=160636.0
Подождем...

1) Будет симулятор - посчитаем проценты
 в разных вариантах. Для этого он и нужен.

2) А зачем оставлять остаток ? В чем его назначение ?
Я как суперминималист всегда выступаю
 за самые простые решения )
Оно само потом усложняется в процессе
 развития )

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

3) Не, один адрес на человека/семью
 - это не комильфотно.
  Пока все транзы считаются полезными.
  И просто увеличиваем денежную массу.
Но я еще покопаюсь в этих теориях
 немного , вдруг чего нарою...
 

(1-2). Затем и остаток, чтобы не высчитывать сложные процентные зависимости. А с ним мы гарантируем, что за сутки транзакции эмитируют в систему нужный % от всей суммы монет системы, невзирая на количество PoS-Pow блоков и число монет участвующих в PoS.

(3) Повторю имхо. V = total_summ_transaction * rand(); как обладая таким V вычислять не умозрительную, а практическую эмиссию - непонятно.

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

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

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

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

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

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

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

(4) Ассоциации, они разные бывают. у меня например AES - это http://www.aes-group.kz/ (http://www.aes-group.kz/)  ;D

(5) Думал обширная раздача премайна - это для PR.


PoS без PoW запустить можно и оно будет работать, будет безопасным в плане даблспенда, но есть проблема. А именно, чистую PoS-систему можно задосить генерацией очень большого количества инвалидных блоков (потому что проверка PoS блоков более ресурсоемка, что и создает плечо атаки). Это ничего не даст финансово, но парализует систему. И пока неясно, как решить эту проблему. Кстати, это является одной из причин, почему PPC/NVC являются гибридами.
PoS ведь - не инфляционная модель валюты?
Логика для "живой" валюты и некризисной экомномики такова. Есть рост экономики х%, есть эмиссия у%. Разность y% - x% - это инфляция валюты. Но, если вся эмиссия это только PoS-генерация, то хранить инфляционную валюту становится выгодно. Деньги в обороте - они обесценились на (у-х)%. А деньги лежащие в кубышке - наоборот подросли. На размер эмиссии, которая больше инфляции.
Поэтому и желательно, чтобы при общей эмиссии y%, PoS эмитировал меньше, и даже желательно меньше х% чтобы инфляция на них действовала.

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



Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on March 29, 2013, 06:27:51 PM
PoS сам по себе к модели никакого отношения не имеет. Это просто способ подтверждения транзакций, а награда там может быть хоть нулем. Можно сделать инфляционную PoS-валюту, если найти способ простимулировать юзеров сливать накопленные монеты, а не удерживать их для увеличения награды.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 29, 2013, 06:37:07 PM
Про вырожденный случай писал, когда система только на PoS строиться. Или для такого случая уже придумали эмиссию не через PoS-блоки?
(извиняюсь за возможно тупые вопросы и высказывания, просто в плане знаний всех внутренностей со старожилами конечно не потягаешься; да к тому же как понимаю куча ключевых обсуждений новинок/альтернатив только на инглише и происходит)


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on March 29, 2013, 06:42:35 PM
Гибридный дизайн в первую очередь из соображений стабильности. Чистый PoS это хорошо в теории, но на практике гибрид лучше как чистого PoS так и чистого PoW. Хотя, косвенно PoW эмиссия действительно уменьшает вероятность бесконтрольного накопления средств стейкхолдерами, т.к. влияет на них психологически.


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on March 29, 2013, 07:38:59 PM
@Balthazar
Говоря про чистый PoS я имел в виду систему
 отличную от NVC/PPC, которую еще не изобрели.
Это неважно, о какой именно системе речь. Это аксиома, PoS-блоки сложнее проверять, чем PoW, и практически невозможно сделать иначе (если только PoW не утяжелен чрезмерно громоздкой хэш-функцией). Потому что инвалидные PoW блоки отсекаются простой проверкой хэша первых 80 байт на соответствие таргету, все остальные проверки опускаются после этого. Для PoS блоков же при проверке необходимо помимо заголовка залезть в транзакции, подгрузить и проверить их зависимости и т.д.


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on March 29, 2013, 08:10:45 PM
Не понял, причем тут дробление монет. ::)

Если о реализации в ppc/nvc, то оно не только дробить умеет, но и клеить. А дробить нужно чтобы увеличить количество вариантов для перебора в будущем. Чем больше вариантов, тем устойчивее система, потому что злоумышленнику сстановится еще сложнее предсказать ее состояние в будущем (хотя его и так предсказать невозможно практически, но лучше быть параноиком).


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on March 29, 2013, 08:20:26 PM
33 байта - это достойная плата за дополнительный фактор рандомизации.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 29, 2013, 08:45:08 PM
Вот кстати дьявольский план - если утвердить "перенос" недоэмитированных монет в PoS-блоке в последующий PoW, и есть у всех есть возможность (и почему-то я на 99% уверен что она есть) проверить были ли на начало генерации этого блога ожидающие транзакции, то признавать валидным только такой блок, который эти транзакции (хотя бы определённый минимум из штку/kb) включил в обработку.


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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 31, 2013, 08:47:56 AM
Ремарка небольшая - нужно прекратить всё называть инфляцией, и начать называть эмиссию в системе эмиссией  :D

А когда симулятор будет готов? И будет ли он доступен не только в виде source-под-*nix ?


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 31, 2013, 12:00:12 PM
Вот идейка насчёт транзакций: считать "полезными" такие транзакции, % комиссии в которых больше, чем % эмиссии за один день (например для обсуждавшейся парой страниц ранее константной эмиссии в ПИ%, такая комиссия на 1'000'000 монет будет чуть меньше 85, что составляет 0,0085%).
В целом никто комиссию платить не заставляет, но если это "бизнес"-транзакция, то проще будет выставить комиссию в 0,01% для обработки платежа за десяток-второй минут, а не экономить гроши, теряя возможные часы на подтверждение (в том же биткоине уже сейчас безкомиссионые транзакции бывает "подвисают" с включением в обработку, думаю для реальной валюты расчётов и оборота, а не сбережений, текущее число транзакций в системе биткоина будет казаться смешным).


Ещё одно. Если процент эмиссии будет "плавающим" - проще где-то в блоках хранить всю сумму эмитированных монет.
Если "реальные транзакции" где-то будут учитывать - за нужный период тоже проще хранить скорость/объём денежного оборота.
Это конечно размеры нефункциональных частей блока увеличит - зато избавит от необходимости лопатить последние ХХХ блоков (а то и все) блоки, для простых расчетов текущей эмиссии (aka block rewards).


P.S. технических препятствий, по перечислению комиссий автору PoS блока не должно же возникнуть?


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 31, 2013, 02:29:01 PM
Ну да, в переведённом примере и должно быть так  :D

Как я понял эта формула из NVC? Так там награда за блок высчитывается как абсолютная величина. сложность в степени (1/6).

А Вы считаете той же формулой, но берёте не как число_монет, а как размер процента.

ну и понятно, что +20, и +20% - это очень разный результат.


-----------------------------------------------------------------------------------
в общем:
эмиссия в биткоине - это уменьшающаяся функция (скачкообразно) от времени системы;
PoW-эмиссия в NVC - это функция (непрерывная) от сложности системы;
PoS-эмиссия в NVC - это % от коин-годов генерирующих блок.


P.S. че то c Go у меня не выходит.
localhost:6060 в браузере-то окрывается, а вот потом после нажатия на Run, даже в семплах окно вывода сообщает только это:
This functionality is not available via local godoc.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 31, 2013, 03:41:18 PM
wReward - это награда за 1 PoW блок у меня.
КАлька с Той формулы, именно в монетах должно получаться а не процентах ???.

C++ клиент НЕ считает через трудность как я
 они берут таргет, а трудность потом высчитывается
 в другом месте в безумной функции кою я не понимаю,
 как перевести на Go.
ПОртировать с языка на язык трудно всегда.
Но польза от симулятора есть - он считает годы работы
 за минуты, а тестнет нельзя запучтить быстрее
 чем блок раз в 30 сек.

Я вот думаю , что можно ваще не ловить эту формулу.
главное смоделировать изменение награды похожим
 на данные реального NVC ( мы ведь не собираемся
 менять эту их функцию wReward).
А хотим просто прибавлять к ней наш скромный процент
 (как вы думаете: делать это в каждом блоке или реже ?)

Еще сначала PoS-блоков нет, потом их число растет
 до 50/50 и позже PoW почти сходит на нет,
как это учесть по какой функции прибавлять % к
 PoS и по какой к PoW-блокам ?
Ненужна нам их PoW-формула. Ни btc, ни nvc.
Представьте награду за PoW-блок так:
сама_награда = 0; // просто 0 и всё.
эмиссия = %(от всего агрегата монет системы)
комиссия = сумма_комиссий_с_транзакций_блока
итоговая_награда = сама_награда + эмиссия + комиссия;

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

 % эмиссии в блоке - это
// Percent_year_digit - Это константа либо вычисленная величина в формате 9%, 5%, 3,14% и т.п.
a = pow (1 + Percent_year_digit/100, float64(1.0/365.0) ) //это дневной процент в формате "множителя"
b = (a-1)/720.0 // это процент за блок, в формате "доли"
block_emission = M * b;

// иттого
wReward = 0 + block_emission + commission;


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 31, 2013, 04:33:21 PM
Для симулятора наверно проще считать год как 720*365 = 262800 итераций/блоков?

А с числами может где я протупил - или блок за 10 минут посчитал, или считал для недель а потом с днями перепутал и т.п.

На код можно будет глянуть потом? Пока простые обкатки идут, вроде должен суметь "прочесть".


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 31, 2013, 06:09:16 PM
Сложные проценты и должны в абсолютном значении эмиссию разгонять.

И удвоение за ~25 лет - вполне нормально.
Биг мак за пол века подорожал в ~10 раз - а о постоянно безумной инфляции в США как-то не кричали всё это время  :D


p.s. rand.NewSource(7556) - чего делает? обычный rand() си-шный, но в диапазоне 0-7556?


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 31, 2013, 06:47:03 PM
Вроде бы всё то же самое

изменил строки
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


PoW bounty:  1.2522628786536848e-07
----------------------------------------------------------
moneysupply:  1.0638667494366378  at block # 525961
==========================================================

у moneysupply на одну тысячную разница. наверно из-за 365 дней в проценте.

1.81647227375:1.760293788 = 1,03191. Процент на 0,05 отличается от задуманного. может тоже из-за расхождений по високосным/обычным годам?

В общем,
Симулятор слабо-инфляционной валюты, со стабильным % эмиссии готов. Теперь осталось приспособить формулы из какой-нибудь "true money theory" для динамического изменения годового процента, и математическая база готова  ;D

если изменить на /365.25, и прогнать опять до 18 и 19 - по идее должно выйти 1.0314159, плюс-минус ошибки округления :)


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 31, 2013, 06:57:13 PM
ещё вариант - погрешность может накапливается, из-за того процент на блок вычисляется /720, а не извлечением корня 720-й степени из (1+day/100), но имхо с такой точностью уже подгонять - это маразм  :P


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on March 31, 2013, 07:58:30 PM
Пока я вижу только такие сущности, независимо наблюдаемые системой (часть из них может и отсутствовать, определяется при проектировании):

блок - квант времени

М - общая денежная масса (где М0 - виртуальные монеты, нужные для эмиссионого алгоритма, (M + М0) - те самые supply из симулятора)

I% - текущий [рассчитываемый] процент эмиссии. Вычисляемый от него block_reward отходит майнерам (с точки зрения индивидумам - обогащение), с точки зрения системы просто обезличенная эмиссия каждый квант времени. Увеличение % эмиссии вызывает повышение инфляции, в "умеренных дозах" подогревая экономическую активность. Увеличение денежной массы, медленней чем рост связанной с ней (этими деньгами) реальной экономики - порождает замедление роста, но повышает защиту от пузырей и прочих перекосов и т.д.

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

Vп - "бизнес"-транзакции с комиссией (минимум ~0,0..zz% от суммы транзакции) (практически "подтверждённая" деловая активность системы)

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

PoS%, % награды при PoS-генерации - величина стимулирующая "сбережения" и "накопления", при значении близком к I%, может вызывать стремление свернуть активность (транзакции) в пользу накоплений путём генерации PoS-процентов (но при добавлении несложного кода, на величину эмиссии никак не влияет)
Также PoS% по сути определяет минимальную границу стоимости кредита в системе (Таким образом понятие бесроцентный кредит - это кредит в 2*t% разовых + PoS% годовых).

из всего вышеперечисленного - косвенно можно вычислять объёмы "активных" монет (задействованных в транзакции + PoS), и объёмы "анабиозных/мёртвых" (оставшиеся, нигде не задействованные)

Итого, наблюдая на текущем блоке k (и для предшествующих блоков) параметры М, V, Vп, также вычисляя объёмы активных денег (транзакционных), денег на сбережении (PoS), и денег в анабиозе /мёртвых система по заранее заложенным правилам может изменять I%, PoS%, t/t%.



Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 01, 2013, 01:32:28 PM
Да не натуральный это метод подсчёта. Если за 20 лет объём в 22 раза увеличился  :o

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

И откуда взялась их идея эмисии в PoW-блоках, в зависимости от сложности системы (как аналог - придумали деньги в городке, рисовали в год по 10000 новых; потом расширили сферу влияния на область - стали рисовать по 1000, потом придумали клише для печатанья - стали выпускать по 100, стране понравились эти деньги - расширились ещё раз, стали выпускать на всю страну в год по 10 новых). Смысл экономический этого каков?
Как я понимаю с точки зрения их методологии: PoW-генерация, это просто распределённый по пользователям и во времени преймайн. Как только система вырастает из детских штанишек - PoW-генерация становится мизерной, и равновесный приход/расход денег в системе начинают обеспечивать PoS|шредер в транзакциях.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 01, 2013, 03:02:50 PM
Только чистый PoS - это форк сбережений;

Что же касается срока жизни в 10 лет, так за 10 лет даже биткоин вполне себе инфляционная валюта (https://bitcointalk.org/index.php?topic=130619.0). Там правда с моей точки зрения странный метод "мгновенной" инфляции который вызывает скачки, но это из как 10ку считать 7+3 или 6+4.  На том графике хорошо видно, что в биткоине сейчас ещё эмиссия больше 10% в год. И это ко всей массе, включая мёртвые/отправленнные в никуда и т.п. монеты.

Я максималист, на четверть века рассчитывал  ;D


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 01, 2013, 03:57:46 PM
да моя идея проста. из вашего первого поста. Стабильно низко-инфляционная валюта
на 20й год - денежная масса больше на Х% чем на 19-й.
на 120й год - денежная масса больше на Х% чем в 119-й  ;D

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

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

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

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


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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 01, 2013, 06:46:25 PM
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 без практической пользы в применении)




Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 02, 2013, 03:24:23 AM
Эх, ещё одна идейка, в порядке бреда:

Награда за блок - положительная обратная связь со сложностью генерации этого блока, как пример:
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.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 02, 2013, 01:19:35 PM
В логарифме - отношение сложностей.
wDiff_base - это заданная начальная сложность. Наверняка она же есть в каком-то значении типа 0x00ffffff...f
и высчитывается ln не от самого числа текущей сложности (мощности), а от того, во всколько раз она меньше чем базовая
и в "отрицательную" зону она кажись зайти не может - даже если система "умерла", и мощность стремится к 0 (в сети один майнер на PIV), сложность до 0хffff... не поднимется, застынет на 0х00ffff.... с генерацией блока раз в 3 часа  :P


тот же пример про 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(8) = 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, которые долго искать и гораздо быстрее проверять.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 02, 2013, 02:04:22 PM
да точно Target - это то про что я и говорил.

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


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

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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 02, 2013, 06:19:56 PM
С процентами ничего не поделаешь. Тут 2 варианта:

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

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


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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 02, 2013, 08:01:52 PM
Вы про ту кривую, что у них в wReward присутствует math.Pow(wDiff, float64(0.16666666666666666))?

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


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


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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 03, 2013, 06:27:48 AM
Ну тогда второй вариант из примера?
награда_блока_за_сложность = 10 + log10(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-м блоке прописать какую угодно генерацию на какой нужно адрес, запечатать его в том числе и в коде (чек-поинты же делаются итак) - и уже все остальные будут подтверждать эту транзакцию премайна.


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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 03, 2013, 05:18:33 PM
Премайн в 2млн? это RIP на старте, без вариантов  :-\

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

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

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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 03, 2013, 06:01:03 PM
не нравится мне премайн, тем более огромный такой. но уж если его планировать, то
supply = 2000000.0 и смотреть на все объёмы проценты уже с ним

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


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on April 03, 2013, 06:37:24 PM
Чем больше зверствовать, тем большую централизацию ты создашь. Потому что для сложного алгоритма GPU-майнер будет приватным долгое время, как это было в случае LTC. В итоге это приведет к концентрации мощности и эмиссии в руках ограниченного круга лиц.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 03, 2013, 06:47:39 PM
Может тогда к авторам алгоритмов обратиться? Как вы считаете, каковы перспективы переноса на openCL и т.п.? Или сразу в лоб "каковы по вашему мнению параметны, обеспечивающие наименьшую производительность на GPU)

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 03, 2013, 07:12:05 PM
Ukigo, как до жирафа только сейчас дошло.
В последней версии симулятора где-то логическая ошибка.
После того как PoW вырубается, и остаётся один PoS, инфляция вообще не может превышать 1% никоим образом. а она почти 3%.

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




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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 04, 2013, 03:00:48 PM

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

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

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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 04, 2013, 04:16:42 PM
Итак:

в начале каждого цикла 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, значит это ерунда  :P


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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 04, 2013, 05:30:50 PM
с coinAge сложнее. как я понял, это количество_монет*их_возраст (эдакий вариант человеко-часов).
И если с возрастом понятно - это всегда от Х1 до Х2 блоков {дней/часов}
А среднее количество монет прямо пропорционально их объёму вообще. (предложил бытак: среднее число монет в PoS-блоке = supply/2 * (1 / число_блоков_за_60_дней)
Но это глюк симуляторный-то. У нас там либо PoS-монеты в 5 раз быстрее прокручиваются, из-за соотвественно большей скорости блоков, либо заморозка не "простимулирована", и одна сумма может месячную награду хоть 5 раз подряд за 10 минут получить.
Повторюсь, сейчас PoS-часть симулятора - это как банковский вклад с 1% награды, но по факту каждый год на 4% сумма возрастает  :P


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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 04, 2013, 06:40:54 PM
У нас же PoS и PoW по очереди работают... Зачем инфляцию в PoW снижать?
Вернее так: награда за PoW - это и есть расчётная целевая инфляция. Когда проходит PoS-блок, он эту награду фактически отменяет, заменяя своей 1%. Так что в реальности как бы поднимать % не пришлось :D

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 05, 2013, 05:29:50 PM
512 бит - это же не страшно. В конце концов, даже если формат блоков и их заголовков оставить полностью совместимым, можно будет старшие{младшие} 256 бит результата от хешей брать и всё.
Маразмом то это выглядит только если единичный расчёт хеша происходит, и нужна скорость. А у нас, в криптовалютах результаты вычисления всё равно миллиардами откидывают.

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


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


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on April 05, 2013, 06:43:41 PM
Groestl реализован на куче языков и есть даже асики. Я думал его использовать, но отказался от этой идеи во избежание централизации эмиссии обладателями приватных майнеров.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 05, 2013, 08:30:56 PM
Она должна стабильно работать при ЛЮБОМ
 соотн. от скажем 28:2 до 2:28 или типа того ;)
не, в краткосрочном периоде она конечно плавать может, но для длительных промежутков нужно соотношение, к которому система будет динамически сложность PoS подгонять.
Иначе будет 100% доминации одного типа.
Простой пример. PoS-мощность пропорциональна всей денежной массе M. PoW-мощность равна сумме мощностей майнеров. Даже навскидку будет 3 периода:
1) старт первый(е) месяйы - экспотенциальный рост pow-мощностей. PoS-мощность практически нулевая из-за отсутсвия в природе достаточных сумм монет как таковых
2) первый год, стабилизация PoW, но денежная масса растёт очень быстро в арифметической прогресии (начальный майнинг буквально месяцы назад её было 0, и каждый месяц + Мм, инфляция пока бешенная). PoW-мощность практически неизменна, PoS-мощность растёт ровно с ростом денежной массы М.
3) окончание роста, инфляция постепенно падает на ~ +Пи%, PoW-мощность удваивается каждый год. (Итог - удвоение мощности-PoW, практически стабильная мощность-PoS)
То есть нужно эти мощности между собой как-то калибровать, и калибровка эта должна постоянно меняться, стремясь соотношение PoW:PoW-блоков привести к заранее прописанной константе.

Итого, навскидку, будут конструкции вида:
Смотрим период формирования последних блоков за неделю. Время5040. Корректируем текущую цель для PoW. target_pow  *= 168_часов / время5040
Дополнительно можно учитывать поправку, насколько фактическое число блоков с самого старта системы отличается от расчетного
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-реализации, это необходимое и достаточное условие существования.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 06, 2013, 10:36:28 AM
попробую вечерком симулятор для го сбацать:

пока идеи такие
первые 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 элементов?


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 06, 2013, 04:25:02 PM
А как компилятор - настроен на максимальную скорость?

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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 07, 2013, 09:46:44 AM
У меня со симулятором какой-то  полнейший затык. А как "по стандарту" сейчас везде сложность пересчитывают? По фиксированным N блокам, или по фиксированному T "реального" времени?

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 07, 2013, 11:09:23 AM
http://pastebin.com/REZUfBQ1

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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 07, 2013, 12:30:13 PM
second - для последних 5040 блоков - время в секундах от "старта" системы до появления этого блока (в идеале для последнего блока = №блока*120)
delta_time - количество секунд между последними 5040 блоками (ну т.е. в идеале это должно быть близко к 120 * 5040 = 604800

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



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

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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 07, 2013, 09:24:27 PM
Не пойму как выразить bnProofOfWorkLimit
 в виде Python's BigNum ?
И что такое bnInitialHashTarget ?

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

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




Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 08, 2013, 09:51:31 PM
a зачем root(а,n); чем math.Pow(а,1/n) плох?

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 10, 2013, 02:48:17 AM
По-моему с майнингом другая проблема более чем реальна - как только криптовалюта выходит за круг гиков/анархистов и т.п. и внедряется в массы; то если правительства/элиты/корпорации вдруг не "убивают" её (валюту) целиком, то уж майнинг/сбор_комиссий своими мощностями полностью под контроль могут забрать. Как раз для извлечения доходов.
Тем более в инфляционной валюте. Представить, что владеешь 30% мощностей генерации True, которая обеспечивает хорошую часть мировых платежей - это же получение буквально "нахаляву" 1% от мирового оборота финансов. В дефляционных-то наоборот, когда эмиссия по-факту кончится (если при этом валюта не умирает), все сбереженцы будут беречь своё добро. Мало транзакций -> мало комиссии -> PoW-майнинг уныл.

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

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


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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 10, 2013, 09:14:54 AM
Хочу добится, чтобы в итоге true в том числе и под visual studio "портирован был" так сказать. Плюс, да простят мну поклонники Only-crossplatform-GNU, но такое ощущение, что bitcoin-qt написан на java, такой в нём запуск тормознутый и появление окна из трея; если для новой валюты под винду удастся сделать "почти дефолтный" нетормозной кошель - это возможно для успеха будет не менее важно всех хороших идей, вложенных в создание.
Но с текущим вниканием в ппц/бит, наверно действительно будет проще пока mingw поставить.


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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 10, 2013, 03:07:26 PM
С майнингом тогда можно сделать так. каждые ~500'000 блоков, PoS-генераторы, голосуют за варианты по добавлению/замене хеш-алгоритмов в цепочке вычисления PoW-блоков. Но это слабая страховка вообще-то. Как я понял, в том же битке, как при появлении fpga, так и при слухах о запуске проектирования/начале поставок асиков, никто не мешал текущей команде разработчиков объявить что с блока Х/даты Ч вычисление переходит на другое - пример ша2(ша3(...)). Но никто не захотел/или им не позволили такой поворот осуществить. С точки зрения хард-форка, это ничем не отличается от допустимых блоков в 0.7/0.8 версиях - старые кошели никак не смогут работать с новыми условиями существования цепочки блоков и точка.

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 11, 2013, 11:48:09 AM
Собиратель программы из исходников в моём исполнении прям по пословице "заставь дурака богу молиться, он весь лоб расшибёт"

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

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




Title: Re: TrueCoin <-- правильная монета
Post by: awoland on April 11, 2013, 12:38:21 PM
...
Лично мну НЕ поклонник Linux ,
просто Lin - это мейнстрим в мире бесплатных
 ...
А так есть более продвинутые *nix системы
( но они не популярны) :
Inferno
Minix3
DargonFlyBSD
...

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 11, 2013, 12:56:34 PM
В продолжение холивара: имхо, опыт xUSSR 90х-00х годов, со всей очевидностью показал что при нулевой стоимости софта/отсутствии саппорта по нему же, в домашних компах и малом бизнесе невозможно существование ничего кроме винды - и очевидно из-за доступности и качества продуктов для рядового потребителя. Так что, если бы не жадность мелкомягких в ценах на свои продукты, они давно бы могли стать всеохватывающими мировыми монополистами.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 11, 2013, 11:59:03 PM

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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 12, 2013, 03:53:30 AM
...

А может они обиделись на "щупальце" ???


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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 12, 2013, 04:32:21 AM
А если серьёзно - пока ведь трудно определить, какая конфигурация будет нужна именно для фарма.

amd vs intel; ядра vs потоки/гипертрейдинг; экономическая эффективность разгоняемых K/black; размер/частота ОЗУ.
Хотя может всё это на первых порах это и не важно будет? Приживётся валюта, будет поначалу, отчасти как с биткоином - нецелевое использование процессорного времени админами, ради баловства  :P


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 13, 2013, 11:47:33 AM


Нет уж мы пойдем простым путем !
Есть план.
Сначала будет сделан псевдофорк PoW-only.
с нашей цепочкой , изм. трудности по типу PPC/NVC
 и увеличением награды на 2-3% в год.
+ еще пару идей инкорпорируем.
Если будет интерес, тогда посмотрим что
еще туда добавить можно.

PoS идеологически убирается? Появилась безумная идея на будущее по PoS'aм. Поскольку даже увеличение числа PoS-блоков на порядки, на генерацию монет не повлияет практически (самые большие суммы денег обработаются в PoS даже если pos-блок раз в час поялятся будет), PoS-ами можно будет затыкать увеличение объёмов транзацкий.
Другими словами - PoW-блоки всегда появляются скажем раз в 2 минуты, калибруется сложность под это и всё такое.
PoS-блоки появляются "вклиниваясь в цепочку PoW'ов". Так вот pos появляются при накоплении определённого числа необработанных транзакций, тем самым защищая систему от возможной блокировки кровообращения в результате популярности и взрывного роста количества транзакций.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 19, 2013, 05:57:59 PM
Интересная мысль насчёт форков  ;D
Но если у форков-денег, естественный отбор вполне возможен..
То у биткоина и форков-"средств накопления" многообразие скорее к разочарованию и разрушению приведёт.

p.s. а с будущим это конечно лучше в политику, но у Казахстана скорее всего после НАН'a ппц настанет. Жузы/роды ("кумовство") вылезут во всём неприглядстве и всю цивилизацию перемелют в пыль. Я в этом плане даже Сингапуру и прочим азиатским тиграм не верю (в виде эталонов/примеров), как только ускорение извне закончится, имхо тут же внутрь окуклятся и откатятся назад в застой/средневековые традиции.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 21, 2013, 06:02:40 PM
А есть образцы таких алгоритмов хоть? Что там за see the book of Burgin?


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 22, 2013, 08:58:21 AM
Это оно :
https://en.wikipedia.org/wiki/Special:BookSources/0387955690
45 GBP за электронную версию,
и от 25 GBP за поюзаный бумажный книг...
Может где-то есть и бесплатный текст ?!
Конечно есть
http://gen.lib.rus.ec/book/index.php?md5=ca2d7b0f375ca494fdd201500d1977e5

Я думаю пора объявить конкурс на
 лучшее название для TrueCoin.

Помимо отстутвия в названии cash , money, coin... ,
какие еще условия конкурса поставить, как думаете ?
Отсутвие byte, bit, и т.п.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 22, 2013, 08:35:35 PM
С начальной гипер-инфляцией на ум пока два варианта приходит:
а) первые 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(8)->A3 заменяется на генерация(8)->A3, ну и естественно все такие атомарные транзакции на один адрес суммируются и в итоге остается лишь одна транзакция на каждый задействованный адрес) , и этот новый блок соотвественно становится стартовым для системы. Все транзакции созданные после 100'000 блока, и ссылающего на блок с меньшим номером - при проверках входов перенаправляются на новый стартовый №.
Цепь достигает №300'000 - повторяется всё то же с блоком №200'000 с вырезанием диапазона 100'000-200'000, и т.д.
От потеряных кошельков это не спасёт разумеется - эти транзакции на зависнувшие адреса так и будут кочевать с супер-блока в супер-блок, увеличивая размер БД, но хотя бы на заголовках экономия будет всегда.
Ну и конечно никто не мешает для безопасности, да и просто параноикам иметь некие server-edition программы кошельков, которые будут всю первозданную цепочку блоков хранить и использовать.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 23, 2013, 01:57:32 PM
Еще момент помните вашу формулу :
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. В международной теме каждый второй пост вида премайн -> скам? Печально что саму систему инфляции и платежей не обсуждают :(


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 23, 2013, 05:17:17 PM
100'000 за блок, при сложности 10^9... это эксахэши Eh/s когда пойдут где-то?

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

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

http://s019.radikal.ru/i644/1304/9d/a5c0af402fcd.png
(по х миллионы сложности, по у - награда... видно что логарифм стартует как ракета, затем чуть ли не горизонтален, а корень увеличивает награду более плавно)

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


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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 24, 2013, 08:12:46 AM
Я правильно понимаю, эти итоговые 5% получаются так сказать "суммированием" собственно инфляции, и доп. эмиссии от сложности?

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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 24, 2013, 01:00:51 PM
Я все еще верю что и на GPU BMW
 оч плохо ускоряется. Это кстати можно проверить - в той бумаге (ссылку я давал)
 есть готовые проги на CUDA для BMW
 у кого есть такая видяха - может проверить
 и сравнить c CPU- что быстрее и насколько.
на OpenCL BMW реализации я не нашел.

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 24, 2013, 06:11:33 PM
Да уж. получить 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 включится для стабильности/эффективности системы, а не для начала фазы "а теперь все копят монеты".


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 25, 2013, 02:07:43 PM
Стремясь очень быстро обуздать инфляцию, можно к несчастью обнаружить что желания сбываются  :P
Догадайтесь, какая "инфляционная" формула награды даёт такой +% эмиссии по годам?
12500,00%
2100,00%
350,00%
433,31%
512,51%
611,12%
710,01%
89,13%
94,17%
104,00%
113,85%
123,67%



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


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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 25, 2013, 06:17:05 PM
Ага,  а нам надо чтобы награда зависела
 от времени ( номер блока) и от трудности
 (ваша идея).

 или быстрое получение  невысокой инфляции
 плавно падающей от 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 монеты... К итоговой награде надо константу десяточку хотя бы накидывать, а то не пойдёт народ копейку в час майнить  :o (Хотя если убрать премайн, и выкупать монетки по 1$ за десяток...  3$ за двое суток майна всей системы  8))


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 25, 2013, 10:02:54 PM
Я уже прикинул в симуляторе. На поздних годах х*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 раза больше монет создалось.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 26, 2013, 07:13:27 PM
Может не обращать внимание на процент 2-го года? В принципе он так гуляет только из-за того, что сильно может разнится майнинг в год первый. Может это и правильно? Майнило целый год лишь дясяток cpu - получи мизерную базу денежную и как следствие огромную инфляцию на следующий год, при реальной раскрутки валюты. Если валюта стартанула как ракета, сразу распространившись, было выпущено большое число монет в первый же год - да, возможно на второй год инфляция упадёт даже до двузначной, ну так видимо это будет инфляция уже работающих платежей/торговли.
Вдобавок, такой майнинг лишь силами нескольких одиночек  вхолостую, почти гарантировано избавляет от "призрака Сатоши" - десятков процентов первоначально намайненых монет, непонятно каким образом зависших, и самое печальное возможно всё-таки хранимых, и лишь у нескольких индивидов.

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


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


Title: Re: TrueCoin <-- правильная монета
Post by: mech on April 26, 2013, 07:16:16 PM
Тема интересная, где можно получить клиент?


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 26, 2013, 09:27:49 PM
Тема интересная, где можно получить клиент?
Пока только концепт вырабатываем. С кодом работает только Ukigo; остальные иногда советы дают, я постоянно языком чешу, ибо балда  :P (Но надо понимать, что такая ситуация вовсе не означает безнадёжности реализации. По сути для старта переписать нужно будет самую малость - только функции майнинга на cpu, и определения награды за майнинг в системе; о них все дебаты в основном и идут)


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 27, 2013, 11:30:50 AM
Может "смухлевать"?  :P
В первые годы добавить ещё одну функцию к награде.
образец идеи:
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 лет.

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


Title: Re: TrueCoin <-- правильная монета
Post by: RoadTrain on April 28, 2013, 03:11:43 PM
Можно в двух словах, как награда PoS рассчитывается у вас?


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 30, 2013, 04:41:34 PM
...
Чет я засомневался : достаточно ли просто вычитать PoS% из poW% , или тут более сложная
 зависимость ? <-- чтобы вычислить %% реальной
(целевой) инфляции" ?
Ну здесь "идеальная" формула проста сама по себе... [%эмиссии_PoW*(число_PoW_блоков)+%эмиссии_PoS*(число_PoS_блоков)]/(общее_число_блоков)=%итоговой_эмиссии.
Но тут главнее не переборщить с зажиманием. Вон японцы 20 лет экономили, а счас рубанули сплеча - для роста экономики в ближайшую пятилетку удвоим денежную массу и точка  8)

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on April 30, 2013, 06:24:56 PM


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

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

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

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

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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on May 01, 2013, 10:18:57 AM
Совместимость 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;
};
ему надо отрывать руки, а потом яйца.... или наоборот  >:(


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on May 02, 2013, 07:37:55 AM
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. Вырастала не только суммарная награда в системе, но и награда каждому майнеру.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on May 02, 2013, 08:31:31 AM
Да проверок и не надо, вместо 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-ядер, и т.д.

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on June 02, 2013, 04:16:21 PM
Ну как экс-трушечки поживают, надежда на воплощение ещё осталась?


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on June 02, 2013, 08:59:58 PM
А кто сказал, что PoS непременно обязан быть чистым? Гибридного вполне хватит, если создать надлежащие условия.


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on June 04, 2013, 09:21:21 AM
А 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 защиты от дабл-спенд атак?


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on June 04, 2013, 10:03:43 AM
Добавит, но привязка к номерам, равно как и неполноценность блоков не имеют смысла. Подобное ограничение только добавит проблем и ухудшит масштабируемость, плюс теряется энергоэффективность.

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on June 04, 2013, 01:12:13 PM
Добавит, но привязка к номерам, равно как и неполноценность блоков не имеют смысла. Подобное ограничение только добавит проблем и ухудшит масштабируемость, плюс теряется энергоэффективность.

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

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

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


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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on June 08, 2013, 05:14:23 PM
Ukigo, а вы ничего не слышали, а каких-либо форках, переписанных под win/visual studio  ???

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



Title: Re: TrueCoin <-- правильная монета
Post by: Storan on June 11, 2013, 03:25:26 PM
А разбирались, у существующих живых форков есть какие-либо джентльменские ограничения/изменения в функционале?
В смысле, что обязательно нужно изменять из списка, чтобы не конфликтовать с "родительскими" валютами : заголовки блоков, сетевые порты, префиксы адресов, в транзакциях что-либо, и т.п. ?


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on June 11, 2013, 03:54:39 PM
Ukigo, а вы ничего не слышали, а каких-либо форках, переписанных под win/visual studio  ???

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on June 12, 2013, 12:26:25 AM
Ukigo, а вы ничего не слышали, а каких-либо форках, переписанных под win/visual studio  ???

А то пока моё единственное достижение - так и не смог скомпилировать готовые исходники bitcoin'a в ехе-файлы  ;D
Раньше биткоин собирался MSVC без проблем... Потом на поддержку соответствующего мейкфайла забили. Принципиальных проблем с этим нет, был бы смысл. Оно понятно, что MSVC генерит более быстрый код, но это же не игровой движок все-таки.
Ну встроенный майнер присутствует же ::) Но я искал по другой причине, если до этого unix в глаза не видел, не то что его среды разработки, то трудно решиться что-то сделать в нём сделать.


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

Все таки хотите нечто выпустить ? :)

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

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

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on June 12, 2013, 06:29:35 AM
Ну QtCreator'ом компилирую, может из-за него ещё эта проблема с линковкой.

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

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


Title: Re: TrueCoin <-- правильная монета
Post by: rPman on June 12, 2013, 09:21:29 AM
Я и так могу скзать, без сильного изучения 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 ПОДСТРАИВАЮЩИЙ параметры алгоритма в зависимости от сложности (т.е. потребление памяти растет - правда что будет когда типичного компа не будет хватать...)


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on June 12, 2013, 06:44:28 PM
Таки С/C++ для меня чужеродный язык. ( ??? :)))

то есть у вас тройной хэш вида :
 Хэш512(Хэш512(Хэш512(...) ?
А чего не хотите последний сделать Хэш256 ?
транкировать( или trim256() это что-то другое ? ) может быть хуже чем использовать
 "готовый" 256-Й хэш...

Я не понимаю как оно у вас выбирает
 "в зависимости от пред. хэша"  ,
мой С/C++ ОЧЕНЬ базовый (
не могли вы объяснить русскими словами
 какие байты оно с чем сравнивает ?

------------
>> эффективный гпу-майнер сотворить мозг поломать надо будет...

Не, не мозг ж) ;)
Можно пойти иным путем, прежде чем дизайнить
 цепочки хэшей надо сделать так :
1) Выучить OpenCL
2) Пообщаться с опытными кодерами на нем
 по "майнерной" теме.
3) после 1) и 2) у вас появится понимание
 какая цепочка будут круче на ГПУ и насколько.
4) ???
5) Наступит просветление и нирвана Ж))))
___________
Да, это кружный путь, зато не придется
 по горам лазать...
Все умные делают это.Идут в обход то есть.



ну ещё чуток выбор изменю, и принцип таков будет. Есть хэш предыдущего блока (в роли случайной константы выступает); представляем его в пятеричной системе исчисления и выбираем хеш-функции для текущего блока по младшим разрядам этой константы (ну т.е. диапазон чисел в цифрах/разрядах будет 0005 - 4445; младшая цифра 0 - функция-0, цифра-1 - функция-1, ... цифра 4 - функция-4.  вторая и третья итерации то же самое, но по следующим цифрам этого пятеричного числа).

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


Я и так могу скзать, без сильного изучения 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 ПОДСТРАИВАЮЩИЙ параметры алгоритма в зависимости от сложности (т.е. потребление памяти растет - правда что будет когда типичного компа не будет хватать...)
А насколько scrypt с переменными параметрами вообще криптоустойчив? Профаном в такое лезть - может и выйдет придумать нечто труднозатратное на первый взгляд, а потом вдруг умник найдётся, который этот внезапно нестойкий алгоритм хакнет, и будет на атоме раз в минуту блоки рассчитывать, независимо от сложности в сети.

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

p.s.Это и есть magic bytes?
Code:
// The message start string is designed to be unlikely to occur in normal data.
// The characters are rarely used upper ASCII, not valid as UTF-8, and produce
// a large 4-byte int at any alignment.
unsigned char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };

Магическая строка вида const string strMessageMagic = "Bitcoin Signed Message:\n"; тоже присутствует, но не думаю что сетевой магик таким длинным сделали бы.


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on June 12, 2013, 06:58:05 PM
Хэш предыдущего блока - это не очень удачный выбор "случайного" числа. Потому что его выбором можно манипулировать в некоторых условиях.

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


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on June 12, 2013, 07:58:44 PM
Ну по-факту получается ведь не весь хэш, а младшие 64 бита.
(b64 % 5), ((b64/5) % 5), ((b64/25) % 5) и во всех этих итерациях результат зависит от всех битов;  подбирать хэш блока не только по старшим битам для сложности, но и по 64 младшим для получения "форы" в следующем блоке безумием будет.
Вот только эти деления по модулю не совсем случайные получаются, всё-таки для целых не выполнится 2m == 5n; но думаю от того что какая-то цепочка 100 раз повторится, а другая 99 особо никто не пострадает, случайные отклонения в реальности будут гораздо больше.


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on June 12, 2013, 08:53:01 PM
Может статься, что даже перебирать не придется. В активной сети всегда происходят ситуации, когда возникают орфаны. Среди этих самых орфанов и может оказаться блок, который даст преимущество и позволит попутно сделать из орфана валидный блок. ::)


Title: Re: TrueCoin <-- правильная монета
Post by: Storan on June 12, 2013, 09:33:42 PM
Может статься, что даже перебирать не придется. В активной сети всегда происходят ситуации, когда возникают орфаны. Среди этих самых орфанов и может оказаться блок, который даст преимущество и позволит попутно сделать из орфана валидный блок. ::)
Да уж  :-\. Спасибо, в таком варианте реально дыра для нечестного майна... Эх, жаль к позапрошлому хэшу лёгкого доступа нет.


Title: Re: TrueCoin <-- правильная монета
Post by: icreator on June 13, 2013, 06:16:19 AM
Quote
Сказ о пользе инфляции

 

Мы знаем, что волк в лесу считается необходимым животным для наилучшего развития животного мира леса. Он уничтожает слабых и больных, являясь тем самым своеобразным «санитаром леса». Охотясь, волки загоняют свою добычу, тем самым животные должны быть достаточно натренированы и сильны чтобы не стать добычей волка. Инфляция сродни волку, она в экономическом лесу выступает и санитаром и тем механизмом, который тренирует бизнес. Как это происходит?

Известно, что банки предлагают процент по вкладам своим вкладчикам соизмеримый с текущей инфляции в стране. Рассмотрим случай, когда инфляция слишком низкая, например 0-3% в год. В этом случае банки также предлагают вкладчикам процент примерно 2%. В этом случае население в своём большинстве не захочет вкладывать свои накопления в банк. А вдруг банк прогорит? Да и ради такого маленького процента даже не охота в банк идти! Тем более что инфляции нет, и деньги могут просто «лежать в чулке» до какого-то времени. Мы видим, что маленькая численность «экономических волков» в «экономическом лесу» слабо действует на экономику. Теперь допустим, что уровень инфляции равен 12-15%. В этом случае банки уже предлагают населению допустим 12% годовых по депозитам. Тут уже население, да и предприятия, у которых есть свободные средства будут задумываться. Гражданин, копящий деньги на жилье будет выбирать: или за три года накопления денег для покупки квартиры он потеряет 36% из-за инфляции, или вложит в банк и потеряет не более 8% с разницы процентов банка и реальной инфляцией в стране. Большинство населения пойдет в банки и вложит свои деньги, вместо того чтобы хранить их «в чулке». А эти вложенные деньги вольются в экономику через кредиты развивающимся предприятиям. Что в свою очередь положительно отразится на развитии страны. Мы видим, что инфляция так же как и волк в лесу «съедает» слабых и неподготовленных – то есть неработающие деньги – деньги хранящиеся «в чулках». Одновременно инфляция, как и волк в лесу, заставляет остальные деньги «тренироваться» что бы убежать от «волка» - то есть деньги вкладываются в экономику, в результате чего растут благодаря банковским процентам, что в свою очередь оздоравливает весь «экономический лес» страны. В такой ситуации и любое предприятие заинтересованно в скорейшем обороте своих средств, чтобы в условиях инфляции остаться на плаву и еще получить прибыль, приведенную к уровню инфляции. Теперь рассмотрим случай, когда в стране слишком большая инфляция, например 30% и выше. Этот случай, как и любая крайность, является неблагоприятным. Это происходит прежде всего из-за того, что налоги собираемые правительством страны от момента перечисления их предприятием в бюджет и до момента реализации их, например выдаче их в виде  зарплаты бюджетным работникам, успевают сильно обесцениться. Как правило, время оборота бюджетных денег складывается из этапов сбора, учёта, накопления, перераспределения, перечисления и выдачи. Это время занимает от полугода до года, а иногда и более. За это время инфляция «съедает» их на треть, а то и больше! Таким образом, социальная сфера в стране начинает сильно страдать. Страдает и экономика: предприятия не успевают достаточно быстро обернуть свои средства так, чтобы не подвергнуть их инфляции, а это приводит к решению увеличить «накрутки на цену» фирмы без улучшения качества товара. Таким образом, развитие промышленности начинает тормозиться – «экономические волки» просто «съедают» всю «экономическую живность» в «экономическом лесу».

Сделаем выводы. Умеренная инфляция в 8-15% является стимулирующим фактором для развития экономики страны. Инфляция в экономике сродни волку в лесу, и выполняет функцию «санитара» и «тренера» экономики.

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

 

крипто-валюта для ЦБ страны:
http://nep-3000.livejournal.com/13824.html


Title: Re: TrueCoin <-- правильная монета
Post by: icreator on June 23, 2013, 07:45:19 PM
https://docs.google.com/document/d/1vfLw7FJwuA9OddOsSI1xr1YeQN5evm3p4K6kUu-1rto/edit?usp=sharing

Автоматическое регулирование величины эмиссии криптовалюты - поддержание оптимальной инфляции.

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

Например можно в качестве нормы взять величину “коэффициента избыточности” равную 0,5. Тогда:
-  если “коэффициент избыточности” > 0,5, то есть в сети свободных монет, которые просто лежат в кошельках, больше чем монет в неподтвержденных платежах, то включается механизм старения денег, так как это сделано сейчас в криптовалюте  FreiCoin (сайт криптовалюты  http://freico.in/ ). причем величина уничтожения находится в диапазоне 1-20% в год в зависимости от величины соотношения.
- если “коэффициент избыточности” < 0,5, то есть в сети свободных монет меньше, чем монет в неподтвержденных платежах, то включается механизм добычи новых монет, который реализован в криптовалюте NovaCoin (Proof-of-Stake - https://bitcointalk.org/index.php?topic=226592.0 ) - монеты, которые лежат нетронутыми какое-то время в кошельке, начинают генерировать новые монеты в размере 1-20% в год - величина генерации зависит от величины коэффициента избыточности.

хотя генерацию монет можно и по другому делать - как у PoW добычи


Title: Re: TrueCoin <-- правильная монета
Post by: Balthazar on June 23, 2013, 07:56:35 PM
Proof-of-Stake (равно как и Proof-of-Work) - это не печатные станки, а механизмы поддержания работоспособности распределенного сервера меток времени, и только. Генерация - это лишь побочный эффект, которого вообще может не быть.