Так, я короче гоню. Взял частоту вместо отношения. Получилось все наоборот

Счас перепишу формулы.

Центрально децентрализованный DNS

Коллизии sha2??? Или у них там мд5 по ходу?

Для начала можно просчитать динамику развития неймспейса .bit Данные по нему в динамике имеются в блокчейне. Дамп блоков неймкоин доступен через RPC.

Нужны дампы активности доменных операций в формате

блок:таймштамп:кол-во операций с доменами
блок:таймштамп:кол-во операций с доменами
блок:таймштамп:кол-во операций с доменами

кол-во операций это name_firstupdate + name_update

Чето уж сильно жеские коэфициенты получаются. Надо брать более либеральную пологую функцию. Не разницы а отношения

K=1/(F/6 - 1)

Получается на промежутке от 9 до 12,5 блоков в час цена вальсирует в пределах 20%.

В общем, Ukigo, пересчитай плз обе

Кстати, это все выше идеальная формула. В реалиях там цифру 6 надо заменить на реальную частоту выхода Bitcoin блоков, чтобы перестраховаться наверняка от излишней активности или медлительности сети.

Ну и там будет интегральный расчет, без всяких double'ов. Без бутылки не разберешься.

Ага. Получается чето типа

diana1:bitcoin1
diana2:bitcoin3
diana3:bitcoin5

Если проплата была в bitcoin2, то ищем ближайший меньший блок дианы, то есть diana1.

И у нас есть формула поправки цены. Я изобретать велосипед не стал. Взял сатошинскую формулу пересчета таргета. То есть функция вида 1/x

Поскольку сложность дианы будет чуть больше сложности биткоин, блоки дианы должны стремиться к частоте биткоин - 6 в час, но никогда ее не достигать (иначе фри домены).

Отсюда вытекает коэфициент поправки к текущей цене.

Цена зашита в блок типа как в биткоин зашита сложность (nBits). Цена измеряется в BTC.

1 раз в 2016 блоков или 1 раз в 14 суток (какое из условий первое совпало) - включается пересчет цены.

В любом случае, как и в биткоин, берется последний тайм-фрейм 14 суток и количество блоков в нем (N). Количество блоков делим на 336 (часов) и получаем цифру F:

F=N/336

Определяем допустимые границы разового изменения K (как в биткоин)

K_min=0.25
K_max=4

Исходя из F, считаем на что нужно умножить текущую цену

K=K_max | if (K <=6) - да, могут быть чудеса
K=1/(F-6)  | else

График 1/(F-6) выглядит так:



Далее, проверяем что K вписался в пределы K_min <= K <= K_max и умножаем текущую цену в блоке на K

Price=K*Price

Из этого графика следует что цена будет стремиться к стабилизации на частоте 7 блоков в час (k=1)

Задает начальную цену первого блока, первый майнер, которой намайнил блок с PDIff=100% (2x Сложность биткоина).

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

Target=BitcoinTarget / (1 + (int64 SumDomainFees)/(int64 BitcoinBounty + int64 SumBitcoinFees))

Таргет получается для каждого блока свой.

Все что выше в ходе кодинга должно быть по максимуму приведено к интегральной математике для кросс-платформенной совместимости.

Voila.

Да, мухлюют с таймштампами. Но в определенных границах. Там погрешность от десятков минут до пары часов. Что в контексте двух недель особой погоды не делает.

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

Значит им и будем штамповать блоки диана. Хешем предыдущего блока PARENT'а. Ну для еще большей стабильности, можно взять хеш пред-предпоследнего блока =)

И будет условие принятия блока диана: чтобы хеш предыдущего к PARENT блока был в официальной цепи.

Оттуда и берем базовый таргет.

Оттуда и строим соответствие блок_диана:блок_биткоин

А из этого соответствия определяем, корректно ли была уплочена цена, т.к. цена задается жестко в блоке дианы. Ну такой себе платеж задним числом. Ну а че =)

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

Я похоже не до конца понимал принцип работающей версии мержед майнинга.

https://bitcointalk.org/index.php?topic=67451.0

AUX блоку не обязательно должен соответствовать "официальный" блок. Это не вписывается в архитектуру дианы. Что мы можем сделать?

Становится немного непонятно как правильно определять текущий таргет биткоина, т.к. в приаттаченом недоблоке можно подсунуть любой таргет.

Вывод: транзакции с комиссиями блока дианы майнер должен скалдывать в 1 блок биткоин и на него давать ссылку. Оттуда возьмем и таргет. Это не проблема, т.к. комиссии идут в приватном порядке лично майнеру. Не обязательно их бродкастить. Вашу мамашу, как все это синкать потом?

Ох и проблем отгребли с разделением финансовой цепи =)

Итак, теоретическая база

https://github.com/vinced/namecoin/blob/mergedmine/doc/README_merged-mining.md
https://en.bitcoin.it/wiki/Alternative_Chains#Sharing_work

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

Как я понимаю реализацию.

1. Строится дополнительный Merkle Tree (AUX Tree) где то в воздухе, из root Merkle хешей блоков всех доступных AUX чейнов. В простейшем случае неймкоин, это тупо хеш одного AUX'а неймкоина
2. В CoinBase scriptSig биткоина суется рут-хеш этого дерева (там по протоколу может быть что угодно)

Таким образом, если мы майним блок биткоин с рут хешем дерева AUX'ов, то при успехе, у нас есть доказательство работы - намайненый блок биткоин и в нем есть рут этого древа AUX Tree.

