So. I decided do not complicate system with any contracts procedures. If anyone scaried to loose his money during name update, he can consider using escrow services. The current 1.6 rawhide preview is almost on track. This design looks perfect. Does anyone see the vulnerabilities in it? So, here is the DIANNA internals with bunch of tech details: The Block Chain TreeNamespacesBlockTransactionFees: 1 2Retargeting RepricingNo independent DifficultyAnd Merged Mining Implementation |
|
|
|
|
Файлы шифруются утилитой gpg
|
|
|
|
|
Цена сдирается за полный или неполный килобайт, точнее 1000 байт. А пдифф считается по сумме таких сдираний.
Цена операции равна прайсу в простом случае, когда значение не больше килобайта.
|
|
|
|
Очередное изменение, ногами не бить  Формула цены не была окончательной Репрайсинг теперь происходит базируясь не на частоте блоков биткоин, а на пред-предыдущей частоте блоков DIANNA. То есть базируясь на частоте двух последних чекпоинтов репрайсинга. По этому цена гуляет в какую хош сторону и ищет свое значение, значение PDiff и частоту блоков, которая бы устроила данный неймспейс. Во! http://dianna-project.org/wiki/Repricing_procedureЕсли в цепи не было активности в течении последнего "bitcoin-года", цепь уничтожается. Это реально ТруЪ получился. Каждый неймспейс будет иметь свой адекватный прайс, и свою адекватную частоту появления блоков. |
|
|
|
1. Do not use VPS or Cloud hostings - only pure hardware. VPS and Cloud hosts have several ways to get staff login to your server without a password and without rebooting server. But even on pure hardware there is always a way to reset a root password when staff have access on console. Because of this: 2. Keep your wallet on crypted partitions. Use kernel-level partition encryption LUKS on Linux and ELI on FreeBSD. When server crashed or rebooted, on next boot crypted partition can not be mounted without entering a password. VPS and Clouds provide a theoretical fault-tolerance and safety of your data. So when you use a stand-alone server there is always small chance that HDD can be damaged causing loosing a wallet. So you need a backup to external host. If external backup host in a same DC, the chances of loosing both at ones - main and backup server - are high. So... 3. Do not keep main bitcoind host and backup host in a same datacenter.You also need to be sure your backups go through secure channel, So 4. Use secure protocols to make an external backup. Such as SSH (scp).Even if you backup your data via secure protocol, there always a chance that someone will get into the backup server and steal them. If you do not want to complicate the backup server setup: 5. Encrypt backup files on creation with gpg-like standard unix utility. And then send them to backup host via secure channel.This will let you use cheap untrusted VDS and Cloud services for backup purposes. And finally, you have to restrict most ways to get your hosts to be compromised. 6. There must be no applications running that listens network except bitcoind and sshd on main server, and sshd only on backup server.PS. I don't say about complex passwords and pubkey ssh authorization, I assume people understand this. Also you may consider restrict ssh access by IP. But dont try too hard, you can restrict yourself
|
|
|
|
Не используйте VDS и облачные сервисы для работы внешнего демона bitcoin, если вам дороги средства, которые вы там собираетесь держать. Потому как в подобных сервисах есть масса возможностей для администрации зайти в консоль не зная никаких паролей. А то одни уже лоханулись на 40к BTCТолько нативное железо! Только на криптованных разделах размещать кошельки! (LUKS - Linux, ELI - FreeBSD) Если делаете бекап кошелька, этот файл обязательно должен быть зашифрован стандартной утилиткой gpg (если кошелек не зашифрован). |
|
|
|
|
Я подумал, а может же быть DDoS такой, что один майнер будет майнить по 1 транзакции на почти минимальной сложности биткоина и может завысить цену до потолка, не теряя ничего при этом? Может.
А мы тогда будем привязывать блок дианы не к предыдщему PARENT блоку, а непосредственно к нему.
То есть, PARENT блок Bitcoin должен быть включен в официальную цепь bitcoin. Только тогда блок DIANNA будет принят системой.
Сложность DIANNA всегда больше сложности Bitcoin. Значит любой подошедший PARENT-блок биткоин имеет немало шансов попасть в мейнстрим. Это еще больше повышает безопасность системы.
Это уравнивает шансы пуллов согласно их хешрейтам, а чтобы заспамить диану, надо чтобы сеть bitcoin принимала каждый блок пулла. А это практически невозможно.
|
|
|
|
Время в блоках -- это разумно
Дык я и не шучу -- не стоит беспокоится слишком много о курсе к $
через пару лет в Америке все равно дефолт будет
завтра понастраиваю свою беду
может у тебя еще какие варианты формулы цены есть ?
я бы их заодно попробовал
За курс точно не стоит беспокоиться, т.к. есть обратная связь. Если курс подскочил, получается подскочила и цена. Клиенты сказали "данунах" и спрос упал. Значит упало количество блоков в промежуток времени. Значит, цена будет вскоре пересчитана в меньшую сторону. И наоборот. Так что обратка есть, все нормально. Вариант формулы изменения цены окончательный. Может еще просто лимиты K подправить надо будет. Сейчас 0.25 <= K <= 4 http://dianna-project.org/wiki/Domain_Transaction_Fee |
|
|
|
|
Время в блоках, цены в коинах. Да. А как по другому?
|
|
|
|
|
Мне кажется ты зря мучаешься с эмуляцией биткоин цепи. В биткоин итак все понятно. 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 минут на одинаковой сложности. Тогда расчет какой то вменяемый получится. Обратные связи в системе скомпенсируют эти допущения в реале.
|
|
|
|
Формат блока при Merged Mining расширен. То есть некоторые блоки NameCoin содержат в себе еще Header-ы Bitcoin-блоков
Ну так я ж написал При этом к AUX блоку цепляется куча левой инфы для верификации:
а) Меркль ветка AUX блока в AUX Tree
б) Индекс а) в AUX Tree (зачем, если ветка есть?)
в) Нулевая транзакция биткоин в найденом блоке, конкретно интересует ее scriptSig с рутом AUX Tree.
г) Меркль ветка предыдущего пункта в дереве Bitcoin блока
д) Хидер блока биткоин непонятно где здесь это дерево хранится. |
|
|
|
|
Ну коли охота трахаться с uint256, то валяй =)
|
|
|
|
|
Пару слов о сложности. Difficulty, это просто такая мера величины для прикида на глаз, т.к. это дабл. А дабл значение не может быть точно выражено в процессорном понимании.
Биткоин оперирует понятием таргет. Это uint256.
Для простоты понимания таргета был введен difficulty=maxtarget/target
Но для тестовых расчетов всяких там ожиданий difficulty годится. Не годится в боевом коде.
Считай мощности биткоин и дианы равны. Как будто оба обладают одинаковыми мощностями. Мержед это предоставляет.
|
|
|
|
это даже проще для меня А как тогда выразить среднее ожидаемое время нахождения блока дианы в секундах ? среднее время нахождения блока биткойна я считаю у себя так : time = difficulty * 2**32 / hashrate*10**9 то есть трудность и хэшрейт относятся к предыдущему блоку, а время исп. уже для текущего Представь что сложность берется из текущего биткоин блока. Это почти одно и тоже. Но диана добавляет к этой сложности еще PDiff %. То есть если Difficulty = 10**6, а PDiff насчитали на 0.1, то блок дианы считается по сложности (10**6 + 10**5), т.е. DiannaDifficulty=Difficulty*(1+Pdiff) |
|
|
|
Тогда значит примерно алгоритм 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;
|
|
|
|
А вот теперь правильно, в интегрально-дружелюбном исчислении. Возьмем время, за которое биткоин вычисляет 2016 блоков как tsBase Возьмем время, за которое дианна вычисляет 2016 блоков как ts Тогда коэффициент K будет выражен как K=tsBase/(ts-tsBase) График функции K(ts). K становится меньше с возрастанием ts и не позволяет ts достигнуть tsBase (1.21E6)  ts так же можно выразить через частоту блоков в час, если принять биткоиновские данные константами: F=2016*3600/ts Это облегчает восприятие предыдущего графика функции. Тогда зависимость K от частоты выхода блоков дианы будет такая:  |
|
|
|
|
Show Posts
