Не, PDiff=0 это деление на ноль в формулах. Не канает. Надо задать минимальный PDiff.

А минимальный PDiff это минимальная цена (квант биткоин) в одной транзакции. То есть

Ага, спасибо

Ну вроде как через 2016. Но для первых блоков можно и ограничиться, например, сотней И не вижу ничего плохого в этом кстати.

Если майнер открывает свой неймспейс и начинает там регать бесплатно домены, пока есть халява, то:
1) Домены все таки когда то проекспайрятся
2) Помимо майнера, должен еще кто то быть заинтересован в этом неймспейсе, чтобы хранить весь этот хлам. Иначе он будет хранить его сам.

У тебя мозги очень правильно стоят Всегда спрашиваешь правильные вещи


Ну да, получается, да. Поскольку цепи неймспейсов изолированы, из одного биткоин блока может появиться одновременно два блока разных неймспейсов. Более того, может даже получиться два блока одного неймспейса. Маловероятно, но может, правильно?

Тогда надо делать доп. проверку if (PDiff<0) Pdiff=0;

Не понял однозначно слова "независимый"
Сложность в неймспейсе dianna не может быть ниже сложности парент блока биткоин. Никогда. Это как деление на ноль )


Надо будет создавать необычную транзакцию Bitcoin. Предположительно, она будет делаться из фулл клиента DIANNA.

1 может.

Мне вот не нравится PDiff=0 )

Хотя почему бы и нет? Тогда цена домена на старте неймспейса будет равна нулю, народ ломанется, пойдут транзакции, PDiff пойдет вверх вместе с ценой.

По этому мы откидываем PPDiff, поскольку это саморегулирующаяся величина, не в интересах майнеров ее наращивать больше единицы.

Так же из предыдущего расчета видно, что майнить биткоин будут в обычном режиме. Потери будут только на блоках DIANNA. На биткоин PDiff не отразится. И в самом деле, кто будет пропускать блок Bitcoin из-за блока DIANNA, если награда за биткоин по дефолту выше?

Следовательно, DIANNA должна компенсировать PDiff'ом замедление сети: Отсюда вытекает формула PDiff:



f1 - частота выхода Bitcoin блоков
f2 - частота выхода DIANNA блоков в заданном неймспейсе

Надо найти замедление появления блоков DIANNA по сравнению с Bitcoin. Будем считать что у нас 1 неймспейс.

Исходя из, время нахождения блока биткоин майнером при постоянном хешрейте H и сложности Dbit:

Частота:



Для блока DIANNA:

Частота:


Нужно сказать что здесь было сделано допущение, что при мержед майнинге с одинаковой сложностью цепочек, их среднее время нахождения примерно одинаково. Поправьте если не прав.

Тогда блоки DIANNA будут выходить реже блоков Bitcoin в Slow раз:



PPDiff - пеналь. В простейшем случае равен единице. В сложном случае - больше единицы, если кто то хочет халявы.

Да вот формула цены домена, тут как раз все просто )



Bounty - награда за биткоин парент блок
PDiff - типа вкурсе, PDIff неймспейса
sum(bfee(j)) - сумма по комиссиям транзакций парент блока биткоин
N - среднее количество доменных транзакций на блок у майнера/пулла для этого неймспейса

Sorry guys, all is fine

M = D * 2**256 / (0xffff * 2**208) = D * 2**256 / 2**224 = D * 2**32

or

M = MaxTarget * 2**32 / Target

Да, все правильно в биткоин вики написано. Матожидание нужного значения будет

M = D * 2**256 / (0xffff * 2**208) = D * 2**256 / 2**224 = D * 2**32

или

M = MaxTarget * 2**32 / Target

Please help to draw an equation of block solving expectation (in hashes) depending on current difficulty/tarrget.

I see that one provided here is not correct: https://en.bitcoin.it/wiki/Difficulty#How_soon_might_I_expect_to_generate_a_block.3F

time = difficulty * 2**32 / hashrate

I suppose value expectation here is "difficulty * 2**32", but this equation provides incorrect solutions for current network values.

I was about to use formula for discrete finite random value: http://en.wikipedia.org/wiki/Expected_value

But the Bitcoin target is uint256, and i see no possible way to calculate it.

Кстати да, парочки формул в системе не хватает.

Да будет матан!

Здесь вопрос во времени Они получают в среднем награду блока за некую единицу времени. С дианной они будут получать немного больше на мержед майнинге.

Кстати, если кто нить выведет формулу матожидания решения в зависимости от сложности/таргета, я даже назову точные цифры.

Dear Ukigo, I had a talk with cjd (CJDNS leader) in IRC, IRC log is somewhere above in this topic.

He said he will use DIANNA as DNS as long as its domain price would be free or almost free.

His requirement brought DIANNA design to version 1.4 (current), where namespaces have been isolated and non-linear block chain added.

This will allow small networks, having small activity - to have a correspondent small domain fee. I think in CJDNS case it will be almost free.

