NovaCoin (scrypt PoW + PoS hybrid)

[Balthazar]

Думаю дело не в разрядности, а версиях.

Вообще ещё как страдают, просто пока везет. Биткоин и все основанные на нем клиенты используют асинхронные коммиты, а потому любое неожиданное завершение работы может закончиться фатально для базы данных.

В будущих версиях NVC для wallet.dat планируется перейти на синхронные, что уменьшит вероятность подобных событий. Но, в любом случае, бороться надо не со следствием, а причиной т.е. бсодами.

[qqqq]

Думаю дело не в разрядности, а версиях.

Скорее всего.

Напомни плиз какую оптимальную сумму стоит "склеивать" для ловли POS блоков, а то я просто не найду в этой теме этого)) ? Мне вроде запомнилось то ли 60, то ли 80...

Но, в любом случае, бороться надо не со следствием, а причиной т.е. бсодами.

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

[in100]

Напомни плиз какую оптимальную сумму стоит "склеивать" для ловли POS блоков, а то я просто не найду в этой теме этого)) ? Мне вроде запомнилось то ли 60, то ли 80...

Оптимальная сумма зависит от PoS-сложности. При нынешней сложности 0,2 и выше можно делать выходы до 150 NVC, у них будет ~15 дней, чтобы сгенерировать блок, и награда не превысила бы 10 NVC

[qqqq]

Напомни плиз какую оптимальную сумму стоит "склеивать" для ловли POS блоков, а то я просто не найду в этой теме этого)) ? Мне вроде запомнилось то ли 60, то ли 80...

Оптимальная сумма зависит от PoS-сложности. При нынешней сложности 0,2 и выше можно делать выходы до 150 NVC, у них будет ~15 дней, чтобы сгенерировать блок, и награда не превысила бы 10 NVC

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

[boinc]

И всё же какова сейчас вероятность намайнить PoS блок за день? Как посчитать?

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

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

[Balthazar]

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

https://en.bitcoin.it/w/images/en/e/e1/TxBinaryMap.png

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

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

Действительно на счет подмены po_code нашел инфу:
https://en.bitcoin.it/wiki/Transaction_Malleability
буду проверять.
Спасибо за ответ, но в дейсвительности проблема исключительно биржи которая проверяет вывод денег путем поиска хеша транзакции в блоках.

Патч:

https://github.com/novacoin-project/novacoin/commit/0c80f9494715c7dacd6c74a6a56092b416a4d60d

[rPman]

Не могу понять, от чего и как это защищает? Это выставляет более строгие правила на определение, стандартная ли транзакция или нет? А зачем? В каких случаях это нужно использовать?

[Balthazar]

Не могу понять, от чего и как это защищает?

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

Это открывает злоумышленникам путь к мошенничеству по следующей схеме:

• Запрашиваем вывод;
• Модифицируем транзакцию так, чтобы её хэш поменялся;
• Делаем попытку отправки модифицированного варианта в сеть через ноду, имеющую хорошую связность;
• Если подтвердился оригинальный вариант транзакции, делаем попытку снова.

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

Это выставляет более строгие правила на определение, стандартная ли транзакция или нет?

Именно так. Эти правила позволяют отфильтровать большую часть возможных вариантов модификаций. В том числе и тех, которые "в ходу" при текущей атаке на сеть Bitcoin.

В каких случаях это нужно использовать?

Включено по умолчанию, может быть отключено по желанию.

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

P.S. Bitcoin пулы в данный момент постепенно применяют идентичный набор правил определения стандартности/нестандартности скрипта, Eligius один из первых.

[rPman]

После 'большую часть' стало грустно читать...
А можно попытаться разработать не полумеру?

Вместо того, чтобы пытаться выявить такие 'вторые' транзакции, может быть разработать инструментарий гарантированного определения, ушли ли деньги, отосланные транзакции txid, или нет?
Отличным примером может послужить условие - если хотя бы один выход транзакции потрачен, то эта транзакция не будет подтверждена (естественно при использовании необходимо дождаться X подтверждений а не первое включение в блок).

