Indeed, should at least get some rocking momentum going, though, perhaps enough to break the painful deadlock.
Momentum powered by newsletter. God damn speculants =) |
|
|
|
which makes a very clear recommendation for once  Yep, go ahead, buy. And leave your ass naked =) Once subscribers excited with this recommendation will run out of cash, something other will happen. Price didnt get to 5 and RSI is already 70. |
|
|
|
We just issued an interim bitcoin charts and bitcoin price forecast
Let me disagree. Where are the signals here for that conclusion?  This is nuts. I'll not take a part. |
|
|
|
Any answer to this? DIANNA Blocks are going to be WAY slower than bitcoin blocks. Even if half (which is probably a high guess) of the bitcoin network merge mines DIANNA, won't block time be worse than 20 minutes? Is this what you want? Maybe I'm just missing something.
Every namespace will have its own block appear time and yes, it will be higher than Bitcoin, as namespace will have always a bit higher difficulty than bitcoin. For example, users of potentional CJDNS namespace will be not so active as users of I2P, or users of Tor namespace. All them have their optimal activity and network adjusts block frequency and price to this activity. DIANNA is a domain system, not financial. I don't see problem of transaction approve time from 20 minutes to a hour. Modern ICANN domain registars process domain request from minutes to days. |
|
|
|
If you dont mind guys, I remind you, that namecoin is in alpha version, which is publically written on their website: Project Status
Status : usable, alpha stage
And NameCoin have a couple of general issues, which make the future of namecoin questionable. And developers are not able to fix them. https://bitcointalk.org/index.php?topic=62017.0If namecoin is a fork of bitcoin, this is not mean that it is so good as bitcoin. Watch what you are trading. I just aware. |
|
|
|
|
Когда происходит резкий скачек значения Fprev/Fpprev, то оно дальше не затухает. Идет "гармошкой": медленный-быстрый-медленный-быстрый и т.д.
Надо ввести затухающий фактор в это выражение.
|
|
|
|
Это естественно что шатает -- но это редкое событие раз в 210000 блоков
Но да можно формулы подкрутить чтобы переход был плавнее
Дело не в том что редкое. А в том, что его шатнуло раз и дальше пошел раскач. Незатухающий. Сейчас формула пересчета цены Fprev/Fpprev То есть, диана вычисляет ее из своего "виртуального времени" без привязки к реальности. Если мы будем считать Fprev/Fbitcoin, привязываясь, то это форсанет систему держать выход блоков в строгих рамках. Но активность в немспейсах может быть разная. А оно будет форсировать определенную активность. Таким образом, шатать в таком случае будет цену. Как быть? |
|
|
|
Я вообще сразу не заметил но вот это вот плохо  Шатает очень нехило. В правильном направлении, но нехило. Думаю дело не в pdiff, просто надо к какому то реальному показателю времени репрайсинг привязать. К степу например. |
|
|
|
|
Все таки, если в процессе происходит какой то фазовый сдвиг (Bounty 50 -> 25) например, система очень плохо стабилизируется, по графикам видно. С ценой то более-менее, а вот с остальным плохо - шатает во все стороны. В правильном направлении, но уж очень шатает.
И вообще, чет надоело мне в питоне это все считать и в маткад перекидывать. Счас буду в маткаде считать непосредственно.
|
|
|
|
Какая разница, какой 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
|
|
|
|
Also, immitation of Bitcoin block reward change from 50 to 25 BTC. How this will affect on DIANNA price? In a region of step 30000 change bounty to 25. bounty=50.0
for z1 in range(1, last):
if z1 == 30000:
bounty=25
#bla-bla
pdiff = domfee/(bounty + bitcom)
What happens with price?  Note, the price graph is based on example simulations. For real activity price can be different, but it is explicitely linked to network activity, so it has a feedback, so it will change to community expectations. |
|
|
|
Не вижу проблем с переходом на 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)
Что с ценой? |
|
|
|
|
Надо будет взять какой то подходящий и перепилить.
Вообще дхт можно пилить параллельно. Сначала то, что будет находиться в дхт, складывать в виде заглушки в локальную отдельную базу.
А когда появится дхт, просто эту базу каждый клиент туда сольет, освободив место.
|
|
|
|
|
Можно на экспоненте, только реальной какой то. Или просто наполнять буфер реальными данными неймкоин.
Ну и ожидание блока на час поменять.
Кодить думаю на яве. Там есть гугловский BitcoinJ и protobuf.
|
|
|
|
|
Ну можно еще погонять на другом спросе, на других ожиданиях кастомеров.
Ну а вообще по моему можно уже кодить. Мне надо только с текущей работой разгрестись.
|
|
|
|
|
Ты шагал блоками дианы, а я шагаю блоками биткоин - почти реальным временем.
TTL я думаю будет измеряться в блоках биткоин. У нас же есть соответствие.
|
|
|
|
And we have the first simulation of single namespace running with graphs! It includes dynamics graphs of: * Domain price * Block solving time * Miners profit * Number of handled transactions Please follow: http://dianna-project.org/wiki/Calc_1It illustrates how DIANNA looks for correct fee value and transaction commit time depending on namespace activity. |
|
|
|
Получается такое Шаг на графике - 10 минут. Т.е. если step=100, то это 1000 минут. step типа время. Время нахождения блока Транзакций на блок  Цена транзакции  Доход майнеров на блок  |
|
|
|
Так, корректировка. Значит спрос у нас будет такой: sqrt(5*x) Где x = шаг в 10 минут  Довольство клиентов будет измеряться более простой функцией good_price/price При good_price=1 вот такое довольство будет  Еще довольство будет зависеть от скорости выхода блоков. Ведь если блок выходит раз в неделю, то кому это надо, правильно? Допустим, 5 часов - терпимый промежуток выхода блоков 43200/blktime  Тогда функция спроса будет такая def num_domain_trans(step, prc, blktime):
return sqrt(5*step)*(start_price/prc)*(43200/blktime) ## changed coeff. 10 --> 2 !!!
Я чесно не подгоняю ничего, я просто ввожу какие то адекватные обратные связи вида 1/x Погоняем на другом спросе потом Значит эмулятор будет такой http://pastebin.com/HeP3kQKVПолучается вот что http://dianna-project.org/c/diaemu.log |
|
|
|
|
Show Posts
