pent (OP)
|
|
March 06, 2012, 10:49:37 AM |
|
Чето уж сильно жеские коэфициенты получаются. Надо брать более либеральную пологую функцию. Не разницы а отношения K=1/(F/6 - 1) Получается на промежутке от 9 до 12,5 блоков в час цена вальсирует в пределах 20%. В общем, Ukigo, пересчитай плз обе
|
|
|
|
|
|
|
Even if you use Bitcoin through Tor, the way transactions are handled by the network makes anonymity difficult to achieve. Do not expect your transactions to be anonymous unless you really know what you're doing.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
pent (OP)
|
|
March 06, 2012, 11:18:03 AM Last edit: March 06, 2012, 11:35:05 AM by pent |
|
Для начала можно просчитать динамику развития неймспейса .bit Данные по нему в динамике имеются в блокчейне. Дамп блоков неймкоин доступен через RPC. Нужны дампы активности доменных операций в формате блок:таймштамп:кол-во операций с доменами блок:таймштамп:кол-во операций с доменами блок:таймштамп:кол-во операций с доменами кол-во операций это name_firstupdate + name_update
|
|
|
|
pent (OP)
|
|
March 06, 2012, 12:02:26 PM |
|
Так, я короче гоню. Взял частоту вместо отношения. Получилось все наоборот Счас перепишу формулы.
|
|
|
|
pent (OP)
|
|
March 06, 2012, 01:48:30 PM |
|
А вот теперь правильно, в интегрально-дружелюбном исчислении. Возьмем время, за которое биткоин вычисляет 2016 блоков как tsBase Возьмем время, за которое дианна вычисляет 2016 блоков как ts Тогда коэффициент K будет выражен как K=tsBase/(ts-tsBase) График функции K(ts). K становится меньше с возрастанием ts и не позволяет ts достигнуть tsBase (1.21E6) ts так же можно выразить через частоту блоков в час, если принять биткоиновские данные константами: F=2016*3600/ts Это облегчает восприятие предыдущего графика функции. Тогда зависимость K от частоты выхода блоков дианы будет такая:
|
|
|
|
pent (OP)
|
|
March 06, 2012, 02:21:06 PM Last edit: March 06, 2012, 02:51:05 PM by pent |
|
Тогда значит примерно алгоритм nextFeeRequired на языке Ы (деления на ноль не проверял! ) Для простоты понимания эту процедуру в диане я назвал тоже ретаргетом. Хотя это репрайсинг =) 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 (OP)
|
|
March 06, 2012, 02:26:52 PM |
|
это даже проще для меня А как тогда выразить среднее ожидаемое время нахождения блока дианы в секундах ? среднее время нахождения блока биткойна я считаю у себя так : time = difficulty * 2**32 / hashrate*10**9 то есть трудность и хэшрейт относятся к предыдущему блоку, а время исп. уже для текущего Представь что сложность берется из текущего биткоин блока. Это почти одно и тоже. Но диана добавляет к этой сложности еще PDiff %. То есть если Difficulty = 10**6, а PDiff насчитали на 0.1, то блок дианы считается по сложности (10**6 + 10**5), т.е. DiannaDifficulty=Difficulty*(1+Pdiff)
|
|
|
|
pent (OP)
|
|
March 06, 2012, 02:44:01 PM |
|
Пару слов о сложности. Difficulty, это просто такая мера величины для прикида на глаз, т.к. это дабл. А дабл значение не может быть точно выражено в процессорном понимании.
Биткоин оперирует понятием таргет. Это uint256.
Для простоты понимания таргета был введен difficulty=maxtarget/target
Но для тестовых расчетов всяких там ожиданий difficulty годится. Не годится в боевом коде.
Считай мощности биткоин и дианы равны. Как будто оба обладают одинаковыми мощностями. Мержед это предоставляет.
|
|
|
|
pent (OP)
|
|
March 06, 2012, 02:55:38 PM |
|
Ну коли охота трахаться с uint256, то валяй =)
|
|
|
|
pent (OP)
|
|
March 07, 2012, 03:44:34 PM Last edit: March 07, 2012, 04:14:39 PM by 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 (OP)
|
|
March 07, 2012, 05:13:59 PM |
|
Время в блоках, цены в коинах. Да. А как по другому?
|
|
|
|
pent (OP)
|
|
March 07, 2012, 06:24:36 PM |
|
Время в блоках -- это разумно Дык я и не шучу -- не стоит беспокоится слишком много о курсе к $ через пару лет в Америке все равно дефолт будет
завтра понастраиваю свою беду может у тебя еще какие варианты формулы цены есть ? я бы их заодно попробовал
За курс точно не стоит беспокоиться, т.к. есть обратная связь. Если курс подскочил, получается подскочила и цена. Клиенты сказали "данунах" и спрос упал. Значит упало количество блоков в промежуток времени. Значит, цена будет вскоре пересчитана в меньшую сторону. И наоборот. Так что обратка есть, все нормально. Вариант формулы изменения цены окончательный. Может еще просто лимиты K подправить надо будет. Сейчас 0.25 <= K <= 4 http://dianna-project.org/wiki/Domain_Transaction_Fee
|
|
|
|
pent (OP)
|
|
March 07, 2012, 08:14:58 PM |
|
Я подумал, а может же быть DDoS такой, что один майнер будет майнить по 1 транзакции на почти минимальной сложности биткоина и может завысить цену до потолка, не теряя ничего при этом? Может.
А мы тогда будем привязывать блок дианы не к предыдщему PARENT блоку, а непосредственно к нему.
То есть, PARENT блок Bitcoin должен быть включен в официальную цепь bitcoin. Только тогда блок DIANNA будет принят системой.
Сложность DIANNA всегда больше сложности Bitcoin. Значит любой подошедший PARENT-блок биткоин имеет немало шансов попасть в мейнстрим. Это еще больше повышает безопасность системы.
Это уравнивает шансы пуллов согласно их хешрейтам, а чтобы заспамить диану, надо чтобы сеть bitcoin принимала каждый блок пулла. А это практически невозможно.
|
|
|
|
pent (OP)
|
|
March 07, 2012, 08:57:56 PM |
|
|
|
|
|
pent (OP)
|
|
March 08, 2012, 12:12:57 AM |
|
|
|
|
|
|
pent (OP)
|
|
March 08, 2012, 03:19:48 AM Last edit: March 08, 2012, 03:47:23 AM by pent |
|
Очередное изменение, ногами не бить Формула цены не была окончательной Репрайсинг теперь происходит базируясь не на частоте блоков биткоин, а на пред-предыдущей частоте блоков DIANNA. То есть базируясь на частоте двух последних чекпоинтов репрайсинга. По этому цена гуляет в какую хош сторону и ищет свое значение, значение PDiff и частоту блоков, которая бы устроила данный неймспейс. Во! http://dianna-project.org/wiki/Repricing_procedureЕсли в цепи не было активности в течении последнего "bitcoin-года", цепь уничтожается. Это реально ТруЪ получился. Каждый неймспейс будет иметь свой адекватный прайс, и свою адекватную частоту появления блоков.
|
|
|
|
pent (OP)
|
|
March 08, 2012, 06:10:53 AM |
|
Цена сдирается за полный или неполный килобайт, точнее 1000 байт. А пдифф считается по сумме таких сдираний.
Цена операции равна прайсу в простом случае, когда значение не больше килобайта.
|
|
|
|
pent (OP)
|
|
March 09, 2012, 06:47:01 AM |
|
А что ты вообще считаешь? Какие исходные данные? Какой первый блок? Сколько он генерируется? замена умножения на сложение приводит к плавному росту цены в облака Кгхм. Ну ессесно. К - это не цена, это нельзя добавлять.
|
|
|
|
pent (OP)
|
|
March 09, 2012, 06:53:20 AM Last edit: March 09, 2012, 08:28:56 AM by pent |
|
Мои комментарии по поводу tru 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
Во-первых, нет никакого деления на ноль: 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, это оч большой костыль. В третьих, if price > old_price*4: price = old_price*4; if price < old_price/4: price = old_price/4;
В четвертых, у тебя питон воспринимает koef как integer, а не float. То есть дробную часть откидывает. Я не очень дружу с питоном, но вот это исправило ситуацию koef = float(1) koef = koef * ts_preprev/ts_prev koef = koef * n_prev/n_preprev
В-пятых, скорость появления блока < 600 секунд маловероятна. return int(times[b-1] + winestim + random.randrange(1, 90))
Впрочем, это не важно, можешь оставить -130 .. 130 В шестых, вот этот кусок кода надо сделать вот таким образом: 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
ИТОГО: #!/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к блоков 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 (OP)
|
|
March 09, 2012, 08:40:19 AM |
|
Рост цены в 10% за 4 года при псевдо-равномерном распределении я связываю с тем, что где то допущена ошибка в расчете блок-фрейма. Где то откуда то надо вычесть единицу в общем в индексе =)
|
|
|
|
|