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

[Balthazar]

А кто сказал, что PoS непременно обязан быть чистым? Гибридного вполне хватит, если создать надлежащие условия.

[Storan]

А 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 защиты от дабл-спенд атак?

[Balthazar]

Добавит, но привязка к номерам, равно как и неполноценность блоков не имеют смысла. Подобное ограничение только добавит проблем и ухудшит масштабируемость, плюс теряется энергоэффективность.

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

[Storan]

Добавит, но привязка к номерам, равно как и неполноценность блоков не имеют смысла. Подобное ограничение только добавит проблем и ухудшит масштабируемость, плюс теряется энергоэффективность.

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

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

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


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

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

[Storan]

Ukigo, а вы ничего не слышали, а каких-либо форках, переписанных под win/visual studio 

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

[Storan]

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

[Balthazar]

Ukigo, а вы ничего не слышали, а каких-либо форках, переписанных под win/visual studio 

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

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

[Storan]

Ukigo, а вы ничего не слышали, а каких-либо форках, переписанных под win/visual studio 

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

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

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

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

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

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

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

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

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

[Storan]

Ну QtCreator'ом компилирую, может из-за него ещё эта проблема с линковкой.

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

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

[rPman]

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

[Storan]

Таки С/C++ для меня чужеродный язык. ( ))

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

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

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

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

ну ещё чуток выбор изменю, и принцип таков будет. Есть хэш предыдущего блока (в роли случайной константы выступает); представляем его в пятеричной системе исчисления и выбираем хеш-функции для текущего блока по младшим разрядам этой константы (ну т.е. диапазон чисел в цифрах/разрядах будет 000₅ - 444₅; младшая цифра 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"; тоже присутствует, но не думаю что сетевой магик таким длинным сделали бы.

[Balthazar]

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

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

[Storan]

Ну по-факту получается ведь не весь хэш, а младшие 64 бита.
(b64 % 5), ((b64/5) % 5), ((b64/25) % 5) и во всех этих итерациях результат зависит от всех битов;  подбирать хэш блока не только по старшим битам для сложности, но и по 64 младшим для получения "форы" в следующем блоке безумием будет.
Вот только эти деления по модулю не совсем случайные получаются, всё-таки для целых не выполнится 2^m == 5ⁿ; но думаю от того что какая-то цепочка 100 раз повторится, а другая 99 особо никто не пострадает, случайные отклонения в реальности будут гораздо больше.

[Balthazar]

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

[Storan]

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

Да уж  . Спасибо, в таком варианте реально дыра для нечестного майна... Эх, жаль к позапрошлому хэшу лёгкого доступа нет.

[icreator]

Сказ о пользе инфляции

 

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

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

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

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

 

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

[icreator]

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 добычи

[Balthazar]

Proof-of-Stake (равно как и Proof-of-Work) - это не печатные станки, а механизмы поддержания работоспособности распределенного сервера меток времени, и только. Генерация - это лишь побочный эффект, которого вообще может не быть.