DIANNA: IANA Decentralized концепт дизайн

[pent]

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

K=1/(F/6 - 1)

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

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

[pent]

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

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

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

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

[pent]

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

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

[pent]

А вот теперь правильно, в интегрально-дружелюбном исчислении.

Возьмем время, за которое биткоин вычисляет 2016 блоков как tsBase
Возьмем время, за которое дианна вычисляет 2016 блоков как ts

Тогда коэффициент K будет выражен как

K=tsBase/(ts-tsBase)

График функции K(ts). K становится меньше с возрастанием ts и не позволяет ts достигнуть tsBase (1.21E6)



ts так же можно выразить через частоту блоков в час, если принять биткоиновские данные константами:

F=2016*3600/ts

Это облегчает восприятие предыдущего графика функции. Тогда зависимость K от частоты выхода блоков дианы будет такая:

[pent]

Тогда значит примерно алгоритм nextFeeRequired на языке Ы (деления на ноль не проверял! )

Для простоты понимания эту процедуру в диане я назвал тоже ретаргетом. Хотя это репрайсинг =)

Code:

DChain=get_dianna_chain_index(); // Цепь дианы
BChain=get_bitcoin_chain_index(); // Цепь биткоин

tsTgt=60*60*24*14; // Шаг ретаргета биткоин и дианы в секундах (биткоин не ретаргетится по этому значению)
nB=2016; // Шаг ретаргета биткоин и дианы в блоках
lastRetarget=query_dianna_db("last_retarget_height"); // номер блока дианы с последним ретаргетом

Bfirst = BChain[BBestHeight - nB]; // блок последнего ретаргета биткоин
Blast = BChain[BBestHeight]; // последний блок биткоин
Dfirst = DChain[lastRetarget]; // блок последнего ретаргета дианы
Dlast = DChain[DBestHeight]; // последний блок дианы

tsB = Blast->ts - Bfirst->ts; // Сколько времени прошло с предыдущего ретаргета Bitcoin
tsD = Dlast->ts - Dfirst->ts; // Сколько времени прошло с предыдущего ретаргета DIANNA
retarget=0;
if (Dlast->height % nB == 0) retarget = 1; // ретаргет через nB блоков!
if (tsD >= tsTgt) retarget = 1; // ИЛИ ретаргет через tsTgt секунд

if (retarget == 1) :
  // Приводим к общему знаменателю
  tsD *= nB;
  tsD /= Dlast->height - Dfirst->height; // int!!!
  price = Dlast->price * tsTgt; // int64!!!!
  price /= tsD - tsTgt; // int64!!!!
  // Защита от дурака
  if (price > Dlast->price*4) price = Dlast->price * 4;
  if (price < Dlast->price/4) price = Dlast->price / 4;
  query_dianna_db("set_block_retaget_marker",BBestHeight + 1, true);
  return price;
endif

return Dlast->price;

[pent]

это даже проще для меня 

А как тогда выразить среднее ожидаемое время нахождения блока дианы в секундах ?

среднее время нахождения блока биткойна я считаю у себя так :
  time = difficulty * 2**32 / hashrate*10**9
то есть трудность и хэшрейт относятся к предыдущему блоку, а время исп. уже для текущего

Представь что сложность берется из текущего биткоин блока. Это почти одно и тоже.

Но диана добавляет к этой сложности еще PDiff %. То есть если Difficulty = 10**6, а PDiff насчитали на 0.1, то блок дианы считается по сложности (10**6 + 10**5), т.е. DiannaDifficulty=Difficulty*(1+Pdiff)

[pent]

Пару слов о сложности. Difficulty, это просто такая мера величины для прикида на глаз, т.к. это дабл. А дабл значение не может быть точно выражено в процессорном понимании.

Биткоин оперирует понятием таргет. Это uint256.

Для простоты понимания таргета был введен difficulty=maxtarget/target

Но для тестовых расчетов всяких там ожиданий difficulty годится. Не годится в боевом коде.

Считай мощности биткоин и дианы равны. Как будто оба обладают одинаковыми мощностями. Мержед это предоставляет.

[pent]

Ну коли охота трахаться с uint256, то валяй =)

[pent]

Мне кажется ты зря мучаешься с эмуляцией биткоин цепи. В биткоин итак все понятно. Bounty=50, sum(txfee)-->0

Можно просто взять данные развития неймкоин с апреля 2011 по сей день.

далее из неймкоин вытянуть такую таблицу:

block_id:block_timestamp:num_ops
block_id:block_timestamp:num_ops
....
block_id:block_timestamp:num_ops

Далее, создаем 1 блок дианы (считаем 1 неймспейс) датой 1 блока неймкоин с одной транзакцией и стартовой ценой, скажем, 0.01 BTC.

Потом, исходя из таблицы неймкоин, создаем другие блоки. Их expectation time будет на PDiff % больше, чем у биткоина, то есть в среднем 10+10*PDiff минут. Создаем их так, чтобы виртуальным кастомерам не приходилось ждать более суток апдейта. Делаем репрайсинг и т.п.

