NovaCoin (scrypt PoW + PoS hybrid) [self-mod]

[rPman]

Какой тут жуткий оффтоп.

В тему куби/буби/..-board, я облизываюсь на это - http://www.parallella.org/board/ (shop), они пишут что 64-процессорный сопроцессор у них заработал (но кажется недостаточно средств чтобы платы на его основе клепать, а как хотелось бы). А наличие FPGA-модуля, зарождают надежду на нормальное развитие софта в этом направлении.

[Balthazar]

Для совместимости с BTC в репозиторий была добавлена реализация RPC функции createmultisig, по назначению она аналогична addmultisigaddress, но не добавляет созданный адрес в кошелек.

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

В процессе:

https://bitcointalk.org/index.php?topic=114712.msg7758020#msg7758020

Код черновой реализации алгоритма генерации ключей можно посмотреть здесь:

https://github.com/CryptoManiac/novacoin/commit/952b469fe40e71ed14752b28641aa0cb62c8d741

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

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

[Dimanoid]

И всё же вернусь к теме комиссии за перевод. Хотелось бы понять, за что в этот раз сняли 0,003NVC, если блок меньше 2-х килобайт. Вот транзакция.
P.S. Возможно, причина - что один из входов "молодой"? Но в этом случае вроде только совсем без комиссии нельзя отправить?

[Balthazar]

Тут всё просто. Во-первых, при подсчете комиссии размер всегда округляется до килобайтов в большую сторону, то есть 1.001КБ, 1.3КБ или 2КБ это одно и то же для сети. Во-вторых, если приоритет транзакции ниже среднего, то добавляются дополнительные 0.001 nvc комиссии и соответствующая надпись в форме coincontrol подсвечивается красным. Возможно, в этом дело, можно посчитать.

[Dimanoid]

 Тут даже не в размере комиссии дело (она в любом случае теперь меньше!) Просто не так удобно стало управлять входами.
Клиент рассчитывает комиссию 0,002 - я её выставляю. Пытаюсь отправить - не уходит, всплывает окно о нехватке средств.
А когда 0,003 выставляю - в клиенте пишет, что будет 0,001NVС сдача. В общем, сбивает с толку, сколько нужно выставить.

P.S. А как узнать о низком приоритете транзакции? В управлении входами красных надписей не было! (есть скриншот).

[aclon]

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

[icreator]

может в АПИ сразу сделать расчет величины комиссии по данной рав-транзакции?

get_tax_raw(rawtx)

[Balthazar]

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

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

может в АПИ сразу сделать расчет величины комиссии по данной рав-транзакции?

get_tax_raw(rawtx)

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

[Dimanoid]

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

Ну откуда-то сумма комиссии всё же берётся!? Вот в тестовой сети попробовал - тоже не хватило 0,002NVC:

 То есть точно рассчитать комиссию никак нельзя? Можно считать, что это "фича" и пользоваться как есть (добавить 0,001 и отправить снова)?

[Kepasa]

Тому кто найдет следующий блок на пуле nvc.coinpool.ru в течении следующих 3 часов- 1 NVC от меня в качестве бонуса. Адрес в личку на пуле.

[Balthazar]

Ну откуда-то сумма комиссии всё же берётся!? Вот в тестовой сети попробовал - тоже не хватило 0,002NVC:

...

 Можно считать, что это "фича" и пользоваться как есть (добавить 0,001 и отправить снова)?

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

То есть точно рассчитать комиссию никак нельзя?

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

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

[icreator]

Если сделать свою локальную сеть нод - скажем 2-3 компа то блоки в такой сети будут генерироваться с тойже скоростью что и в основной сети

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

и все - каюк биткоинам - переходим на новакоины ))

или там точно так же можно по сути - если отдельную сеть создать и внутри сети так же блоки гнать а 2 компа

[Ochert]

Походу кто-то потихоньку закупается?

[Balthazar]

Если сделать свою локальную сеть нод - скажем 2-3 компа то блоки в такой сети будут генерироваться с тойже скоростью что и в основной сети

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

и все - каюк биткоинам - переходим на новакоины ))

или там точно так же можно по сути - если отдельную сеть создать и внутри сети так же блоки гнать а 2 компа

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

[RoadTrain]

Balthazar, вы не анализировали различные предложения о "запечатывании" в блоки текущего "снимка" UTXO?
https://bitcointalk.org/index.php?topic=88208.0
https://bitcointalk.org/index.php?topic=204283.0

Интересно было бы примерить это всё к нове

[Balthazar]

Разработчик Electrum (ThomasV) изначально был вдохновлен данной темой, и использовал этот подход на базе древовидной структуры в своем проекте. Правда, им не используется блокчейн для "запечатывания" хэшей текущего состояния.

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

Конечно, возможен вариант, в котором для создания снимков используются только PoW блоки и проверка их PoS предков не производится. Тогда можно будет обойтись заголовками, однако проверка таких снимков будет всецело полагаться на work составляющую. В принципе, это даже можно реализовать модификацией Electrum-server... Это не изменит его концепцию принципиально, но добавит надежности.

Кому суть идеи непонятна по тому посту в теме, то упрощенно это выглядит так:

1) Формируем список хэшей всех непотраченных транзакций (по аналогии со списком хэшей транзакций, включаемых в блок);
2) Считаем хэш всех элементов списка (по аналогии с merkle хэшем в блоке);
3) Создаем структуру вида:

Версия
Хэш предыдущего экземпляра структуры
Хэш всех элементов списка
Время создания
Номер блока

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

[RoadTrain]

Разработчик Electrum (ThomasV) изначально был вдохновлен данной темой, и использовал этот подход на базе древовидной структуры в своем проекте. Правда, им не используется блокчейн для "запечатывания" хэшей текущего состояния.

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

Интересно, но Electrum слишком лёгкий клиент, в том плане, что слишком полагается на доверие серверам. Я не знаю в деталях его принципы работы, но полагаю, что несильно ошибаюсь.
Тут идея состоит в том, чтобы сделать легковесный клиент, который, тем не менее, мог бы проверять цепочку без необходимости излишне кому-либо доверять.
Чем-то напоминает развитие SPV-концепции, с добавленим загрузки и верификации UTXO set.

Надо бы как-то сподобиться и накидать примерный вариант реализации, потом оценить, надо ли оно вообще...

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

Конечно, возможен вариант, в котором для создания снимков используются только PoW блоки и проверка их PoS предков не производится. Тогда можно будет обойтись заголовками, однако проверка таких снимков будет всецело полагаться на work составляющую. В принципе, это даже можно реализовать модификацией Electrum-server... Это не изменит его концепцию принципиально, но добавит надежности.

Думаю, в случае с гибридным дизайном придётся полагаться на pow составляющую. Хотя проверить pos блоки в принципе тоже возможно, если клиент уже обладает полноценной базой UTXO.
В моём представлении, данный протокол в первую очередь облегчает первичную синхронизацию с сетью, что было бы особенно заметно в случае с биткойном.
После получения всех заголовков и снимка UTXO, клиент может продолжить функционирование в "обычном" режиме - принимать блоки полностью, проверять их, проверять транзакции, коммитить изменения в локальную базу UTXO...

Но это лишь один из вариантов, есть ещё всякие UTXO commitments и мета-цепочки, в которые я пока не углублялся.

[Balthazar]

Разработчик Electrum (ThomasV) изначально был вдохновлен данной темой, и использовал этот подход на базе древовидной структуры в своем проекте. Правда, им не используется блокчейн для "запечатывания" хэшей текущего состояния.

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

Интересно, но Electrum слишком лёгкий клиент, в том плане, что слишком полагается на доверие серверам. Я не знаю в деталях его принципы работы, но полагаю, что несильно ошибаюсь.
Тут идея состоит в том, чтобы сделать легковесный клиент, который, тем не менее, мог бы проверять цепочку без необходимости излишне кому-либо доверять.
Чем-то напоминает развитие SPV-концепции, с добавленим загрузки и верификации UTXO set.

Надо бы как-то сподобиться и накидать примерный вариант реализации, потом оценить, надо ли оно вообще...

Electrum проверяет заголовки блоков, а состояние UTXO запрашивает у серверов. Смысл же цепочки снимков в том, что теоретически с её помощью можно принудительно унифицировать поведение таких серверов... То есть, известно что в такое-то время хэш UTXO должен быть именно таким, и никак иначе, и все не соответствующие этому правилу сервера можно предать анафеме. Как-то так.

[RoadTrain]

Разработчик Electrum (ThomasV) изначально был вдохновлен данной темой, и использовал этот подход на базе древовидной структуры в своем проекте. Правда, им не используется блокчейн для "запечатывания" хэшей текущего состояния.

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

Интересно, но Electrum слишком лёгкий клиент, в том плане, что слишком полагается на доверие серверам. Я не знаю в деталях его принципы работы, но полагаю, что несильно ошибаюсь.
Тут идея состоит в том, чтобы сделать легковесный клиент, который, тем не менее, мог бы проверять цепочку без необходимости излишне кому-либо доверять.
Чем-то напоминает развитие SPV-концепции, с добавленим загрузки и верификации UTXO set.

Надо бы как-то сподобиться и накидать примерный вариант реализации, потом оценить, надо ли оно вообще...

Electrum проверяет заголовки блоков, а состояние UTXO запрашивает у серверов. Смысл же цепочки снимков в том, что теоретически с её помощью можно принудительно унифицировать поведение таких серверов... То есть, известно что в такое-то время хэш UTXO должен быть именно таким, и никак иначе, и все не соответствующие этому правилу сервера можно предать анафеме. Как-то так.

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

[Balthazar]

Сеть полных нод в любом случае не пострадает. Однако, подобные клиенты будут способны проверить лишь PoW составляющую, а потому будут менее безопасными.

То есть, теоретическому злоумышленнику для обмана жертвы достаточно будет сгенерировать свою цепочку PoW блоков, привязав к ним фальшивые снимки состояния. Решить эту проблему можно, используя несколько параллельных подключений. К примеру, Electrum устанавливает 8 соединений с разными серверами. Вообще, использование множества серверов само по себе усложняет жизнь потенциальным любителям пошутить, даже без использования цепочки снимков .

P.S. Кстати, использование Electrum серьезно упрощает жизнь, перенес биткоиновый валлет на него на десктопе.