Author

Topic: NovaCoin (scrypt PoW + PoS hybrid) - page 126. (Read 600924 times)

donator
Activity: 968
Merit: 1002
February 12, 2014, 07:30:07 AM
Почему-то вылазит сообщение «URGENT: your client is possibly affected by synchronization issues. Please downgrade to 0.4.4.6 as possible.»
Хотя версия и так 0.4.4.6, причём после переустановки свежескачанного клиента сообщение вернулось. С этим как-то связано то, то 67-монетный инпут двадцатый день не может найти блок?)
Никак, просто сообщение от "создателя"(читай Бальтазара), если ты обновился то все хорошо.
newbie
Activity: 5
Merit: 0
February 12, 2014, 07:28:49 AM
Почему-то вылазит сообщение «URGENT: your client is possibly affected by synchronization issues. Please downgrade to 0.4.4.6 as possible.»
Хотя версия и так 0.4.4.6, причём после переустановки свежескачанного клиента сообщение вернулось. С этим как-то связано то, то 67-монетный инпут двадцатый день не может найти блок?)
donator
Activity: 968
Merit: 1002
February 12, 2014, 07:27:46 AM
В первое время возможно не банить,а нормализовывать, так будет обеспечена совместимость со старыми клиентами. А потом, спустя какое то время запретить вовсе. Так новые клиенты смогут однозначно идентифицировать транзакции, что в целом есть гут. Ну и не забывать при передаче автоматически "исправлять" содержимое, так у старых клиентов будут дабл спенды, но учитывая масштаб проблемы, имхо все терпимо.
Мы занимаемся перебором хешей для PoW, имхо добавление нескольких вычислений, не самое страшное зло) Вряд ли сильно замедлит работу на современных пк.
legendary
Activity: 3108
Merit: 1359
February 12, 2014, 07:22:50 AM
Разумное решение - из двух вариантов всегда использовать тот, что дает меньшее значение при хэшировании функцией sha256, а за отправку "неправильных" подписей банить. Тогда все подписи будут существовать в единственно возможном экземпляре.

Но есть и недостаток, это замедлит работу.
donator
Activity: 968
Merit: 1002
February 12, 2014, 07:14:14 AM
Не вижу проблемы проверить как обычный так и зеркальный вариант), да и вообще считать их идентичными). Например всегда брать по "модулю"(вот только хз возможно ли понять, какой из вариантов зеркальный).
Например выбрать "наименьший" из пары хешей. Кстати а что вообще мешает ввести это ограничение сразу, из пары хешей "минимальный" является истинным? И взять потом хеш из нормализованного упорядоченного набора(то что писал выше) в качестве ID транзакции?
legendary
Activity: 3108
Merit: 1359
February 12, 2014, 07:07:25 AM
Может, можно даже реализовать прокси, который будет отзеркаливать подписи во всех получаемых транзакциях, такое даже вроде делали в 2011 году. Smiley

Если подписывать подпись и так далее, то промежуточные подписи изменить будет действительно нельзя. Однако, можно вычислить зеркальный вариант для финального результата, так что имеет смысл использовать для вычисления txid не эту подпись, а заверенные ей данные.
donator
Activity: 968
Merit: 1002
February 12, 2014, 06:57:07 AM
Так разве не владелец сможет сделать обратную подпись?
А если такой ход, вся транзакция последовательно подписывается каждым ключем(их набор упорядочен),каждая следующая подпись включает транзакцию и предыдущие подписи?
legendary
Activity: 3108
Merit: 1359
February 12, 2014, 06:38:24 AM
А что мешает брать хеш из упорядоченного набора подписей? Их нельзя заменить.
Подписи изменить можно. Точнее не изменить, а заменить на эквивалент:

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

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

Кстати, это можно использовать для кодирования данных в блокчейне, либо передаче сигнала кому-нибудь... Надо только договориться с другой стороной о порядке чередования вариантов, и канал готов.
donator
Activity: 968
Merit: 1002
February 12, 2014, 06:24:10 AM
А что мешает брать хеш из упорядоченного набора подписей? Их нельзя заменить.
legendary
Activity: 3108
Merit: 1359
February 12, 2014, 04:50:46 AM
После 'большую часть' стало грустно читать...
Большую часть - это все варианты, связанные с модификацией именно скриптов. Это имеет смысл, потому что модификация скриптов может быть использована не только для двойных трат, но и для DoS атак на сервисы.

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