Хотя мне чето кажется все равно это не реально будет. У неймкоин домены были сначала дорогие, счас вообще халява, спама полно. К тому же оборот по диане начнет влиять на курс USD/BTC, а этого мы не можем рассчитать.

Например, если биткоин вдруг взлетит до 100 USD, а цена дианы была 0.5 BTC, то никто не захочет за 50 баксов апдейтить домен. Спрос упадет, за ним и цена дианы до приемлимого уровня.

В общем тут есть взаимные влияния, которые трудно рассчитать.

Надо если рассчитывать, то предполагать что курс USD/BTC фиксированный. Что биткоин блоки выходят каждые 10 минут на одинаковой сложности. Тогда расчет какой то вменяемый получится. Обратные связи в системе скомпенсируют эти допущения в реале.

[pent]

Время в блоках, цены в коинах. Да. А как по другому?

[pent]

Время в блоках -- это разумно
Дык я и не шучу -- не стоит беспокоится слишком много о курсе к $
через пару лет в Америке все равно дефолт будет

завтра понастраиваю свою беду
может у тебя еще какие варианты формулы цены есть ?
я бы их заодно попробовал

За курс точно не стоит беспокоиться, т.к. есть обратная связь. Если курс подскочил, получается подскочила и цена. Клиенты сказали "данунах" и спрос упал. Значит упало количество блоков в промежуток времени. Значит, цена будет вскоре пересчитана в меньшую сторону.

И наоборот.

Так что обратка есть, все нормально.

Вариант формулы изменения цены окончательный. Может еще просто лимиты K подправить надо будет. Сейчас 0.25 <= K <= 4

http://dianna-project.org/wiki/Domain_Transaction_Fee

[pent]

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

А мы тогда будем привязывать блок дианы не к предыдщему PARENT блоку, а непосредственно к нему.

То есть, PARENT блок Bitcoin должен быть включен в официальную цепь bitcoin. Только тогда блок DIANNA будет принят системой.

Сложность DIANNA всегда больше сложности Bitcoin. Значит любой подошедший PARENT-блок биткоин имеет немало шансов попасть в мейнстрим. Это еще больше повышает безопасность системы.

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

[pent]

Описал структуру доменной транзакции http://dianna-project.org/wiki/Domain_Transaction#Syntax
Описал логику Transaction Fee http://dianna-project.org/wiki/Domain_Transaction_Fee

[pent]

Описал возможные операции с доменом http://dianna-project.org/wiki/Domain_Transaction#Domain_operations
Переделал описание блока, описал синтаксис http://dianna-project.org/wiki/DIANNA_block#Syntax

[pent]

Описал детали имплементации мержед майнинга в DIANNA http://dianna-project.org/wiki/Merged_Mining

[pent]

Очередное изменение, ногами не бить Формула цены не была окончательной

Репрайсинг теперь происходит базируясь не на частоте блоков биткоин, а на пред-предыдущей частоте блоков DIANNA. То есть базируясь на частоте двух последних чекпоинтов репрайсинга. По этому цена гуляет в какую хош сторону и ищет свое значение, значение PDiff и частоту блоков, которая бы устроила данный неймспейс. Во!

http://dianna-project.org/wiki/Repricing_procedure

Если в цепи не было активности в течении последнего "bitcoin-года", цепь уничтожается.

Это реально ТруЪ получился. Каждый неймспейс будет иметь свой адекватный прайс, и свою адекватную частоту появления блоков.

[pent]

Цена сдирается за полный или неполный килобайт, точнее 1000 байт. А пдифф считается по сумме таких сдираний.

Цена операции равна прайсу в простом случае, когда значение не больше килобайта.

[pent]

А что ты вообще считаешь? Какие исходные данные? Какой первый блок? Сколько он генерируется?

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

Кгхм. Ну ессесно. К - это не цена, это нельзя добавлять.

[pent]

Мои комментарии по поводу tru

Code:

def reprice(h):
    if h == 0:
        return old_price
    n_prev = h - check_prev
    n_preprev = check_prev - check_preprev
    ts_prev = times[h-1] - times[check_prev]
    ts_preprev = times[check_prev] - times[check_preprev]
    koef = (ts_preprev * n_prev)/(ts_prev * n_preprev+333) # division by zero !!!
    price = old_price * koef
    return price

Во-первых, нет никакого деления на ноль:

Code:

  if n_prev == 0 and n_preprev == 0:
     return old_price/4;
 if n_prev == 0:
     return old_price/4;
 if n_preprev == 0:
     return old_price*4;

Во вторых, s/+333//g, это оч большой костыль.

В третьих,

Code:

if price > old_price*4:
 price = old_price*4;
if price < old_price/4:
 price = old_price/4;

В четвертых, у тебя питон воспринимает koef как integer, а не float. То есть дробную часть откидывает. Я не очень дружу с питоном, но вот это исправило ситуацию

Code:

    koef = float(1)
    koef = koef * ts_preprev/ts_prev
    koef = koef * n_prev/n_preprev

В-пятых, скорость появления блока < 600 секунд маловероятна.

Code:

