Topic: DIANNA: IANA Decentralized концепт дизайн - page 7. (Read 31554 times)

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

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://bitcointalksearch.org/topic/merged-mining-67451

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

ok. спасибо за формулы -- завтра посмотрим что я смогу из
этого всего выжать.

Ну, можно сделать оч малым но не 0, на практике тоже самое будет
но никакой халявы )

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

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

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

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

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

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

Price_k = F_bitcoin/F_dianna - 1

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

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

есть предложение фиксировать цену купленного домена.
Плюсы: дополнительный интерес к системе со стороны инвесторов/спекулянтов.
Минусы: ...?

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

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

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

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

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

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

a PDiff тоже может быть == 1 ? или == 0 ?

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

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

это атака не для совершения даблспенда, это даже вообще не атака, скорее уязвимость, приводящая фактически к захвату сети.
Если у меня будет более 50% работы всей сети и более-менее приличная мощность (чтобы не сильно отстать по времени), я смогу сгенерировать более длинную цепочку валидных блоков. В итоге конкурентам придётся выполнять на 25 - 30% больше работы (так как их блоки получат статус orphaned).
Даже если уязвимость надуманная, докажите обратное.

Надо понимать что к диане 51% атака уже не относится, пока биткоин к ней устойчив.

надо понимать, что все майнеры участвуют в коллективной проверке друг друга, соответственно чем больше узлов, тем выше надёжность сети. Если платить конкретным людям, то самый раскрученный сервис может получить >50% работы сети, что то же самое, что и получение 51% мощности. (пул может быть и будет работать честно, однако важен сам факт возможности атаки)

Сделай пож. еще раз расчет по обороту биткойнов(мин/макс) за доменные операции
у тебя был такой расчет выше

и что будет с этим значением когда станет 25 BTC/блок ?
это уже будет другое значение или нет ?

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

Пуллы работают по айпи обычному. И заговоры всегда чреваты утерей электората. Особенно если всколыхнуть общественность.

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

Нездоровый перфекционизм всегда мешает.