Тут все немного не так как в обычной жизни Диана устанавливает не цену, а "заказ" сети. Диана устанавливает, сколько денег по доменам следует процессить за 1 блок. В процентах от награды блока биткоин. И это есть PDiff. За этот процент - хочешь или не хочешь, диана сдерет с тебя работу.

То есть вот установила диана в неймспейсе 1 PDiff=1%.
Это значит в 1 блок дианы в этом неймспейсе должно влезть транзакций с суммой комиссий ~ 0.5 BTC (считаем что доход блока биткоин по обычным комиссиям ничтожно мал).
Это так же значит, что в любом случае, минимальная сложность будет "BitcoinDiff + 1%" при расчете блока.

Если майнер набрал в блок транзакций на 0.5 BTC, его доход будет 0.5 BTC (1% от дохода блока биткоин), отработанный за 1% оверхед по сложности. Справедливо.

Если майнер набрал 1 BTC транзакций, его доход будет 1 BTC, но сложность будет, учитывая пенальти:
BitcoinDiff + 1%*2=BitcoinDiff + 2%

На 2 BTC:
BitcoinDiff + 1%*(2^3) = BitcoinDiff + 8%

То есть, рост работы здесь превышает рост дохода из-за пенальти.

Формула одна и майнеры должны выполнять этот заказ:


Отступление от нее в большую-меньшую сторону вызывает экспоненциальный пеналь по сложности PPDiff:



Физический смысл всего этого анального огораживания - жестко привязать бабки, которые получает майнер к работе, которую он делает. И никак иначе. Иначе - инфляция или коллапс.

Нужно так же помнить, что в интересах майнеров держать PDiff на вразумительном уровне. С этой величиной, сложность дианы всегда будет чуть больше сложности биткоина. А значит, чем больше PDiff, тем выше вероятность найти решение Bitcoin, но не найти решение DIANNA. И что в таком случае делать? Отказываться от решения Bitcoin? Нет, отказываться от блока DIANNA и ждать следующего блока Bitcoin.

"You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete" Buckminster Fuller

"Never doubt that a small group of committed citizens can change the world." Margaret Mead

Quotes from http://p2pfoundation.net/

весеннее обострение

В общем, если ни у кого нет возражений, то теперь мне нужны добровольцы.

Нужен прожект менеджер для координации программеров. Нужны программмеры. На начальном этапе я так полагаю, буду делать всю работу сам. Но мне нужна помощь.

Проект предположительно на Java. По скольку я знаю Java Это касается толстого клиента, тонкие там уже разберутся на чем писать.

Обсуждение, разумеется, продолжается. Просто я вижу что вызрело нечто, к чему можно примерить свой NetBeans 

Alright, the final strokes.

Decentralized P2P DNS System Design version 1.4. Changelog

1. Non-linear block chain, block tree

Each Namespace will have its own block chain, its own activity, its own PDiff, and thus, its own domain operation price.

Total namespaces isolation. I2P namespace and chain branch will not contain any data from Tor namespace and branch and any other. And visa-versa.

Small namespaces will have small domain operation price. Bigger namespaces will have bigger one.

Attack on single block chain branch will not affect other branches. And attack on whole DIANNA block tree will be just huge, difficult work.

2. Single domain transaction contains only 1 input and only 1 output, and both about single domain. So 1 domain = 1 transaction. And nothing else.

Since miners process only domain transactions which were directly paid with fee for them, there is no need to include many domain operations in single transaction.

This also will make domain lookup easier. So the authoritative domain reply lookup will be as follow:

For first, DNS client queries for particular domain and network returns a last domain transaction hash and block hash. Highest block wins - as always. Here client can verify that block hash is present in local headers chain and has a particular height.

For the second, client queries the network for Merkle Tree branch for needed domain transaction and transaction data itself. Here he can verify that transaction data are correct by reassembling Merkle Tree and comparing its root hash against local stored block header in chain.

Since client ensured that network returned *valid* *last* transaction for this domain, he can easily resolve domain into VALUE containing in transaction output.

Peace a cake

I need volunteers to code this tree of freedom. Primary, I need the project manager which will coordinate programmers. For the first steps I can be ideologist, project manager and programmer in one But I really need a help.

Ну в "обычном" интернете этим занимается IANA. Ну, например, вводит список стандартизированных TCP/UDP портов. Это носит характер рекомендации, чтобы девелоперам было от чего плясать, но соблюдать его - дело девелоперов. Например, я могу повесить апач на порт 675, однако такое действие отпугнет общественность.

Так же и тут. Создадим страницу в WIKI, где будет рекомендовано, кто какой неймспейс юзает.

Поскольку это все замутилось из-за i2p, пусть i2p будет №1, к нему я собираюсь написать первую имплементацию.

Конечно не могут. 1 домен принадлежит только 1 владельцу в фиксированный момент времени. Если владелец хочет передать домен другому, он в output его просто подписывает ключом другого владельца. Соответственно, владеть доменом он с этой минуты перестает. Точнее с минуты, когда транзакция будет включена в блок.