Т.е. может быть добавить в атрибуты транзакции выводимые rpc булевский флаг - уже потраченные входы 'spentinputs:true/false', если оно true то можно считать что транзакция потрачена
Естественно, подобный флаг для записи при выводе списка транзакций нужно сделать. Однако, наличие подобного флага не означает, что не нужно фильтровать мусор.  Roll Eyes
legendary
Activity: 1120
Merit: 1069
February 12, 2014, 04:21:46 AM
После 'большую часть' стало грустно читать...
А можно попытаться разработать не полумеру?

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

Т.е. может быть добавить в атрибуты транзакции выводимые rpc булевский флаг - уже потраченные входы 'spentinputs:true/false', если оно true то можно считать что транзакция потрачена (единственный кто может это сделать неправильно, т.е. не все а только часть - владелец кошелька, значит инструментарий достаточен)
legendary
Activity: 3108
Merit: 1359
February 12, 2014, 04:08:00 AM
Не могу понять, от чего и как это защищает?
Суть в том, что алгоритм подписывания скриптов позволяет модифицировать скрипт таким образом, чтобы хэш транзакции изменился при сохранении корректности её подписи.

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

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

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

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

В каких случаях это нужно использовать?
Включено по умолчанию, может быть отключено по желанию.

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

P.S. Bitcoin пулы в данный момент постепенно применяют идентичный набор правил определения стандартности/нестандартности скрипта, Eligius один из первых.
legendary
Activity: 1120
Merit: 1069
February 12, 2014, 03:32:44 AM
Не могу понять, от чего и как это защищает? Это выставляет более строгие правила на определение, стандартная ли транзакция или нет? А зачем? В каких случаях это нужно использовать?
legendary
Activity: 3108
Merit: 1359
February 12, 2014, 12:06:37 AM
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
full member
Activity: 224
Merit: 100
February 11, 2014, 11:41:55 PM
И всё же какова сейчас вероятность намайнить PoS блок за день? Как посчитать?
https://bitcointalksearch.org/topic/novacoin-scrypt-pow-pos-hybrid-114712
Спасибо большое!
Выходит, в прошлый раз когда я впервые запустил майнинг PoS и за несколько часов намайнил блок - мне просто чертовски повезло, на самом деле нормально ждать неделями...
legendary
Activity: 1596
Merit: 1011
February 11, 2014, 04:45:04 PM
Напомни плиз какую оптимальную сумму стоит "склеивать" для ловли POS блоков, а то я просто не найду в этой теме этого)) ? Мне вроде запомнилось то ли 60, то ли 80...

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

Спасибо, короче надо пользоваться таблицей, которую запостили выше...
legendary
Activity: 1200
Merit: 1021
February 11, 2014, 04:14:09 PM
Напомни плиз какую оптимальную сумму стоит "склеивать" для ловли POS блоков, а то я просто не найду в этой теме этого)) ? Мне вроде запомнилось то ли 60, то ли 80...

Оптимальная сумма зависит от PoS-сложности. При нынешней сложности 0,2 и выше можно делать выходы до 150 NVC, у них будет ~15 дней, чтобы сгенерировать блок, и награда не превысила бы 10 NVC Smiley
legendary
Activity: 1596
Merit: 1011
February 11, 2014, 03:51:31 PM
Думаю дело не в разрядности, а версиях. Roll Eyes

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

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

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

Да там не разберешься, просто майнит неделю, а потом пишет что сиджимайнер будет закрыт так как бла бла бла. Запускаешь его по новой, комп уходит в ребут, а потом при перезагрузке пишет что был блускрин. Может сиджимайнер глючит, может видяха какая-та помирает, хз...
legendary
Activity: 3108
Merit: 1359
February 11, 2014, 03:48:39 PM
Думаю дело не в разрядности, а версиях. Roll Eyes

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

В будущих версиях NVC для wallet.dat планируется перейти на синхронные, что уменьшит вероятность подобных событий. Но, в любом случае, бороться надо не со следствием, а причиной т.е. бсодами.
legendary
Activity: 1596
Merit: 1011
February 11, 2014, 03:35:51 PM
Почему после блускрина кошель отказывается запускаться и настойчиво предлагает удалить всю БД, клиент битка и лайта таким не страдает !?



Сорри, оказывается у меня образовалось два клиента, один 32битный, а второй 64битный, забыл удалить старый и тыкал по нему, а цепочка уже не подходит от нового клиента.
Jump to: