NovaCoin (scrypt PoW + PoS hybrid)

[Balthazar]

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

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

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

[ShadowAlexey]

Балти,а что мешает в целом ввести общий для всех клиентов набор условий, которые он может вычислять и на их основе определять мн-во доступных действий над транзакцией?)
Ex. Транзакция может быть использована для PoS или отправлена на адресс отправителя(тут нужно не допустить подмены понятий при PoS генерации)? Вроде все довольно тривиально.

[Balthazar]

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

[Reaver]

эх, а у меня сегодня аж 3 POS блока нашлось. Теперь врядли к конкурсу ещё один POS будет...

А у меня stakeweigth почти 6000 и 4й день без блоков сижу, хотя по моим расчетам шанс найти блок в течении суток более 40%.
Удача такая удача 

[Balthazar]

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

NovaCoin 0.4.4.7 bugfix2

• CORE: Исправлена ошибка с подсчетом комиссии в функции CreateTransaction();
• RPC: Добавлен вызов getsubsidy, позволяющий получить значение proof-of-work награды для текущего или заданного таргета;
• RPC: getmininginfo и getinfo теперь сообщают так же и текущее значение proof-of-stake сложности.

Исходные тексты: https://github.com/novacoin-project/novacoin

MacOS X dmg: link
Linux 64 bit static build: link

Windows nosetup: i686, AMD64
Windows installer: i686, AMD64

P.S. Помимо исправления ошибки данный билд включает в себя RPC вызов getsubsidy, который используется в новом p2pool.

Новый p2pool можно пощупать здесь:

https://github.com/0xDEADFACE/p2pool

Для основной сети цепочка не запущена пока, в тестнете же работать должно без проблем. Через getwork работает отлично, stratum пока не тестировался, но проблем быть не должно. Генезис шару сделаем чуть позже.

[Balthazar]

Через getwork работает отлично, stratum пока не тестировался, но проблем быть не должно. Генезис шару сделаем чуть позже.

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

Кстати, в новом p2pool шары в два раза более быстрые, чем в старом.

[Sibiryak]

NovaCoin 0.4.4.7 bugfix2 споткнулся на блоке #72808 (или 72809) дальше синхронизироваться не хочет.

добавление. если нужно, есть копия папки Novacoin из Roaming

[Balthazar]

Ты прав, что-то не так с пересчетом чексуммы stakemodifier и похоже, 0.4.4.7 все-таки решила нас убедить в том, что мы её рано зарелизили.

P.S. Линуксовая сборка считает модификаторы нормально. Похоже, что это что-то именно со сборкой, а не клиентом как таковым.

[Balthazar]

Проверка показала, что 32-битная Windows сборка тоже считает чексуммы корректно. Кроме того, 64-битная сборка тоже чаще всего работает корректно, но иногда нет.

Итого, 64-битные сборки клиента для Windows удалены, пока не выясним в чем дело. Если кто-то использовал 64-битную Windows сборку, настоятельно рекомендуется переехать на 32-битную, перекачав при этом блокчейн.

[yurm]

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

Это позволяет реализовать следующую схему:

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

Итоги просты:

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

Порекламировать что ли свой скрипт и размышления по этому поводу: https://bitcointalk.org/index.php?topic=439210.0 (см. Use cases).
Один нюанс:

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

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

[AlexRus227]

У меня счас комп зависает раз в сутки и после этого кошелек умирает  bklindex.dat вроде не может прочитать на 4.6 такие зависания не приводили к такой ошибке Посмотрим как на 4.7 фикс2 будут мои зависания сказываться =)

[Balthazar]

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

[svost]

@Balthazar

С утра обнаружил, что мой клиент 0.4.4.7 32bit подвис на блоке 72815. Перешёл сразу на версию bugfix2 с повторной закачкой цепочки. Debug.log сохранён - он представляет какой-либо интерес?

[awoland]

У меня 0.4.4.7 тоже "буксует" сегодня...

[Balthazar]

Думаю что уже знаю, что там увижу, но лучше все-таки скинь debug.log. Проблема плавающая и пока проявлялась только на Windows... Если используются версии 0.4.4.7 *, то  лучше проверять кошельки периодически на предмет умирания синхронизации. Или поставить 0.4.4.5/0.4.4.6 и забыть пока об этом.

[awoland]

Ничего подобного. Не только под Windows. У меня самособранный rpm CentOS 6.4 64-bit из v0.4.4.7-nvc: v0.4.4.7 release. Тоже "буксует"...

[AlexRus227]

Да подтверждаю фикс2 буксует на Осталось 10 блоков

PS по железу я знаю что глючит но нужна работать именно на таком =( Валеты все забыкаплены =) так что есл все сдохнет не проблема

[Balthazar]

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

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

Отправляйте debug.log, если кто столкнулся, надо собирать статистику.

[Reaver]

Вернулся на 0.4.4.6, а всё равно пишет "downgrade to 0.4.4.6" - можно не реагировать?

[Balthazar]

Вернулся на 0.4.4.6, а всё равно пишет "downgrade to 0.4.4.6" - можно не реагировать?

Да, можно игнорировать.