Bitcoin Forum
July 04, 2024, 09:00:45 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [24] 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »
461  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 02, 2012, 05:01:25 PM
теперь стоит прокомментировать идеи, находящиеся между строк:
1. заявка через блокчейн биткоина является публичным обьявлением работы, т.е. любой пул посчитавший что заявка валидная и будет оплачена может сразу же приступать к работе. (заявка прикрепляется с помощью ID к транзакции, рассылаемой через сеть дианы)
2. скорее всего пулы не будут доверять любой заявке, поэтому в систему вводятся регистраторы, подписывающие заявки. Идентифицировав регистратора по его публичному ключу, пул может собрать историю выплат регистратором, на основании которой принять решение доверять ему или нет.
3. сложность блока дианы всё также может определяться зависимостью от частоты блоков / количества транзакций. Но. Лучше привязать сложность к скорости выхода блока после заявки используя тот же алгоритм, что и в биткоин.
4. самое главное нововведение, вытекающее из последнего пункта: база данных доменных записей и блокчейн(-ы) должны быть разделены, так как (в такой реализации) в цепочке блоков дианы могут быть неоплаченные транзакции. Актуальную DNS базу данных следует группировать в блоки и подтверждать их изменение в блокчейне (с некоторой задержкой, необходимой для оплаты транзакции).
5....
Все это весело конечно, но я уже написал выше что не вижу способа деперсонализации майнера.

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

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

Я не вижу альтенативы.
462  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 02, 2012, 04:56:58 PM
@pent

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

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

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

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

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

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



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

Дальше цена изменяется согласно активности сети.
463  Bitcoin / Development & Technical Discussion / Difiicult question related to merged mining on: March 02, 2012, 12:59:39 AM
The sutuation: classical merged-mining scheme. PARENT and AUX chains.

The problem: I need to send a transaction TRX1 in PARENT chain to some address or hash. And another TRX2 in AUX chain. These transactions are cross-referenced to each other by some marks in Script. Is there any solution the funds of TRX1 to be widthdrawn only by miner who merge-mined AUX block with TRX2?

I don't know who will mine AUX block, but i want to pre-pay a reward for him in PARENT chain.

Thanks.
464  Bitcoin / Bitcoin Discussion / Re: DIANNA: the IANA Decentralized design concept on: March 02, 2012, 12:25:23 AM
I need help.

Is there any possible way to send a bitcoin transaction with fee to some address/hash and this transaction can be widthdrawn later only by miner who lately merge-mined DIANNA block with correspondent domain transaction?

I want to depersonalize mining pools in this scheme, so domain transaction can be processed by any miner, not miner who was paid directly by client for processing.

This is related to Miners consolidation possible (last?) issue.

Detailed problem: https://bitcointalk.org/index.php?topic=66959
465  Bitcoin / Bitcoin Discussion / Re: DIANNA: the IANA Decentralized design concept on: March 02, 2012, 12:05:51 AM
New changes! Ideas just run and run - and not going to stop Smiley v1.5
http://dianna-project.org/wiki/Design_Changelog

Summary: Replace forced PDiff system definition by forced domain transaction fee definition, remove Difficulty penalty. Fee is now set by DIANNA for particular Namespace.

* Remove forced PDiff system definition (Pentarh Udi, rpMan)
* Add forced domain transaction fee definition (Pentarh Udi, rpMan)
* Remove Difficulty penalty (Pentarh Udi, rpMan)
* Use cases clearification

DIANNA now will define a price (hallelujah!!!) for domain operation instead of PDiff. Price will be dedicated to each namespace and depend on its network activity. Thanks to rpMan.
466  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 11:58:29 PM
Обновил дизайн результатами дискуссии. Не обделил авторством rpMan Smiley

v1.5
http://dianna-project.org/wiki/Design_Overview
http://dianna-project.org/wiki/Design_Changelog
467  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 10:08:45 PM
Единственная возможность избежать авторитетов - вмешательство в биткоин, пропихивание какого нить очередного BIP, который заставит биткоин учитывать блок-чейн дианы со всеми его приколами.

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

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