Майнится с наименьшей сложностью из всех. Кому подошла - тому повезло. Подошло к наибольшей сложности - повело всем =)

В блок биткоин суется только рут хеш дерева AUX'ов в позволительное место (scriptSig нулевой транзакции).

При этом к AUX блоку цепляется куча левой инфы для верификации:
а) Меркль ветка AUX блока в AUX Tree
б) Индекс а) в AUX Tree (зачем, если ветка есть?)
в) Нулевая транзакция биткоин в найденом блоке, конкретно интересует ее scriptSig с рутом AUX Tree.
г) Меркль ветка предыдущего пункта в дереве Bitcoin блока
д) Хидер блока биткоин

Верификация AUX блока:
1. Из ветки а) вычисляется рут хеш AUX Tree
2. В сохраненном хидере проверяем что этот хеш есть в в)
3. в) должна быть корректно втиснута в г) с соответствующим рут хешем
4. Хеш д) меньше таргета AUX chain
5. а) стоит четко на индексе б) AUX Tree

Таким образом, даже если этот недо-биткоин блок не вошел в "официальную" цепь биткоин, он все равно служит доказательством Proof-Of-Work AUX блока, так как он к нему приаттачен.

Это позволяет майнить AUX'ы и PARENT'ы на разных сложностях, независимо друг от друга, с одной и той же мощностью.

А где хранится весь AUX Tree?
Какие тут могут быть сюрпризы? Один из участников утверждал что это чревато дабл-спендами в AUX'ах.

Что то работы скопилось по основной занятости =)


Почему я предлагаю измерять TTL в блоках биткоин?

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

Но это наверно касается не TTL, а периода пересчета цены. Какие тут варианты решения этой проблемы?

Варант 1. Тогда можно сделать то, над чем я думал. Включать пересчет цены через N блоков (допустим 2016) или через соответствующий промежуток таймштампа (допустим, 14 суток). То есть при таком раскладе, пересчет цены включится через 14 суток в любом случае, даже без активности в цепи.

Но вот опять же. Заплатил человек комиссию, она включилась в цепь биткоин, блок дианы еще не создался. И тут бац - пересчет цены. То есть заплатил по старой цене а считать уже нужно по новой. Что тут делать?

Я думал ттл и соответствие цены к блоку считать по блокам биткоин. Это надежно, но геморройно. (вариант 0)

Вариант 2. Но может просто вернуть опять дифпенальти? И считать не по строгой цене, а допускать отклонения, но за пенали в сложности. Однако это вносит непонятки в прайсинг майнеров.

Вариант 3. Транзакцию с комиссией не бродкастить, а отдавать лично майнеру вместе со всеми остальными данными по домену. И ввести правило что транзакция с комиссией должна быть запечатана в родительский блок дианы. Однако это создает сложность в майнинге. Если майнер поймает правильный хеш блока биткоин, а блок дианы еще не нашелся - майнер будет вынужден пропустить блок биткоин. Это плохо.

Вариант 4. ттл и пересчет блоков в блоках дианы. Но вести какую то базу соответствия блоков биткоин к блокам дианы. Типа этому блоку биткоин соответствует этот ближайший блок дианы. И тогда правильность цены можно определить довольно точно. Платеж был в N-м блоке биткоин, значит, ему соответсвует цена M-го блока дианы.

Итого наиболее безопасный вариант №4 мне кажется. Правда придется помучаться с синхронизацией =)

Чтобы определить формулу цены, надо:

* Узнать как мержед майнинг влияет на частоту выхода блоков. Т.е. при одинаковой сложности AUX и PARENT чейна, будет ли различаться частота выхода блоков обеих в среднем. И если да, то по какому закону.
* Отсюда определить оптимальную частоту выхода блоков DIANNA

а потом уже считать цену как биткоин считает таргет.

В блоке вместо таргета (nBits) будет зашита цена (int64)

Вот вчера всю ночь сидел крафтил транзакции, *ля буду, пропускало ) Пока не понял что в скрипте ошибка и Гевин подтвердил )

Ну это уже новомодное введение. Версия 0.5.2 пропустила IsStandard такого scriptPubKey на ура. Не пропустила eval скрипта. А так, все нормально.

Если бы скрипт заканчивался двумя OP_ENDIF, то пропустил бы еще и как такой вот инпут:

БАЙТ200ВСЯКОГО0ХЛАМА 1 2 3 4

Специально смотрел сорцы.

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

Вообще в английском треде мне подсказали что опкоды соответсвуют ASCII-строке "script" = "OP_IFDUP OP_IF OP_2SWAP OP_VERIFY OP_2OVER OP_DEPTH"

Кто то короче забыл конфиг поправить )))

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

То есть что то вроде (не идеально)

Price_k = F_bitcoin/F_dianna - 1

То есть, раз в 2016, скажем, блоков биткоин, запускается пересчет цены. Прошлая цена умножается на это отношение.

Я еще подумаю над этой формулой. Но она там выводится из все этих базовых биткоиновских формул.

По поводу стартовой цены, предлагаю сделать кто открыл первый блок в неймспейсе, тот и задает первую цену.

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

В дополнение, открыть первый блок в неймспейсе можно только по двойной сложности Bitcoin.

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

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

Майнерам от майнинга реальных доменов очевидный профит. Они заинтересованы в нормальном бизнесе.