Т.е. может быть добавить в атрибуты транзакции выводимые rpc булевский флаг - уже потраченные входы 'spentinputs:true/false', если оно true то можно считать что транзакция потрачена (единственный кто может это сделать неправильно, т.е. не все а только часть - владелец кошелька, значит инструментарий достаточен)

[Balthazar]

После 'большую часть' стало грустно читать...

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

А все полностью отфильтровать в любом случае не выйдет, хотя бы потому что для корректной ECDSA подписи (r,s) будет существовать эквивалентная ей подпись (r, -s (mod N)). И она будет иметь ту же длину, но другой хэш.  

Т.е. может быть добавить в атрибуты транзакции выводимые rpc булевский флаг - уже потраченные входы 'spentinputs:true/false', если оно true то можно считать что транзакция потрачена

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

[ShadowAlexey]

А что мешает брать хеш из упорядоченного набора подписей? Их нельзя заменить.

[Balthazar]

А что мешает брать хеш из упорядоченного набора подписей? Их нельзя заменить.

Подписи изменить можно. Точнее не изменить, а заменить на эквивалент:

А все полностью отфильтровать в любом случае не выйдет, хотя бы потому что для корректной ECDSA подписи (r,s) будет существовать эквивалентная ей подпись (r, -s (mod N)). И она будет иметь ту же длину, но другой хэш.  

Оригинал (r,s) и "зеркальный" вариант подписи (r, -s (mod N)) будут проходить валидацию одним и тем же публичным ключом. В результате, количество возможных вариантов транзакции будет очень быстро расти с увеличением количества подписей. И все эти варианты будут полностью корректны.

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

[ShadowAlexey]

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

[Balthazar]

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

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

[ShadowAlexey]

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

[Balthazar]

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

Но есть и недостаток, это замедлит работу.

[ShadowAlexey]

В первое время возможно не банить,а нормализовывать, так будет обеспечена совместимость со старыми клиентами. А потом, спустя какое то время запретить вовсе. Так новые клиенты смогут однозначно идентифицировать транзакции, что в целом есть гут. Ну и не забывать при передаче автоматически "исправлять" содержимое, так у старых клиентов будут дабл спенды, но учитывая масштаб проблемы, имхо все терпимо.
Мы занимаемся перебором хешей для PoW, имхо добавление нескольких вычислений, не самое страшное зло) Вряд ли сильно замедлит работу на современных пк.

[aceltradegid]

Почему-то вылазит сообщение «URGENT: your client is possibly affected by synchronization issues. Please downgrade to 0.4.4.6 as possible.»
Хотя версия и так 0.4.4.6, причём после переустановки свежескачанного клиента сообщение вернулось. С этим как-то связано то, то 67-монетный инпут двадцатый день не может найти блок?)

[ShadowAlexey]

Почему-то вылазит сообщение «URGENT: your client is possibly affected by synchronization issues. Please downgrade to 0.4.4.6 as possible.»
Хотя версия и так 0.4.4.6, причём после переустановки свежескачанного клиента сообщение вернулось. С этим как-то связано то, то 67-монетный инпут двадцатый день не может найти блок?)

Никак, просто сообщение от "создателя"(читай Бальтазара), если ты обновился то все хорошо.

[Balthazar]

С этим как-то связано то, то 67-монетный инпут двадцатый день не может найти блок?)

Никак не связано. Это просто вручную отправленное сообщение, и не более того.

Хотя версия и так 0.4.4.6

Если версия и так 0.4.4.6, то можно игнорировать. Если не хочется больше видеть это сообщение, то поставить 0.4.4.6-update1 и оно сгинет. 0.4.4.6 update1 можно взять там же, где лежит 0.4.4.6:

http://sourceforge.net/projects/novacoin/files/

Вообще, похоже 0.4.4.6 давно удалить пора оттуда во избежание путаницы.

P.S. так и поступил, файлы 0.4.4.6 удалены со страницы.