Я всеми ногами и руками за такое решение, но я правда не представляю как это сделать.

Может кто помозгует, с новомодными введениями бип16 и пр. такое можно замутить? Если да, то это будет просто ништяк.
468  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 09:55:33 PM
Начал понимать, понимаешь. У я такие схемы в башке кручу, что иногда деталей не видно.

Никакая это не беда, это обычный бызнес.

Домен не могут забрать без ключа. Только если откажут в регистрации на TTL блоков, а потом сами регнут.

Сговор - какашка в свой колодец. Это компрометирует диану, а диана - их бызнес. Зачем им срать в свой бизнес, терять доверие людей?

С тех пор как мы вынесли фин цепочку вовне, все платежи на авторитете пуллов.

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

К тому же есть такие вещи как p2pool. Я хрен знает че такое, не разбирался, но звучит обнадеживающе Smiley
469  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 09:45:19 PM
Кстати регистраторы по ходу отпадают. Или они просто продают биткоины за фиат дабы клиент мог зарегать домен из дианы.

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

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

1. Сгенерить/выбрать ключ домена для регистрации/апдейта
2. Раздобыть каким то образом биткоины на биткоин-кошель дианы (да, диана будет включать в себя базовый клиент биткоин)
3. Найти пулл, получить адрес для платежа
4. Скрафтить комиссию в биткоин сеть, подождать подтверждений
5. Скрафтить доменную транзу на основе это комиссии

В любом случае, крафтить доменную транзу клиент должен со своего гуя своим ключом.
470  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 09:31:37 PM
Да при чем тут слепо? У биткоина правило фундаментальное - у какого форка цепи высота больше - тот и принимать за истину. Форки цепи происходят постоянно. Постоянно генерятся сотни тысяч кандидатов блоков на текущую высоту. и на основе их идут другие форки. Но сеть принимает наивысший форк.
471  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 09:17:32 PM
Ничем. Если намайнят такой блок, то такой блок не будет иметь потомков в течении указанного времени в будущем, а занчит другой блок-кандидат с нормальным таймштампом перебьет его по высоте.
472  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 09:07:30 PM
Касательно таймштампа в биткоин, проверяется, не залез ли блок далеко в прошлое за предыдущий:

Code:
main.cpp: CBlock::AcceptBlock()
    // Check timestamp against prev
    if (GetBlockTime() <= pindexPrev->GetMedianTimePast())
        return error("AcceptBlock() : block's timestamp is too early");

В будущее не проверяется Smiley гыгы. А чем это может навредить?

473  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 08:49:22 PM
* как человек выбирает/находит себе регистратора
 - наисложнейший вопрос... выбор не верной методики точно будет концентрировать все заказы у минимального количества регистраторов, а так как диффиренцировать рынок тут не чем (дорогие и дешевые операции) то регистратор в конце концов будет останется один/мало - кстати будет еще один повод подмять под себя пулы майнинга bitcoin.
Ох что то я об этом уже писал много раз Smiley

* Объявление пулла/регистратора на форуме: Регистрирую DIANNA! Принимаются все/некоторые неймспейсы! Наинизшая цена!
* Тоже: в adsense
* В любом другом удобном месте поспамиться

Мы вынесли фин-цепочку вовне. Платеж идет непосредственно на кошель пулла/регистратора. То есть лично. И контролировать ее прохождение можем лишь частично. Все остальное - ложится на репутацию регистратора или пулла. Как в обычном бизнесе. Кинул пацана - по **лу на! Smiley Ну то есть вонь на форумах и прочие методики загаживания кармы недобросовестных контор.

Немного централизованно, но пулл здесь лишь проводник, он не может управлять доменом. Если че не так - социальное давление опять же.

