pent (OP)
|
|
March 10, 2012, 05:57:32 AM |
|
Ну можно еще погонять на другом спросе, на других ожиданиях кастомеров.
Ну а вообще по моему можно уже кодить. Мне надо только с текущей работой разгрестись.
|
|
|
|
|
|
|
|
In order to get the maximum amount of activity points possible, you just need to post once per day on average. Skipping days is OK as long as you maintain the average.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
pent (OP)
|
|
March 10, 2012, 06:10:10 AM |
|
Можно на экспоненте, только реальной какой то. Или просто наполнять буфер реальными данными неймкоин.
Ну и ожидание блока на час поменять.
Кодить думаю на яве. Там есть гугловский BitcoinJ и protobuf.
|
|
|
|
pent (OP)
|
|
March 10, 2012, 06:27:52 AM |
|
Надо будет взять какой то подходящий и перепилить.
Вообще дхт можно пилить параллельно. Сначала то, что будет находиться в дхт, складывать в виде заглушки в локальную отдельную базу.
А когда появится дхт, просто эту базу каждый клиент туда сольет, освободив место.
|
|
|
|
pent (OP)
|
|
March 10, 2012, 08:51:42 AM |
|
Не вижу проблем с переходом на Bounty=25 BTC В районе шага 30к переходим на 25 BTC bounty=50.0
for z1 in range(1, last): if z1 == 30000: bounty=25 #bla-bla pdiff = domfee/(bounty + bitcom)
Что с ценой?
|
|
|
|
pent (OP)
|
|
March 10, 2012, 09:30:24 AM |
|
Какая разница, какой bounty, какой trfee, какая стартовая цена? Да любой может быть. Стартовую цену можно только прикинуть, даже с большой погрешностью. Как видно из графика, она стремится к ожиданиям общественности. Я вот думаю, удовлетворенность клиентов временем выхода блока нужно считать не по этой формуле 43200/blktime А по чето вроде 1 if blktime < expected_blocktime 2**(1 - blktime/expected_blocktime) else
То есть, если блоки выходят с временем < ожидаемого, то все впорядке. А если больше, начинается экспоненциальное падение спроса. Прально я говорю? А то предыдущая формула спрос взвинтила только потому что блоки выходят чаще чем требуется. def num_domain_trans(step, prc, blktime): k1=1.0*(start_price/prc) k2=1.0 if (blktime > 43200): k2=2**(1 - blktime/43200); return sqrt(5*step)*k1*k2
|
|
|
|
pent (OP)
|
|
March 10, 2012, 10:08:52 AM |
|
Все таки, если в процессе происходит какой то фазовый сдвиг (Bounty 50 -> 25) например, система очень плохо стабилизируется, по графикам видно. С ценой то более-менее, а вот с остальным плохо - шатает во все стороны. В правильном направлении, но уж очень шатает.
И вообще, чет надоело мне в питоне это все считать и в маткад перекидывать. Счас буду в маткаде считать непосредственно.
|
|
|
|
pent (OP)
|
|
March 10, 2012, 10:24:24 AM |
|
Я вообще сразу не заметил но вот это вот плохо Шатает очень нехило. В правильном направлении, но нехило. Думаю дело не в pdiff, просто надо к какому то реальному показателю времени репрайсинг привязать. К степу например.
|
|
|
|
pent (OP)
|
|
March 10, 2012, 11:03:18 AM |
|
Это естественно что шатает -- но это редкое событие раз в 210000 блоков Но да можно формулы подкрутить чтобы переход был плавнее
Дело не в том что редкое. А в том, что его шатнуло раз и дальше пошел раскач. Незатухающий. Сейчас формула пересчета цены Fprev/Fpprev То есть, диана вычисляет ее из своего "виртуального времени" без привязки к реальности. Если мы будем считать Fprev/Fbitcoin, привязываясь, то это форсанет систему держать выход блоков в строгих рамках. Но активность в немспейсах может быть разная. А оно будет форсировать определенную активность. Таким образом, шатать в таком случае будет цену. Как быть?
|
|
|
|
pent (OP)
|
|
March 10, 2012, 12:00:38 PM |
|
Когда происходит резкий скачек значения Fprev/Fpprev, то оно дальше не затухает. Идет "гармошкой": медленный-быстрый-медленный-быстрый и т.д.
Надо ввести затухающий фактор в это выражение.
|
|
|
|
pent (OP)
|
|
March 11, 2012, 12:11:55 PM |
|
Да полностью левый эмулятор. Я его гоняю, поражаюсь.
То что цену шатало, это я пофиксил. Там формула Fprev/Fpprev, Только Fpprev это частота двух последних чепоинтов, а Fprev - частота только последнего. Тогда нормально затухает.
При чем функция затухания зависит от k_max (макс изменения цены). Сейчас 1/k_max < k < k_max, k_max=4. Это значение должно быть больше двух (Fprev/Fpprev), чтобы затухание шло и цена стабилизировалась.
Так же k_max/2 определяет, насколько резкий скачок параметров за чекпоинт система способна адекватно пережевать. Если параметры скачут быстрее чем k_max/2 каждый чекпоинт, то начинаются чудеса. Если же параметры скакнули хоть в 10 раз, но однажды, то жрет нормально.
Соответственно, чем больше k_max, тем лучше система справляется с резкими переходами. Однако изменение цены в 10 раз, например, это вам не здрасте.
Где золотая середина?
Эмулятор очень кривой.
1. Не умеет работать с ситуациями, когда спроса вообще нет 2. Находит блоки с 0 транзакциями 3. Вот эта гребенка на предыдущем графике - создается им же, т.к. бешеное количество транзакций обрушивается на блок внезапно раз в 600 секунд
|
|
|
|
pent (OP)
|
|
March 11, 2012, 12:33:32 PM Last edit: March 11, 2012, 12:47:14 PM by pent |
|
Я даже на перле его переписал, все не то.
оффтоп
Настроение херня, на бирже сегодня не повезло.
|
|
|
|
pent (OP)
|
|
March 11, 2012, 12:41:23 PM |
|
По-моему лучше сначала встроить туда автоматическое изменение баунти как оно должно идти 50 25 12.5 и т.д. адаптировать формулы чтобы система справлялась с изменением баунти достойно а потом уже добавлять устойчивость ко всяким тяжелым ситуациям так оно будет проще и быстрей
С баунти нормально он справляется. Дело не в этом. А в том, что процесс выхода блоков несовершенный. Не так он эмулирует, как в реале будет происходить. На майнера транзакции раз в 600 секунд не обрушиваются. Наверно надо буфер убрать. И формулу К новую я озвучил.
|
|
|
|
pent (OP)
|
|
March 12, 2012, 02:56:58 PM Last edit: March 12, 2012, 03:17:38 PM by pent |
|
Цены нельзя фиксировать на цифрах. Все может меняться, при чем кардинально. Цену надо фиксировать только на работу. А это делает формула PDiff.
Количество транз тоже нельзя фиксировать. Система подстраивается под них с помощью репрайса.
Вообще ничего нельзя фиксировать. Ну разве что вот K_min/K_max, который не позволит расшатать систему какими то резкими фазовыми переходами.
Я не вижу изъяна в формулах. Я вижу изъян в эмуляторе =) Все происходить будет совсем не так. И то эмулятор показывает правильные тренды.
Все эти курсы и баунти - это все неважно. Цена завязана на значение цена/работа с кучей правильных обраток. А значит диана найдет цену, которая удовлетворит людей.
Атака на диану практически невозможна. Разве что на неймспейсы с крайне низкой активностью, которые хотят домены менеджить почти на халяву.
Поскольку Диана требует от каждого блока присутствия парента в менйстриме биткоин, чтобы серъезно нагрузить неймспейс Дианы, надо обладать серъезной мощностью от 30% биткоина. И то, это длительный и неблагодарный труд с непонятными перспективами. Не лучше уж использовать его во благо, в прямой себе профит?
Неймспейсы уязвимы к атакам на начале. Да. Но вообще то их 4 миллиарда, а столько неймспейсов 1 клиент обслуживать и мониторить не в состоянии. 1 неймспейс это минимум 10 TCP сессий. Памяти не хватит даже у хорошего компа чтобы видеть что происходит хотя бы в тысяче неймспейсов.
Собрался народ, решил открыть неймспейс. Собрали денег, заплатили майнеру, он высчитал первый блок по 2х сложности. Если плохой дядька с большой мощностью узнал номер этого нейспейса и решил напакостить, он это будет делать долго. А пока он это делает, можно забить другой неймспейс пока злой дядька сражается с мельницами =)
Намайнить миллиард транзакций? Удачи. Каждый блок должен иметь парента в мейнстриме биткоин. Значит майнер может намайнить столько блоков дианы от общего числа, сколько у него мощности от общей мощности биткоин.
В количествах транзакций на блок майнер тоже ограничен. Цена в блоке фиксирована. Чем больше сумма транзакций, тем больше PDiff, тем больше время расчета блока. Я не знаю, сколько майнер будет считать хотя бы миллион транзакций на начале. Очень долго =) Достаточно долго, чтобы народ увидел что неймспейс засран и свалил в другой неймспейс. А значит все труды майнера в /dev/null.
|
|
|
|
rPman
Legendary
Offline
Activity: 1120
Merit: 1069
|
|
March 12, 2012, 03:20:29 PM |
|
Еще смешная идея выкристаллизовалась - создатель неймспейса определяет формулу (формула определяется в корневом блоке).
Ошиблись, после развития системы в формулах.. не стоит ломать и корежить исходники заглушками if(nuBlock>23456) doNewCoolFormula(...), а просто сдеали форк в соседний неймспейс (ну это я загнул).
|
|
|
|
pent (OP)
|
|
March 12, 2012, 03:24:27 PM |
|
Формулу репрайса и pdiff на скриптовом языке? ) Хм =)
|
|
|
|
pent (OP)
|
|
March 12, 2012, 03:49:17 PM |
|
Биткоин никоим образом не обеспечивает безубыточность работы майнеров. И ничо.
|
|
|
|
rPman
Legendary
Offline
Activity: 1120
Merit: 1069
|
|
March 13, 2012, 06:56:07 AM |
|
В чем заключается атака на неймспейс? данные хранятся в DHT - на узлах памяти требуется логарифм, запарятся атаковать, обрабатывать неймспейс - добровольное дело каждого майнера, желаешь обрабатывать - вперед
|
|
|
|
pent (OP)
|
|
March 13, 2012, 08:11:26 AM Last edit: March 13, 2012, 08:27:47 AM by pent |
|
В чем заключается атака на неймспейс? данные хранятся в DHT - на узлах памяти требуется логарифм, запарятся атаковать, обрабатывать неймспейс - добровольное дело каждого майнера, желаешь обрабатывать - вперед
Наиболее вероятная атака - атака на повышение цены. Просто сидеть и майнить блоки неймспейса, пусть с одной транзакцией, до посинения. Однако: 1. Возможности атакующего ограничены его хешрейтом по отношению к хешрейту биткоин. Каждый его намайненый блок должен иметь реального парента в цепи биткоин. Чтобы реально насрать, надо иметь 100% мощности сети биткоин. 2. В таком случае частота блоков скакнет на величину прироста частоты блоков при следующем репрайсе (макс в 4 раза), т.е. примерно на отношение паразитной активности к активности неймспейса 3. Однако и останется на этом уровне после этого. Чтобы еще раз ее повысить в 4 раза при следующем репрайсе, надо будет увеличить свою же мощность в 4 раза. 4. Цена начнет приспосабливаться к текущим реалиям, постепенно снижаясь до приемлемого в неймспейсе значения. Атакующий грызет локти. 5. Когда атакующего попустит, будет обратный скачок в другую сторону, после чего цена опять вернется на приемлемые значения. Sybil атака на дхт я думаю не будет возможна, т.к. метаданные дхт (хидеры) хранятся у каждого.
|
|
|
|
pent (OP)
|
|
March 13, 2012, 10:17:03 AM |
|
Надеюсь он все таки появится.
Пока звезды не складываются у меня в сторону кодинга в ближайшие пару недель.
|
|
|
|
pent (OP)
|
|
March 13, 2012, 01:15:33 PM |
|
Кто нибудь может запустить IRC бота нормального на канал #dianna @freenode?
Надо нормальный канал сделать и там общаться. А то топ уже вырос.
|
|
|
|
|