|
Хотя нет, в сад жаность майнера. Пусть делает что делает.
Сколько набрал из буфера - по такому PDiff и посчитал блок и выпустил его через соотв. количество секунд time = BitcoinDiff*(1+PDiff) * 2**32 / hashrate
Следующий блок можно считать только если выпущен предыдущий. То есть если на момент следующего "шага" системы предыдущий еще не выпустился, то следующий не считается.
Посмотрим как система сожрет такой SQRT спрос =)
|
|
|
|
|
Но вообще это выглядеть будет так.
Существует буфер, куда добавляются "заказы" каждый раз в 600 секунд по функции NumTrans(N,price)=num_transactions(N)*dov(price/0.02), где N - номер "раза".
Из этого буфера майнер забирает транзакции в блоки.
Он должен набрать транзакций на PDiff~=10%. Тогда он выпускает блок. Если он не может выпустить блок по причине недостатка транзакций, он пытается его выпустить с вероятностью
p(PDiff)=100 - 4*(PDiff*100-10)^2
Если же он "перебрал" транзакций из буфера, то он тоже пытается выпустить блок с этой вероятностью.
То есть система "шагает" шагом в 600 секунд. Каждый шаг наполняет буфер транзакций по функции. И каждые 600 сек принимается решение о выпуске блока дианы
(если предыдущий успел рассчитаться).
|
|
|
|
Смотри. Пусть транзакции у нас по 0.1 BTC. Тогда если майнер возьмет 50 транзакций, то его PDiff=50*0.1/50=0.1 (или 10%) Теперь смотри на обратную параболу. 10% соответствует вероятность 100%: p(0.1)=100 - 4*(0.1*100-10)^2=100% Значит этот блок выйдет через (BitcoinDiff*1.1 * 2**32 / hashrate) секунд. Если майнер взял 60 транзакций, то Pdiff уже 60*0.1/50=0.12 (12%) p(0.12)=100 - 4*(0.12*100-10)^2=84% Значит, запускаем rand(0,100). Если 0 <= rand(0,100) <= 84, то блок выйдет через (BitcoinDiff*1.1 * 2**32 / hashrate) секунд. Если нет, то повторяем процедуру через 600 секунд. |
|
|
|
|
Ukigo, сделай плз эти все вещи ) Я погляжу код и запустим эмулятор. Надеюсь я все учел. Не учел только влияние оборота дианы на курс биткоина. А оно будет.
Короче потом сэмулируем влияние на курс. Это тоже не сложно.
|
|
|
|
Ну и последнее, нам надо сэмулировать спрос. А вот тут сложнее. Предположим что курс BTC фиксированный. И рядового юзера устраивает цена $0.1 = 0.02BTC. Предположим, спрос будет в виде SQRT фукнции, в зависимости от номера блока: num_transactions(num_block)=10*sqrt(5*num_block)  Однако клиенты могут быть довольны или недовольны ценой и спрос в зависимости от этого будет увеличиваться или падать. Тогда надо ввести функцию, описывающую довольство клиентов. Очевидно коэффициент довольства будет равен 1 при цене в 0.02BTC. При цене ниже, коэфициент довольства будет резко увеличиваться. Если выше - резко падать. То есть, если предположить что p=price/base_price (base_price=0.02), то довольство будет dov(p)=2^(2*(1-p))  Тогда количество транзакций на блок с номером N будет NumTrans(N,price)=num_transactions(N)*dov(price/0.02) Но майнеры не могут принять прям все транзакции. Надо будет добавлять это количество транзакций в некий буфер ожидания. А из него по одной в блок и считать вероятность его появления по вышеуказанной формуле. Вероятность свершилась - вышел блок. |
|
|
|
Ну нормально =) Надо ввести еще функцию жадности майнеров. Это какая то обратная парабола вероятности от PDiff, означающая что майнер запустить блок в сеть. То есть, например на значениях PDiff ~10% высчитать блок не проблема. Вероятность хорошая. Больше - геморой с расчетом. Меньше - жаба давит. То есть функция майнерской жадности пусть будет выглядеть так: p(PDiff)=100 - 4*(PDiff*100-10)^2  Только Pdiff сюда передается не в процентах, а так, float. Фунrция возращает вероятность от 0 до 100 что данный блок с данным PDiff будет запущен в майнинг. А значит он выйдет через time = BitcoinDiff*(1+PDiff) * 2**32 / hashrate BitcoinDiff,hashrate брать текущие, считать их константами. И поехали. Добавляем транзакции в блоки, выпускаем блоки, делаем репрайс и т.п. Таким образом мы сэмулируем поведение майнеров. Оно довольно предсказуемо =) |
|
|
|
|
Мой на Ы устарел. Этот почти верный, насколько я могу судить невыспавшимся мозгом.
Надо усложнять скрипт.
Ввести функцию создания блока. Она будет добавлять транзакции, считать общую их цену, вычислять PDiff. Время появления такого блока будет рассчитываться исходя из BitcoinDiff + PDiff*BitcoinDiff и текущего хешрейта сети биткоин (допустим он постоянный).
Когда складываем транзакции, для упрощения берем их цену из текущего блока.
|
|
|
|
|
Looks like my favorite shampoo actively cleans the head of current trend =)
|
|
|
|
Для централизованных IP сетей тоже будет полезно забить себе какой то namespace и объявить его как TLD .diana, как верно подметил rpMan. Почему? Потому что вот эта запись, которая будет храниться в DIANNA: @ IN NS ns1.hosting.com. ; @ IN NS ns2.hosting.com.; вообщето сейчас эта запись хранится на рутовых корневых серверах IANA/ICANN. И все эти сервера расположены в США. Лишь зеркала по миру раскиданы. В последнее время до амеров начало доходить, что эти сервера вообще то стоят у них и они имеют власть затереть любую такую запись на основании SOPA/PIPA запроса. Мол, сайт что то там нарушает. Явный пример беспредела: http://www.megaupload.com/Зайдите и убедитесь что может быть с каждым сайтом. Так вот нехер хранить такие записи на центральных серверах =) Конечно, по IP могут прикрыть, но можно ведь переехать. Домен то не потеряешь - он в цепи DIANNA. А там его не так то просто выпилить. Но вообще всю эту кашу я специально для I2P заварил =) Там реально ТруЪ получится. |
|
|
|
О формате представления данных в базе 'имя -> информация о домене' есть какие-то наработки? может что готовое?
Для обычных доменов как минимум нужна поддержка метасимвола * (*.mydomain.diana), много IP на домен (плюс географическая привязка), в т.ч. алиасы в другие сети/цепочки... может еще что, я просто не в курсе в текущих веяниях DNS в Интернет.
Если ты имеешь в виду семантику <VALUE> домена, то глянь сюда: http://dianna-project.org/wiki/NamespaceЭто тоже дело имплементаторов - что туда пихать и в каком формате. Конкретно для твоего случая отвечаю. Допустим, TLD .diana соответствует неймспейс 100. Есть какая то страничка в вики для этого неймспейса с RFC-подобным описанием, что именно и в каком формате должно содержаться в <VALUE>. Может быть это будет даже RFC. А может у неймспейса будет свой сайт. Вариантов много. Ладно, не буду грузить вариантами, перейду к конкретике. Значит в этом неймспейсе домен mydomain.diana будет иметь имя "mydomain". Я так понимаю, если речь идет об централизованном IP, то будет использоваться традиционная схема DNS. А значит домен "mydomain" будет иметь <VALUE>: @ IN NS ns1.hosting.com. ; @ IN NS ns2.hosting.com.; А уже на этих NS'ах будет стоять бинд и расчехлять всякие вайлдкарды *.mydomain.diana => IP,IP,IP Другой пример - децентрализованная I2P с TLD .dia.i2p и доменом mail.dia.i2p, которому будет соответствовать дестинейшин хеш. Для I2P будет неймспейс 1, в нем будет запись с именем "mail" и значением: Y~V8YK2M-my6-Gw0lkrkJouxeqPuB03idp-4uT9pkIXCA5nki9m4YFfPObSPv0E7c2shBxwlUo-6beaRQ-7tCawJssDRc0C0PhRj12QUYYdtZP7JS8SQXy68gZIylY-wfyEXleIC4mYY5mSthhdUUfyo1lqzrdHc1NpjPBxRJcyMBFBGUeM7Of9E9M518jXpVl0bAmxSnr5dy7sgKAVNufzfqIBfEHnmL2ZYH78FoGnPybsV0F9~154emkmt89ZUbx0BuYvH3kT1zin8pSxKw1NqxvqYt7p8CElq1--U38rO9U5Y~kLB9f6F3RYJdkl28ANkvdgJUgqiHLVI5oPWATrJLAOokyGKhK4Xl4Bjp4SCuemxHwTOGyd-4Kl8cO41u3w1LksndX9stkV6U1X0gL9BeSIoa1997IgMLVbUiDMyCz7-cA0y2tc0EdQdlpc2y77nTdo7z23dMSJzWDXsrfmLhX7M24D70htLLc1dpwZ1BUEvM1uPqGfsBSrHdl-sAAAA Именно этот дестинейшин хеш сейчас соответствует хосту mail.i2p Однако он содержится в файле hosts.txt конфиг директории i2p, навязан разработчиками, ничем не подписан и не авторизован. И получится у нас вот такая вот штука: http://i2psupport.org/ (с чего все началось собсно)  Только я рисовал это для неймкоин  будет mywebsite.dia.i2p или mywebsite.tor =) Это будет бомба. Форк Интернет без контроля и границ. Никто не сможет вычислить и закрыть сайт, а серфинг по таким сайтам станет удобным и понятным. Полная криптоанархия! |
|
|
|
|
Думаю сделать domain просто набором байт до 64 байт. Система интерпретирует при внутреннем поиске этот набор не как строку, а как просто байты.
Что в эти байты пихать - юникод или ASCII - решать имплементаторам.
Если это доменное имя mydomain.dia.i2p, то domain здесь будет "mydomain". Регистратор должен положить этот домен в lowercase в базу. И искать домен нужно, предварительно преобразовав строку поиска в lowercase.
Ну это в общем выбор за неймспейсами и их днс клиентами.
|
|
|
|
Так ты хочешь для ВСЕХ неймспейсов сделать одинаковый TTL или для каждого свой ? Но для тестов мы пока используем как бы один неймспейс То есть TTL примерно один год в обычном выражении, так ? Я то хочу взять цену исходя из доходов в $  И сделать прогоны с разной нач ценой , скажем 5$/год , 10$/год и 15$/год Для всех одинаковый. Это возможно посчитать только учитывая все обратки: - воздействие спроса на price - воздействие оборота по DIANNA на курс USD/BTC то есть только на практике Дело здесь не в цене, а в обратных связях. Если они есть и правильные, цена найдет свое значение согласно спросу. Система должна правильно реагировать на изменения в активности. |
|
|
|
Теперь смотри. Иммитируем спонтанный фазовый переход системы. Допустим в районе блока 15000 с неймспейсом что то произошло и спрос резко упал, то есть блоки стали выходить стабильно реже. Как отреагирует система? Иммитация ситуации. После блока 15000 замедляем выход блоков. def set_time(b):
if b <= 1:
return 1370000000
if b < 15000:
return int(times[b-1] + winestim + random.randrange(-10, 90))
else:
return int(times[b-1] + winestim + random.randrange(200, 1000))
Результат: чекпоинт K новая_цена
13372 0.99902716676 0.0199641703093
15140 0.935328976233 0.0186730669768
16153 0.572426654024 0.0106889612499
17155 0.989222036231 0.0105737560128
18158 1.00095017004 0.010583802879
min & max prices were = 0.0105674481166 0.0199923549873
Спустя 1 чекпоинт цена адекватно просела и больше особо не изменялась! Блоки стали выходить гораздо реже. То что надо. http://pastebin.com/0091kP6R |
|
|
|
|
Пусть будет 42000 блоков.
Примерно год при нормальной активности.
Но у каждого неймспейса будет своя оптимальная частота блоков. То есть у одних это будет год, у других 10 лет... Непорядок =) Говорю ж, ттл надо в биткоин блоках считать. Раз уж у нас есть маппинг соответствия одних блоков другим...
Пусть тогда будет в биткоин блоках, 52560 (6x24x365).
|
|
|
|
Во. Пофиксил.
--- diatest.old 2012-03-09 10:12:03.000000000 +0200
+++ diatest 2012-03-09 10:56:24.178976763 +0200
@@ -9,8 +9,8 @@
winestim = 600
-check_prev = 0
-check_preprev = 0
+check_prev = 1
+check_preprev = 1
prices = []
checks = []
@@ -32,12 +32,12 @@
def reprice(h):
print "=====checkpoint @", h
- if h == 0:
+ if h <= 1:
return old_price
- if h == 2016:
+ if h <= 2017:
return old_price
- n_prev = h - check_prev
- n_preprev = check_prev - check_preprev
+ n_prev = h - check_prev - 1
+ n_preprev = check_prev - check_preprev - 1
if n_prev ==0 and n_preprev ==0:
return old_price/4
if n_prev == 0:
@@ -45,7 +45,7 @@
if n_preprev == 0:
return old_price * 4;
ts_prev = times[h-1] - times[check_prev]
- ts_preprev = times[check_prev] - times[check_preprev]
+ ts_preprev = times[check_prev-1] - 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
@@ -67,11 +67,11 @@
for x in range(0, last):
times.append(0)
-for z in range(0, last):
+for z in range(1, last):
times[z] = set_time(z)
# if z !=0:
# print "Block #",z," time=", times[z], "diff=", times[z]-times[z-1]
- if z < 2016:
+ if z < 2016 or (times[z] - times[1]) < 1209600:
continue
if ((z - check_prev) % 2016 == 0):
Результат: при равномерном распределении спроса (random) и стартовой цене 0.02, за 200к блоков min & max prices were = 0.0199220322999 0.0200676816951
checkpoints were :
[2016, 3907, 5800, 7692, 9586, 11486, 13373, 15262, 17154, 19048, 20941, 22834, 24727, 26623, 28515, 30409, 32301, 34193, 36088, 37980, 39867, 41759, 43651, 45539, 47432, 49321, 51212, 53102, 54992, 56885, 58777, 60667, 62562, 64455, 66347, 68239, 70131, 72025, 73913, 75804, 77695, 79586, 81478, 83367, 85260, 87153, 89043, 90934, 92824, 94714, 96606, 98494, 100386, 102276, 104167, 106059, 107950, 109842, 111737, 113630, 115522, 117414, 119306, 121200, 123090, 124985, 126876, 128766, 130657, 132548, 134438, 136333, 138226, 140121, 142012, 143904, 145797, 147690, 149583, 151476, 153369, 155262, 157153, 159046, 160937, 162828, 164721, 166609, 168503, 170396, 172287, 174176, 176067, 177960, 179855, 181745, 183635, 185525, 187419, 189312, 191200, 193091, 194982, 196875, 198770]
0.78% изменение за 4 года. Вполне себе ничего для рэнда. Удивительная стабильность в наше то время =) |
|
|
|
|
Рост цены в 10% за 4 года при псевдо-равномерном распределении я связываю с тем, что где то допущена ошибка в расчете блок-фрейма. Где то откуда то надо вычесть единицу в общем в индексе =)
|
|
|
|
Мои комментарии по поводу 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 |
|
|
|
А что ты вообще считаешь? Какие исходные данные? Какой первый блок? Сколько он генерируется? замена умножения на сложение приводит к плавному росту цены в облака Кгхм. Ну ессесно. К - это не цена, это нельзя добавлять. |
|
|
|
|
Show Posts