* что за спец-транзакция с комиссией? я вроде четко расписал варианты, вопросы остаются следующие фазы:
 1. факт пожелания в регистрации
 2. проверка переданных средств в bitcoin
 3. проверка того что домен зарегистрирован
 4. только после этого деньги должны поступить на счет пула
Нет, предоплата. Если чета не получается - рефанд через тикеты. Как в обычном бизнесе.
Ты посылаешь деньги - тебе регистрируют домен. Если не регистрируют, кричи что они мудаки.
Единственное что - должна быть специальная транзакция биткоин, созданная хоть пользователем, хоть пуллом на основе хеша, предоставленного пользователем. Так DIANNA узнает что эта транзакция есть ни что иное как комиссия за доменную операцию. Доменная операция создается только с ссылкой на эту транзакцию.

* выбрав регистратора человек платит именно ему, сразу после создания транзакции (пары diana/bitcoin?) никто не может создать с тем же доменом, но на себя?
Домены внутри дианы подписываются ключами типа как коины. Только владелец приватного ключа домена может проводить с ним транзакции. Регистратор или пулл просто просят клиента подписывать некоторые строки этим приватным ключом в процессе регистрации, но сам ключ всегда у клиента.

* transfer - получается для передачи домена другому владельцу нужно заплатить одновременно старому владельцу и комиссию... грустно это, очень грустно.

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

просто еще никто не гадил в блокчейне с ложным временем... я уже вижу алгоритм, выставляющий время в блоке заведомо неверное такое (на пару недель в будущее или в прошлое, чтобы увеличить сложность), чтобы при расчете новой сложности получился коллапс (сложность станет низкой и можно успеть совершить атаку 51%).
Вы понимаете что нет никакой!!! возможности проверить время (хотя есть... если все клиенты будут проверять текущее время у центрального источника, и при сильных расхождениях времени на компьютере и в блоке - просто переставать работать).

В коде bitcoin есть какие либо проверки времени в блоке и текущего времени на компьютере? А проверка времени в соседних блоках? Может оли сейчас новый блок иметь время старее чем указано в предыдущем блоке в цепочке?
Хотя на слишком большие промежутки времени можно найти разумный компромис/алгоритм, в т.ч. децентрализованную синхронизацию времени.
Наверняка какие то проверки есть, не копался точно.
474  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 08:25:56 PM
Неймспейсы позволяют:

1) Разделить семантику значения ключей.

У традиционных DNS зон например семантика значения будет такая:
Code:
KEY<domain.com>=VALUE<@ IN NS ns1.hoster.com.;@ IN NS ns2.hoster.com;>

У I2P семантика значения будет - 516 байт-хеш назначения
Code:
KEY<domain.dia.i2p>=VALUE<sdfjdslfjsdlfsldfkldsfjsldjfdsjf23r3489r943u943f0--дохрена байт--34c83u349c93u0c4>

Ну и зачем данные с разными семантиками в одном неймспейсе?

2) Ограничить объем актуальных данных только своим неймспейсом. И правда, зачем DNS клиентам I2P принимать блоки с доменами CJDNS там например

3) Разделить активность сети, а значит и цену за домен. Своя цепь блоков, в которых фигурируют только свои домены. Значит своя активность. Значит своя цена за транзу.
475  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 08:18:23 PM
Что такое частота последних блоков?
Намекну, что времени, записанному в блоках верить НЕЛЬЗЯ, единственное чему там можно верить - сложность (она однозначно проверяема).

Дык как нельзя, если верят? Я так понимаю, там +/- час не вопрос, но в целом, таймштамп должен укладываться в какие то разумные рамки.

Вот, биткоин таргет по таймштампу вычисляет:

Code:
    // Limit adjustment step
    int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
    printf("  nActualTimespan = %"PRI64d"  before bounds\n", nActualTimespan);
    if (nActualTimespan < nTargetTimespan/4)
        nActualTimespan = nTargetTimespan/4;
    if (nActualTimespan > nTargetTimespan*4)
        nActualTimespan = nTargetTimespan*4;
    
    // Retarget
    CBigNum bnNew;
    bnNew.SetCompact(pindexLast->nBits);
    bnNew *= nActualTimespan;
    bnNew /= nTargetTimespan;
    
    if (bnNew > proofOfWorkLimit())
        bnNew = proofOfWorkLimit();

