Ukigo, сделай плз эти все вещи ) Я погляжу код и запустим эмулятор. Надеюсь я все учел. Не учел только влияние оборота дианы на курс биткоина. А оно будет.
Короче потом сэмулируем влияние на курс. Это тоже не сложно.
Topic: DIANNA: IANA Decentralized концепт дизайн - page 5. (Read 31411 times)
Ну и последнее, нам надо сэмулировать спрос. А вот тут сложнее.
Предположим что курс 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)
Но майнеры не могут принять прям все транзакции. Надо будет добавлять это количество транзакций в некий буфер ожидания. А из него по одной в блок и считать вероятность его появления по вышеуказанной формуле. Вероятность свершилась - вышел блок.
Предположим что курс 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)
Но майнеры не могут принять прям все транзакции. Надо будет добавлять это количество транзакций в некий буфер ожидания. А из него по одной в блок и считать вероятность его появления по вышеуказанной формуле. Вероятность свершилась - вышел блок.
@pent
Наваял сценарий на Питоне по формулам. Выводы :
1) не хватает формулы для ReqSum (трешхолда) -- как его вычислять ?
2) формула для цены домена дает среднюю за домен в последнем блоке DIANNA
а нужна формула определяющая цену домена для регуляции мощности сети.
3) нужны желательные начальные значения при виртуальном запуске сети
чтобы было от чего отталкиватся при тестировании формул.
4) похоже в некоторые формулы потребуется ввести некие коэффициенты
или какие-то довески.
5) PDiff minimal должна быть много больше твоей.
Наваял сценарий на Питоне по формулам. Выводы :
1) не хватает формулы для ReqSum (трешхолда) -- как его вычислять ?
2) формула для цены домена дает среднюю за домен в последнем блоке DIANNA
а нужна формула определяющая цену домена для регуляции мощности сети.
3) нужны желательные начальные значения при виртуальном запуске сети
чтобы было от чего отталкиватся при тестировании формул.
4) похоже в некоторые формулы потребуется ввести некие коэффициенты
или какие-то довески.
5) PDiff minimal должна быть много больше твоей.
Ну нормально =)
Надо ввести еще функцию жадности майнеров. Это какая то обратная парабола вероятности от 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, означающая что майнер запустить блок в сеть.
То есть, например на значениях 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 брать текущие, считать их константами.
И поехали. Добавляем транзакции в блоки, выпускаем блоки, делаем репрайс и т.п.
Таким образом мы сэмулируем поведение майнеров. Оно довольно предсказуемо =)
@rPman
Я понимаю -- такой домен гораздо круче чем "обычный" и должен на рынке стоить больше
но я считаю некую обоснованную миним. цену -- "себестоимость" -- чтобы понять
границы возможного по цене и объемам "готовой продукции"
Все эти расчеты -- весьма приближенные -- слишком много неизвестных
Я понимаю -- такой домен гораздо круче чем "обычный" и должен на рынке стоить больше
но я считаю некую обоснованную миним. цену -- "себестоимость" -- чтобы понять
границы возможного по цене и объемам "готовой продукции"
Все эти расчеты -- весьма приближенные -- слишком много неизвестных
Мой на Ы устарел. Этот почти верный, насколько я могу судить невыспавшимся мозгом.
Надо усложнять скрипт.
Ввести функцию создания блока. Она будет добавлять транзакции, считать общую их цену, вычислять PDiff. Время появления такого блока будет рассчитываться исходя из BitcoinDiff + PDiff*BitcoinDiff и текущего хешрейта сети биткоин (допустим он постоянный).
Когда складываем транзакции, для упрощения берем их цену из текущего блока.
Надо усложнять скрипт.
Ввести функцию создания блока. Она будет добавлять транзакции, считать общую их цену, вычислять PDiff. Время появления такого блока будет рассчитываться исходя из BitcoinDiff + PDiff*BitcoinDiff и текущего хешрейта сети биткоин (допустим он постоянный).
Когда складываем транзакции, для упрощения берем их цену из текущего блока.
Для централизованных IP сетей тоже будет полезно забить себе какой то namespace и объявить его как TLD .diana, как верно подметил rpMan.
Почему?
Потому что вот эта запись, которая будет храниться в DIANNA:
вообщето сейчас эта запись хранится на рутовых корневых серверах IANA/ICANN. И все эти сервера расположены в США. Лишь зеркала по миру раскиданы.
В последнее время до амеров начало доходить, что эти сервера вообще то стоят у них и они имеют власть затереть любую такую запись на основании SOPA/PIPA запроса. Мол, сайт что то там нарушает.
Явный пример беспредела:
http://www.megaupload.com/
Зайдите и убедитесь что может быть с каждым сайтом.
Так вот нехер хранить такие записи на центральных серверах =)
Конечно, по IP могут прикрыть, но можно ведь переехать. Домен то не потеряешь - он в цепи DIANNA. А там его не так то просто выпилить.
Но вообще всю эту кашу я специально для I2P заварил =) Там реально ТруЪ получится.
Почему?
Потому что вот эта запись, которая будет храниться в DIANNA:
Code:
@ IN NS ns1.hosting.com. ; @ IN NS ns2.hosting.com.;
вообщето сейчас эта запись хранится на рутовых корневых серверах IANA/ICANN. И все эти сервера расположены в США. Лишь зеркала по миру раскиданы.
В последнее время до амеров начало доходить, что эти сервера вообще то стоят у них и они имеют власть затереть любую такую запись на основании SOPA/PIPA запроса. Мол, сайт что то там нарушает.
Явный пример беспредела:
http://www.megaupload.com/
Зайдите и убедитесь что может быть с каждым сайтом.
Так вот нехер хранить такие записи на центральных серверах =)
Конечно, по IP могут прикрыть, но можно ведь переехать. Домен то не потеряешь - он в цепи DIANNA. А там его не так то просто выпилить.
Но вообще всю эту кашу я специально для I2P заварил =) Там реально ТруЪ получится.
Ok. Пусть 1BTC == 3200USD и уже дают 25BTC/block. Тогда :
0.0027BTC / domain * 3200 == 8.64$ / domain ( при 100000 нов. регов в день )
или 300000 новых регов/день по цене 2.88$
при 300000 нов. регов/день догнать ICANN можно за 1.5 года
при 100000 -- соответ. за 4.5 года
Это уже лучше
<-- есть что делить участникам сети DIANNA
---------------------------------------------------------------------------------------------
При 100$/BTC имеем : домен стоит 27 центов при 100000 нов. регов
или 10000 нов. регов в день по цене 2.7$ => ~3650000 нов. доменов в год
чтобы догнать ICANN потребуется ~ 25 - 38 ЛЕТ
--------------------------------------------------------------------
--------------------------------------------------------------------
Итого при удачных раскладах для Bitcoin этим имеет смысл
заниматься -- у системы есть экономическое будущее
0.0027BTC / domain * 3200 == 8.64$ / domain ( при 100000 нов. регов в день )
или 300000 новых регов/день по цене 2.88$
при 300000 нов. регов/день догнать ICANN можно за 1.5 года
при 100000 -- соответ. за 4.5 года
Это уже лучше
<-- есть что делить участникам сети DIANNA---------------------------------------------------------------------------------------------
При 100$/BTC имеем : домен стоит 27 центов при 100000 нов. регов
или 10000 нов. регов в день по цене 2.7$ => ~3650000 нов. доменов в год
чтобы догнать ICANN потребуется ~ 25 - 38 ЛЕТ
--------------------------------------------------------------------
--------------------------------------------------------------------
Итого при удачных раскладах для Bitcoin этим имеет смысл
заниматься -- у системы есть экономическое будущее
О формате представления данных в базе 'имя -> информация о домене' есть какие-то наработки? может что готовое?
Для обычных доменов как минимум нужна поддержка метасимвола * (*.mydomain.diana), много IP на домен (плюс географическая привязка), в т.ч. алиасы в другие сети/цепочки... может еще что, я просто не в курсе в текущих веяниях DNS в Интернет.
Для обычных доменов как минимум нужна поддержка метасимвола * (*.mydomain.diana), много IP на домен (плюс географическая привязка), в т.ч. алиасы в другие сети/цепочки... может еще что, я просто не в курсе в текущих веяниях DNS в Интернет.
Если ты имеешь в виду семантику
http://dianna-project.org/wiki/Namespace
Это тоже дело имплементаторов - что туда пихать и в каком формате.
Конкретно для твоего случая отвечаю.
Допустим, TLD .diana соответствует неймспейс 100. Есть какая то страничка в вики для этого неймспейса с RFC-подобным описанием, что именно и в каком формате должно содержаться в
Ладно, не буду грузить вариантами, перейду к конкретике. Значит в этом неймспейсе домен mydomain.diana будет иметь имя "mydomain".
Я так понимаю, если речь идет об централизованном IP, то будет использоваться традиционная схема DNS. А значит домен "mydomain" будет иметь
Code:
@ 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" и значением:
Code:
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 =)Это будет бомба. Форк Интернет без контроля и границ. Никто не сможет вычислить и закрыть сайт, а серфинг по таким сайтам станет удобным и понятным. Полная криптоанархия!
О формате представления данных в базе 'имя -> информация о домене' есть какие-то наработки? может что готовое?
Для обычных доменов как минимум нужна поддержка метасимвола * (*.mydomain.diana), много IP на домен (плюс географическая привязка), в т.ч. алиасы в другие сети/цепочки... может еще что, я просто не в курсе в текущих веяниях DNS в Интернет.
Для обычных доменов как минимум нужна поддержка метасимвола * (*.mydomain.diana), много IP на домен (плюс географическая привязка), в т.ч. алиасы в другие сети/цепочки... может еще что, я просто не в курсе в текущих веяниях DNS в Интернет.
Не , не странно
Это лишь одна из прикидок , чтобы понять что к чему.
То есть цена 2 - 3 $ за домен тебя устроит ? ( 8/3 == 2.67USD)
Щас подумаю и посчитаю что будет при 1BTC == 3200USD
Типа fair value если все мобильные платежи на Земле проводить через Биткойн.
Это лишь одна из прикидок , чтобы понять что к чему.
То есть цена 2 - 3 $ за домен тебя устроит ? ( 8/3 == 2.67USD)
Щас подумаю и посчитаю что будет при 1BTC == 3200USD
Типа fair value если все мобильные платежи на Земле проводить через Биткойн.
Думаю сделать domain просто набором байт до 64 байт. Система интерпретирует при внутреннем поиске этот набор не как строку, а как просто байты.
Что в эти байты пихать - юникод или ASCII - решать имплементаторам.
Если это доменное имя mydomain.dia.i2p, то domain здесь будет "mydomain". Регистратор должен положить этот домен в lowercase в базу. И искать домен нужно, предварительно преобразовав строку поиска в lowercase.
Ну это в общем выбор за неймспейсами и их днс клиентами.
Что в эти байты пихать - юникод или ASCII - решать имплементаторам.
Если это доменное имя mydomain.dia.i2p, то domain здесь будет "mydomain". Регистратор должен положить этот домен в lowercase в базу. И искать домен нужно, предварительно преобразовав строку поиска в lowercase.
Ну это в общем выбор за неймспейсами и их днс клиентами.
Так ты хочешь для ВСЕХ неймспейсов сделать одинаковый TTL или для каждого свой ?
Но для тестов мы пока используем как бы один неймспейс
То есть TTL примерно один год в обычном выражении, так ?
Я то хочу взять цену исходя из доходов в $
И сделать прогоны с разной нач ценой , скажем 5$/год , 10$/год и 15$/год
Но для тестов мы пока используем как бы один неймспейс
То есть TTL примерно один год в обычном выражении, так ?
Я то хочу взять цену исходя из доходов в $
И сделать прогоны с разной нач ценой , скажем 5$/год , 10$/год и 15$/год
Для всех одинаковый.
Это возможно посчитать только учитывая все обратки:
- воздействие спроса на price
- воздействие оборота по DIANNA на курс USD/BTC
то есть только на практике
Дело здесь не в цене, а в обратных связях. Если они есть и правильные, цена найдет свое значение согласно спросу. Система должна правильно реагировать на изменения в активности.
@rPman
Именно "ничего не принимая на веру" -- все трудность тут в том
как сделать формулы которые бы защищали систему от максим. возможного
числа неприятностей и при этом чтобы участники системы могли бы как миним.
не работать себе в убыток.
В каких границах по вашему должна быть цена домена
минимум и максимум ?
Чтобы это было экономически обосновано ?
Именно "ничего не принимая на веру" -- все трудность тут в том
как сделать формулы которые бы защищали систему от максим. возможного
числа неприятностей и при этом чтобы участники системы могли бы как миним.
не работать себе в убыток.
В каких границах по вашему должна быть цена домена
минимум и максимум ?
Чтобы это было экономически обосновано ?
Теперь смотри. Иммитируем спонтанный фазовый переход системы.
Допустим в районе блока 15000 с неймспейсом что то произошло и спрос резко упал, то есть блоки стали выходить стабильно реже. Как отреагирует система?
Иммитация ситуации. После блока 15000 замедляем выход блоков.
Результат:
http://pastebin.com/0091kP6R
Допустим в районе блока 15000 с неймспейсом что то произошло и спрос резко упал, то есть блоки стали выходить стабильно реже. Как отреагирует система?
Иммитация ситуации. После блока 15000 замедляем выход блоков.
Code:
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))
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))
Результат:
Code:
чекпоинт 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 чекпоинт цена адекватно просела и больше особо не изменялась! Блоки стали выходить гораздо реже. То что надо.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
http://pastebin.com/0091kP6R
@pent
Вот статистика по обычным доменам за посл. сутки :
новые реги = 179,822 истекло = 148,447 передача в др. руки = 196,898
-------------------------------------------------------------------------------------------------------------------------------------------
представим себе что у DIANNA объемы такие : новые реги = 100000
и столько же трансферов. В сутки. Это разумная оценка возм. объемов
с учетом всемирной Депрессии.
Из твоих прежних расчетов по обороту денег за доменные операции :
15% от 50 BTC/Block * 144 == 1080 BTC
то есть 540 BTC стоят 100000 новых регистраций доменов
Итого 1 домен стоит 0.0054 BTC или 2.6 цента ))
в среднем
Или вдвое меньше после перехода на 25 BTC/block )
Хватит ли этой суммы чтобы покрыть расходы майнеров/регистраторов ??
-----------------------------------------------------------------------------------------------------------------
Отсюда следует :
или конкуренция с ICANN невозможна при текущем курсе BTC/USD
или я где то облажался при расчетах, тогда где ?
Если все здесь верно -- то имеем или слишком мало доменов при более
высокой цене -- то есть нечего раздавать
или никто не будет обслуживать домены -- потому что это не выгодно
Сколько по твоему может стоить хранение 1 домена ?
Должно быть дешевле продажной цены -- иначе это не капитализм
Или другой вопрос :
как повысить суточный оборот денег за доменные операции ?
Раз в 200 ?
Вот статистика по обычным доменам за посл. сутки :
новые реги = 179,822 истекло = 148,447 передача в др. руки = 196,898
-------------------------------------------------------------------------------------------------------------------------------------------
представим себе что у DIANNA объемы такие : новые реги = 100000
и столько же трансферов. В сутки. Это разумная оценка возм. объемов
с учетом всемирной Депрессии.
Из твоих прежних расчетов по обороту денег за доменные операции :
15% от 50 BTC/Block * 144 == 1080 BTC
то есть 540 BTC стоят 100000 новых регистраций доменов
Итого 1 домен стоит 0.0054 BTC или 2.6 цента ))
в среднем
Или вдвое меньше после перехода на 25 BTC/block )
Хватит ли этой суммы чтобы покрыть расходы майнеров/регистраторов ??
-----------------------------------------------------------------------------------------------------------------
Отсюда следует :
или конкуренция с ICANN невозможна при текущем курсе BTC/USD
или я где то облажался при расчетах, тогда где ?
Если все здесь верно -- то имеем или слишком мало доменов при более
высокой цене -- то есть нечего раздавать
или никто не будет обслуживать домены -- потому что это не выгодно
Сколько по твоему может стоить хранение 1 домена ?
Должно быть дешевле продажной цены -- иначе это не капитализм
Или другой вопрос :
как повысить суточный оборот денег за доменные операции ?
Раз в 200 ?
Пусть будет 42000 блоков.
Примерно год при нормальной активности.
Но у каждого неймспейса будет своя оптимальная частота блоков. То есть у одних это будет год, у других 10 лет... Непорядок =) Говорю ж, ттл надо в биткоин блоках считать. Раз уж у нас есть маппинг соответствия одних блоков другим...
Пусть тогда будет в биткоин блоках, 52560 (6x24x365).
Примерно год при нормальной активности.
Но у каждого неймспейса будет своя оптимальная частота блоков. То есть у одних это будет год, у других 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к блоков
http://pastebin.com/8UDWrXfp
0.78% изменение за 4 года. Вполне себе ничего для рэнда. Удивительная стабильность в наше то время =)
Code:
--- 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к блоков
Code:
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]
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]
http://pastebin.com/8UDWrXfp
0.78% изменение за 4 года. Вполне себе ничего для рэнда. Удивительная стабильность в наше то время =)
Все еще хуже на самом деле )
Какая бы не была мат. конструкция -- ловящая цену домена
или трудность или еще какая ...
Если игра пойдет по-крупному -- в масштабах ICANN
то формулы должны защищать DIANNA не только
от жадных майнеров и нечестных регистраторов
но и от злонамеренных атакующих с большими деньгами
которые готовы выбросить на ветер изрядную сумму лишь бы уронить
систему -- это может быть что угодно
можно например загнать цену домена как можно выше и там держать
да мало ли что можно придумать ...
вот в Европе счас кризис и за последние 3 мес на него вылит уже
1 триллион EUR -- они не жалеют чужих денег -- когда дело серьезно.
а это примерно те же люди что могут атаковать DIANNA не из жадности.
Какая бы не была мат. конструкция -- ловящая цену домена
или трудность или еще какая ...
Если игра пойдет по-крупному -- в масштабах ICANN
то формулы должны защищать DIANNA не только
от жадных майнеров и нечестных регистраторов
но и от злонамеренных атакующих с большими деньгами
которые готовы выбросить на ветер изрядную сумму лишь бы уронить
систему -- это может быть что угодно
можно например загнать цену домена как можно выше и там держать
да мало ли что можно придумать ...
вот в Европе счас кризис и за последние 3 мес на него вылит уже
1 триллион EUR -- они не жалеют чужих денег -- когда дело серьезно.
а это примерно те же люди что могут атаковать DIANNA не из жадности.
Рост цены в 10% за 4 года при псевдо-равномерном распределении я связываю с тем, что где то допущена ошибка в расчете блок-фрейма. Где то откуда то надо вычесть единицу в общем в индексе =)
Jump to: