DIANNA: IANA Decentralized концепт дизайн

[panic]

5. предложенный алгоритм не отменяет ограничений в виде "справедливой цены" и "привязки сложности к цене". Каждый full клиент сможет проверить соответствие блока дианы необходимым требованиям.

[pent]

@pent

Наваял сценарий на Питоне по формулам. Выводы :

 1) не хватает формулы для ReqSum (трешхолда) -- как его вычислять ?
 
 2) формула для цены домена дает среднюю за домен в последнем блоке DIANNA
   а нужна формула определяющая цену домена для регуляции мощности сети.

 3) нужны желательные начальные значения при виртуальном запуске сети
   чтобы было от чего отталкиватся при тестировании формул.

 4) похоже в некоторые формулы потребуется ввести некие коэффициенты
    или какие-то довески.

 5) PDiff minimal должна быть много больше твоей.

Нет уже никакого ReqSum. Цена домена назначается дианой, а поправка к сложности считается по формуле. Ограничений никаких нет. PDiff minimal тоже нет. Все упростилось.



На старте неймспейса назначается цена домена в 1E-8 BTC. Например. Ну или 1 BTC. Ну или как определить корректный старт?

Дальше цена изменяется согласно активности сети.

[pent]

теперь стоит прокомментировать идеи, находящиеся между строк:
1. заявка через блокчейн биткоина является публичным обьявлением работы, т.е. любой пул посчитавший что заявка валидная и будет оплачена может сразу же приступать к работе. (заявка прикрепляется с помощью ID к транзакции, рассылаемой через сеть дианы)
2. скорее всего пулы не будут доверять любой заявке, поэтому в систему вводятся регистраторы, подписывающие заявки. Идентифицировав регистратора по его публичному ключу, пул может собрать историю выплат регистратором, на основании которой принять решение доверять ему или нет.
3. сложность блока дианы всё также может определяться зависимостью от частоты блоков / количества транзакций. Но. Лучше привязать сложность к скорости выхода блока после заявки используя тот же алгоритм, что и в биткоин.
4. самое главное нововведение, вытекающее из последнего пункта: база данных доменных записей и блокчейн(-ы) должны быть разделены, так как (в такой реализации) в цепочке блоков дианы могут быть неоплаченные транзакции. Актуальную DNS базу данных следует группировать в блоки и подтверждать их изменение в блокчейне (с некоторой задержкой, необходимой для оплаты транзакции).
5....

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

То есть, сделать так, чтобы клиент посылал комиссионную транзакцию в сеть непонятно кому - и на основе ее делался блок диана - Я НЕ ЗНАЮ как так сделать.

В текущем варианте оплата посылается персонально майнеру. Он видит эту оплату и принимается за блок.

Я не вижу альтенативы.

[pent]

То есть, сделать так, чтобы клиент посылал комиссионную транзакцию в сеть непонятно кому - и на основе ее делался блок диана - Я НЕ ЗНАЮ как так сделать.

Тут ссылочку подкинули...

https://en.bitcoin.it/wiki/Contracts

[panic]

 
1. транзакция с минимальной комиссией отправляется самому себе.
2. в блок дианы майнер добавляет свой адрес, куда слать коины.
3. после того, как я убедился, что моя транзакция добавлена в блок, я оплачиваю её стоимость.
4. DNS хранилище проверяет оплату и добавляет / обновляет запись в своей базе.
5. Все довольны.

[pent]

Прикольно, но DNS хранилище это и есть блок чейн дианы. Фишка блок-чейна в том, что все, что туда запечатано - валидно.

Следовательно, майнер сделал работу, предоставил свой адрес и запечатал транзакцию в блок. А я взял и не оплатил.

[panic]

DNS хранилище разбиваем на блоки и подтверждаем их в блокчейне. Неоплаченные транзакции идут лесом. см. пункт 4 в комментариях https://bitcointalk.org/index.php?topic=64282.msg779439#msg779439

[pent]

Объясни плз подробнее, чето я не пойму. А их кто подтверждать будет и за какой $?

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

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

Дальше чего? Ты предлагаешь еще один блок чейн, куда такие транзакции будут включаться только если они оплачены? А кто будет майнить этот блок чейн и за какие деньги?

[pent]

@Ukigo, окей.

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

[pent]

А насчет контрактов - а юзает ли их кто-нибудь на практике ?
Если да -- то тебе было бы полезно с ними пообщаться -- мож чего подскажут

Я сейчас изучаю сырцы на предмет поддержки nLockTime и sequenceNumber. Ато везде говоря типа поддержка отключена. Но я там точно видел функции по этой теме, смысл которых мне тогда был не понятен.

По моему все это было упразднено мультисигами.

[pent]

nLockTime и nSequence поддерживаются. Выключили похоже только в UI интерфейсах.

[panic]

Объясни плз подробнее, чето я не пойму. А их кто подтверждать будет и за какой $?

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

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

Дальше чего? Ты предлагаешь еще один блок чейн, куда такие транзакции будут включаться только если они оплачены? А кто будет майнить этот блок чейн и за какие деньги?

1. В сети дианы я объявляю, что хочу зарегистрировать вот-такие вот домены, и заплачу за них вот столько-то.
2. Пул видит это дело, смотрит в блокчейн биткоина, находит транзакцию с хешем моей заявки и, если его устраивает цена, начинает искать блок дианы.