Остаться в конце концов должен кто то один! А вот кому понравится регистрировать xxx доменов в неймспейсах, количество которых кстати будет зависеть от прихоти кого-то, редактирующего публичную вики страничку проекта, на которой записаны рекомендации по неймспейсам? Просто этот момент напрямую вытекает из недостатка самой системы DNS.. развиваться необходимо в другую сторону, ключевые слова и поисковики.
Да не, уж как то разбираться будут.
Еще раз повторяю, страничка в вики с рекомендациями - это рекомендации. Это не правило.
Хочешь - забивай свой неймспейс, договаривайся с майнерами, чтобы шли через него транзы, пиши клиента. Но желательно уведомить об этом страничку в вики, дабы туда кто еще случайно не залез со своей семантикой.
476  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 07:59:45 PM
Бизнес процесс значит.

Основы.

За доменом закрепляется пара ключей. Приватный ключ хранится у юзера и никому он его не дает. С публичным варианты.
Диана устанавливает цену доменной операции для неймспейса, исходя из активности неймспейса. Эту цену нарушить нельзя.
Блок дианы мерж-майнится по прежнему против парент блока биткоин. PDiff есть отношения суммы по доменам к награде парент блока биткоин. Но уже не задается системой.
Основанием для помещения доменной транзы в цепь дианы есть аут спец транзакции биткоин с комиссией.
Транза с комиссией помечается добавлением в скрипт подписи имени домена приватным ключом и за этим OP_DROP и далее обычный биткоин скрипт.

Процесс.
Юзер хочет домен, у него есть пара ключей и немного BTC.
Варианты:
1) Юзер идет на майнинг пулл или к посреднику, смотрит цену за домен текущую в диане.
1а) Юзер качает диану-фулл, создает там биткоин кошель, переводит на него деньги за домен (или просто импортирует ключ). Крафтит оттуда транзакцию биткоин, подписывая в ней имя домена приватным ключом, переводит на счет пулла
1б) Пулл просто просит подписать имя домена ключом и перевести ему нужные деньги. Предоставить имя домена и публичный ключ. Пулл сам крафтит эту транзакцию себе.
1в) Юзер идет к посреднику, платит фиат, посредник проделывает работу 1б) или 1а) за юзера, попросив у того лишь пуб ключ и имя домена.
2) На основании скрафченой транзакции создается доменная транзакция
3) Куча таких транзакций складывается в блок дианы, юзер может наблюдать в публичных источниках проводку своей транзакции

Как я уже говорил, new,update,renew,transfer - одна и та же хрень по одной и той же цене.
477  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 07:36:20 PM
То есть у тебя даже в теории бизнеспроцесса небыло? мдаа... а уже волонтеров-добровольцев кодеров набираешь.
Да как это не было, Было. Просто ты своими вопросами заставил задуматься, я опять порвал шаблон и бизнес процессы изменились.

еще родил красивый вопрос:
* зачем нужно разделение на неймспецсы в блокчайнах? уже сейчас владельцы прибыльных доменов стремятся закрыть для фишинга все возможные пути, регистрируя домены в нескольких зонах - ru, com, org.ru,.. значит и тут будет та же фигня, будут пачками регистрировать во всех неймспейсах (уж киберсквотеры точно)
Чтобы разделять активность и цену. CJDNS например, нищеброды. Какой киберсквоттер туда сунется?


предлагаю схему защиты доменов от киберсквотеров на время старта проекта, чтобы киберсквотеры не захапали чужие домены из текущей системы:
- подтверждать только те регистрации новых доменов, для которых не существует действующего домена в текущей DNS Интернета, а если домен уже существует, подтверждать принадлежность через подпись файлом с сервера в Интернете по специальному протоколу (кстати в текущей DNS похожая схема присутствует, где то от меня требовалось создать в регистрации DNS файлы с соответствующим типом)

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