return int(times[b-1] + winestim + random.randrange(1, 90))

Впрочем, это не важно, можешь оставить -130 .. 130

В шестых, вот этот кусок кода надо сделать вот таким образом:

Code:

   if ((z - check_prev) % 2016 == 0):
       checks.append(z)
       print "==checkpoint by blocknum"
       new_price = reprice(z)
       check_preprev = check_prev
       check_prev = z
    else: ###### !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
       if ((times[z]-times[check_prev]) >= 1209600): ##### !!!!!!!!!!!!!!!1
          checks.append(z)
          print "==checkpoint by time: span=", times[z]-times[check_prev], " (tgt: 1209600)"
          new_price = reprice(z)
          check_preprev = check_prev
          check_prev = z

ИТОГО:

Code:

#!/usr/bin/env python

import time, sys, random

random.seed(time.asctime())
#print random.randint(1,77)

last = 200000

winestim = 600

check_prev = 0
check_preprev = 0

prices = []
checks = []
times = []

deltas = []


start_price = 0.02


def set_time(b):
    if b == 0:
        return 1370000000
#    print times[b-1] + winestim + random.randrange(-130, 130)
    return int(times[b-1] + winestim + random.randrange(1, 90))
#    return int(times[b-1] + winestim + 30)


def reprice(h):
    print "=====checkpoint @", h
    if h == 0:
        return old_price
    if h == 2016:
        return old_price
    n_prev = h - check_prev
    n_preprev = check_prev - check_preprev
    if n_prev ==0 and n_preprev ==0:
        return old_price/4
    if n_prev == 0:
        return old_price/4
    if n_preprev == 0:
        return old_price * 4;
    ts_prev = times[h-1] - times[check_prev]
    ts_preprev = times[check_prev] - times[check_preprev]
    print "check_prev=",check_prev," check_preprev=",check_preprev
    print "nprev=", n_prev, " npprev=",n_preprev
    print "tsprev=", ts_prev, " tspprev=",ts_preprev
    koef = float(1)
    koef = koef * ts_preprev/ts_prev
    koef = koef * n_prev/n_preprev
    print "k=",koef
    price = old_price * koef
    if price > old_price*4:
        price = old_price*4
    if price < old_price/4:
        price = old_price/4
    print "old=", old_price," new=", price
    return price


old_price = start_price

for x in range(0, last):
    times.append(0)

for z in range(0, last):
    times[z] = set_time(z)
#    if z !=0:
#       print "Block #",z," time=", times[z], "diff=", times[z]-times[z-1]
    if z < 2016:
        continue

    if ((z - check_prev) % 2016 == 0):
       checks.append(z)
       print "==checkpoint by blocknum"
       new_price = reprice(z)
       check_preprev = check_prev
       check_prev = z
    else:
       if ((times[z]-times[check_prev]) >= 1209600):
          checks.append(z)
          print "==checkpoint by time: span=", times[z]-times[check_prev], " (tgt: 1209600)"
          new_price = reprice(z)
          check_preprev = check_prev
          check_prev = z
    if new_price != old_price:
        old_price = new_price
        print "====== repricing ======="
        print "price =", old_price, "at block #", z
        prices.append(old_price)
print
print "min & max prices were =", min(prices), max(prices)
print
print "checkpoints were : "
print
print checks
print

РЕЗУЛЬТАТ при равномерном распределении спроса (random) и стартовой цене 0.02, за 200к блоков

Code:

min & max prices were = 0.0200060868679 0.0211689919176

checkpoints were : 

[2016, 3892, 5768, 7644, 9521, 11396, 13272, 15147, 17024, 18901, 20774, 22648, 24526, 26401, 28277, 30151, 32030, 33905, 35779, 37655, 39530, 41406, 43283, 45157, 47033, 48907, 50783, 52659, 54534, 56410, 58289, 60167, 62043, 63918, 65792, 67671, 69543, 71419, 73297, 75173, 77051, 78927, 80804, 82682, 84558, 86435, 88311, 90189, 92064, 93938, 95815, 97689, 99567, 101444, 103317, 105193, 107067, 108946, 110822, 112700, 114577, 116455, 118330, 120207, 122080, 123958, 125833, 127709, 129581, 131458, 133332, 135209, 137086, 138963, 140838, 142715, 144592, 146466, 148345, 150225, 152100, 153975, 155850, 157726, 159601, 161479, 163356, 165233, 167109, 168985, 170861, 172738, 174616, 176490, 178367, 180245, 182120, 183996, 185869, 187739, 189618, 191496, 193370, 195244, 197122, 198997]

Цена гуляла в течении 4 лет аж в пределах 10%. Но это без обратки. "Общественность" в виде функции random не "возмущалась" по поводу скачка цены, понижая спрос И вообще цена random() устраивала похоже По этому наблюдался стабильный рост.

Полный лог http://pastebin.com/2TvsE3pJ

[pent]

Рост цены в 10% за 4 года при псевдо-равномерном распределении я связываю с тем, что где то допущена ошибка в расчете блок-фрейма. Где то откуда то надо вычесть единицу в общем в индексе =)