3. Валидный блок дианы должен содержать:
-валидные транзакции.
-биткоин адрес майнера.
-цены транзакций.
-хеши биткоин блоков с принятыми заявками.
-изменение хешей и добавление новых хешей блоков DNS хранилища.

4. После того, как блок дианы найден, я оплачиваю транзакцию. (а скорее всего не я, а регистратор с хорошей репутацией)
5. В ближайшем блоке дианы пул изменяет блоки DNS хранилища и добавляет новые хеши блоков в блок дианы. Очевидно, что все изменения должны быть сделаны по правилам дианы, чтобы другие узлы сети могли воссоздать блок и получить хеш указанный в блоке.

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

[panic]

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

[pent]

Вот "правильные" узлы - это как раз централизация и цензура.

В твоем предложении можно избавиться от централизации только одним способом - при резолве домена из блок чейна дианы дополнительно еще искать и валидную транзакцию биткоин. Это очень сложно.

[rPman]

Я же вроде описал решение, которое позволит не добавляя в bitcoin чего-то нового (нужна поддержка multisig транзакций для escrow, я просто технических подробностей не знаю, но оно как я понимаю УЖЕ ЕСТЬ и работает), из недостатков, регистрация не мгновенная (как минимум условие ожидания подтверждений в bitcoin) и требует на время проведения регистрации клиент и регистратор должны быть онлайн.

Для контроля в принципе все уже есть в bitcoin - пусть участники следят сами друг за другом (желающие зарегать домен следят чтобы их домен был зареган, а регистраторы - чтобы им платили).
Достаточно чтобы в bitcoin и diana было реализовано escrow, а дальше, перекрестные транзакции, и многоэтапный процесс регистрации:
1. клиент регистрирует домен и переводит деньги
2. пул проверяет что деньги ему перевели и регистрирует домен (ждем когда блок или несколько будут найдены)
3. клиент ждет когда в блокчейне появится его домен и будет доступен ему (а то пул зарегистрирует на себя)
 * если так - подтверждает обе транзакции в bitcoin и diana (multisig transaction - для доступа к монетам должны быть подписаны несколькими участниками)
 * иначе не подписывает и транзакция, по прошествии ttl откатывается (вот тут реально я не знаю сделано это в bitcoin или нет.. но технически не вижу проблем для реализации)
то есть для того чтобы домен был зарегистрирован, оба и клиент и регистратор должны быть онлайн (хотя бы поочередно.. клиент дважды - чтобы послать и подтвердить регистрацию, регистратор чтобы как минимум принять регистрацию и найти блок)

[pent]

Все то оно так, да что мешает клиенту подтвердить только DIANNA транзакцию без bitcoin транзакции.

[pent]

После вникания в суть вот такого предложения у меня родилась идея.

Перед операцией, майнер и клиент создают у себя некие рендомные одноразовые пароли:
* passC - клиентский пароль, hash_passC - его хеш sha256(RIPEMD160()) (соответствует OP_HASH160 в скриптах)
* passM - майнерский пароль, hash_passM - его хеш sha256(RIPEMD160())

Так же,
* bit_pub_M - публичный ключ (адрес) bitcoin, принадлежащий майнеру и hash_bit_pub_M - его хеш160
* dia_pub_C - публичный ключ dianna, принадлежащий клиенту и его хеш hash_dia_pub_C

Майнер дает hash_passM клиенту.

Клиент создает транзакцию Bitcoin с sigScript в ауте:

Code:

OP_HASH160 <hash_passM> OP_EQUALVERIFY OP_HASH160 <hash_passC> OP_EQUALVERIFY OP_DUP OP_HASH160 <hash_bit_pub_M> OP_EQUALVERIFY OP_CHECKSIG

Для того, чтобы забрать эту транзакцию, майнеру нужно будет в следующем INPUT предъявить два пароля в открытом виде + нормальная биткоин проверка на сигнатуры (все что после OP_DUP). Input должен будет быть таким:

Code:

signature bit_pub_M passC passM

Клиент так же создает транзакцию DIANNA с sigScript в ауте:

Code:

OP_HASH160 <hash_passM> OP_EQUALVERIFY OP_HASH160 <hash_passC> OP_EQUALVERIFY OP_DUP OP_HASH160 <hash_dia_pub_C> OP_EQUALVERIFY OP_CHECKSIG

Чтобы клиент мог воспользоваться в дальнейшем этим доменом, ему так же надо будет предъявить два пароля + проверка сигнатуры:

Code:

signature dia_pub_C passC passM

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

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

Однако тут есть недостаток. Что если майнер скажет: А вот хрен с теми деньгами, не дам я тебе пароль! И клиент теряет домен через TTL блоков.

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

[panic]

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

это просто мысли вслух.

Вот "правильные" узлы - это как раз централизация и цензура.

В твоем предложении можно избавиться от централизации только одним способом - при резолве домена из блок чейна дианы дополнительно еще искать и валидную транзакцию биткоин. Это очень сложно.

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

[pent]

Не, майнеры таким образом заинтересованы от балды добавлять в "правильную" базу "правильные" записи. В такой схеме без клиентских проверок никуда.

[pent]

Ну хорошо. У майнеров итак много привилегий.

Пусть клиент просто тупо создает мультисиг транзакцию 2 из 2.

ы?