Мне этот способ огораживания не очень пахнет. Это завязка на ICANN. См. выше что я написал про новую схему.
478  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 07:05:51 PM
Желающие приобрести домен будут оплачивать либо спец транзакцией через диану-фулл, либо фиат посреднику, посредник уже делает спецтранзакцию.

Погодите с процессом. Меня осенило. Все это через *опу. Мы ограничили майнеров в сумме, но не ограничили в количестве.

Короче. Давайте так. Пусть DIANNA задает именно цену домена, а не PDIff - базируясь на частоте последних N блоков. Ниже частота - ниже цена. Выше частота - выше цена. Начиная с 1E-8 BTC. И эту цену нельзя нарушить.

Сумма таких транзакций в блоке будет определять PDiff по старой формуле. Выше сумма транзакций - выше PDiff. Только он уже не определяется системой, а зависит исключительно из отношения в формуле где то выше. Пеналь в сад.

Хочешь - насуй в блок транзакций на 50 BTC. Но считать его будешь по двойной сложности.
479  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 06:16:40 PM
Да, и кстати, чтобы заниматься таким срамом, надо генерировать тысячи/миллионы транзакций биткоин. Мелких. Сомнительная затея. Есть же такие вещи как MAX_BLOCK_SIZE у биткоина и прочие ограничительные мероприятия.

Я допускаю что этим будут заниматься в определенных масштабах. Но не вижу вреда. Данные эти будут лежать мертвым грузом в дхт до своего экспайра. Запросов по ним почти не будет.

Меня лично не напрягает это явление в ICANN. Ну занят dianna.org. Ну и фигли? Зарегал dianna-project.org Я вообще часто регаю домены и кибресквоттеры меня не напрягают.

Ну может кто просчитает, насколько этим выгодно вообще заниматься и в каких границах? Подумаем.
480  Local / Кодеры / Re: DIANNA: IANA Decentralized концепт дизайн on: March 01, 2012, 06:11:41 PM
Сложность - это я подразумеваю число, которое возвращает bitcoin по RPC команде getdiffculty. Сейчас у bitcoin сложность БОЛЬШЕ чем у namecoin, который почти все пулы майнят через merged mining...

Независимый.. это значит пул майнинга bitcoin может настроить свой пул на майнинг через прокси кучу других валют... namecoin, diana, ixcoin, xxxcoin... и факт нахождения блоков в этих форках и bitcoin не связаны (то есть не требуется находить блок bitcoin чтобы найти блок namecoin)

Этот вопрос вытекает из плохого понимания мной сути merged mining... если я верно все понимаю, майнинг форков независимый.. если блок bitcoin не найден но искомый nonce вдруг стал подходить для блока форка - то этот блок упаковывается как при обычном майнинге.

Да, независимый. Но отдельный майнинг без bitcoin невозможен.

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

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

Вы похоже не понимаете как такое будет возможно? Киберсквотер спокойно создаст свою версию клиента diana, которая не рассылает транзакции в сеть, но майнинг настроен на использование пула своих приватных транзакций как следует.
p.s. у вас же opensource проект? Smiley
Майнеры итак будут майнить исключительно свои транзакции, которые были оплачены исключительно им. Не надо для этого делать форк Smiley
С киберсквоттерами бороться вообще бесполезно, надо просто их усилия привязать к работе. Хочет миллион доменов - пусть пыхтит. Работа по PDiff - себестоимость домена.

Они могут пыхтеть и складывать свои домены, да. Но это срач в свой колодец. Ведь они могут брать с клиентов деньги за домены. А если они будут все забивать, то клиентам нахер такое надо. Спрос упадет.

Короче, я думаю что это выстрел себе в ногу. Переубедите меня.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [24] 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!