Topic: NovaCoin (scrypt PoW + PoS hybrid) - page 151. (Read 600924 times)
Если клиент версий ниже 0.4.4.5, то его нужно обновить. Больше ничего делать не нужно. Выдаваемое версией 0.4.4.5 предупреждение можно игнорировать.
Balthazar
можете ли посоветовать как подключиться к правильному блокчейну, если вдруг произошло разделение цепи и мой кошелек оказался в альтернативной цепочке?
Достаточно ли будет скачать правильную базу блоков?
можете ли посоветовать как подключиться к правильному блокчейну, если вдруг произошло разделение цепи и мой кошелек оказался в альтернативной цепочке?
Достаточно ли будет скачать правильную базу блоков?
Прааастите, дяденька. Забыл написать волшебное слово ИМХО, которое сразу снимает всю ответственность за слова 
Видео-инструкции - полный идиотизм... лучше просто по пунктам расписать.
Там были отладочные заглушки, после их удаления остался перевод строки по фен-шую 
В тестовой ветке обнаружена возможная/плавающая/несуществующая ошибка, возможно приводящая к отклонению блока #69484 (сообщение "VerifySignature failed on coinstake" в логфайле, воспроизвести пока не удалось). В связи с этим сборки из next ветки временно удалены.
Баг был очень злой и хитрый Проявлялся практически гарантированно, но крайне редко. Однако, все же путем сравнения баз умершего и живого клиентов удалось найти и устранить причину. 
Кому нибудь удалось решить проблему потери связи p2pool с кошельком? Или это только у меня вылетает ошибка "Warning: LOST CONTACT WITH BITCOIND for 1.0 minutes! Check that it isn't frozen or dead!"?
Косяк в cgminer, который не корректно закрывает коннекты и забивает пул коннектов у p2pool. Вопрос уже много раз обсуждался. Используйте bfgminer.
Кому нибудь удалось решить проблему потери связи p2pool с кошельком? Или это только у меня вылетает ошибка "Warning: LOST CONTACT WITH BITCOIND for 1.0 minutes! Check that it isn't frozen or dead!"?
Загружаться должна libgcc из комплекта компилятора, которым собирался сам mingw64, либо совместимая с ней. К версии самого mingw она отношения при этом не имеет.
Если компилятор собирался GCC 4.8.2, то и libgcc должна загружаться соответствующей ветки... К примеру, если собрать программу с помощью GCC 4.9 и скормить ей рантайм от 4.8, то с высокой вероятностью ничего хорошего из этого не выйдет. В лучшем случае неработоспособность приложения, в худшем - мнимая работоспособность с крэшами в ответственный момент.
Какой версией GCC собирался mingw64? Может, имеет смысл пересобрать дистрибутивным компилятором, если официального пакета нет? Скрипты сборки по идее должны быть доступны слаковские.
Хотя, можно и полностью самому собрать:
http://pete.akeo.ie/2010/07/compiling-mingw-w64-with-multilib-on.html
Раньше собранным таким образом компилером пользовался, пока не переехал на дебиан. Кстати, чтобы не мучиться особенно, можно попробовать ограничиться сборкой binutils, ведь сам по себе компилятор функционирует нормально, как я понимаю.
Если компилятор собирался GCC 4.8.2, то и libgcc должна загружаться соответствующей ветки... К примеру, если собрать программу с помощью GCC 4.9 и скормить ей рантайм от 4.8, то с высокой вероятностью ничего хорошего из этого не выйдет. В лучшем случае неработоспособность приложения, в худшем - мнимая работоспособность с крэшами в ответственный момент.
Какой версией GCC собирался mingw64? Может, имеет смысл пересобрать дистрибутивным компилятором, если официального пакета нет? Скрипты сборки по идее должны быть доступны слаковские.
Хотя, можно и полностью самому собрать:
http://pete.akeo.ie/2010/07/compiling-mingw-w64-with-multilib-on.html
Раньше собранным таким образом компилером пользовался, пока не переехал на дебиан. Кстати, чтобы не мучиться особенно, можно попробовать ограничиться сборкой binutils, ведь сам по себе компилятор функционирует нормально, как я понимаю.
На скрине видно, что ld кросс-компилера ссылается на либу /usr/lib64/libgcc_s.so.1 компилятора в родительской системе, там установлена версия 4.8.2. Это нормально? Если нет, то как мне выйти из этого положения? Официального пакета x86_64-w64-mingw32 для Slackware нет, поэтому просто вручную копирую бинарники кросс-компилятора в /usr/local, удаляю полным удалением каталога /usr/local.
По идее нет, у mingw64 отдельный набор утилит. Просто они что-то со сборкой ld перемудрили.
В тестовой ветке обнаружена возможная/плавающая/несуществующая ошибка, возможно приводящая к отклонению блока #69484 (сообщение "VerifySignature failed on coinstake" в логфайле, воспроизвести пока не удалось). В связи с этим сборки из next ветки временно удалены.
обновился, все хорошо, ну что то очень быстро синхронизировалось минут за 30-40, буквально на днях делал базу с нуля часа2.
2 часа это как-то странно, у меня еще 0.4.4 на ARM с тормозной флэшкой в 55 минут и то укладывался.В тестовой ветке обнаружена возможная/плавающая/несуществующая ошибка, возможно приводящая к отклонению блока #69484 (сообщение "VerifySignature failed on coinstake" в логфайле, воспроизвести пока не удалось). В связи с этим сборки из next ветки временно удалены.
Каталог от старых объектных файлов, созданных 4.9, очищался?
Вообще странно, что линкер так умирает. Думаю, стоит отпостить багрепорт мейнтейнерам дистрибутива, им было бы полезно знать об этом. Скорее всего, что-то не так со сборкой самого ld, я такое наблюдал, когда пытался использовать нестабильный срез gcc и binutils.
Мы используем debian и ubuntu, в комбинации с дистрибутивным mingw-w64 g++/gcc 4.6.3 для сборки зависимостей и самого клиента. На мой взгляд, самая стабильная сборка mingw-w64 именно у дебиана.
Интересно, что при кросс-сборке db-4.8.30.NC попутные win-экзешники утилит базы данных нормально собираются. Пробовал уже и 4.7.х, и 4.8.2, и 4.9.0 - тот же результат. Хотя 4.6.3 да, наиболее чисто собирает, ни одного варнинга. Видимо нужен апгрейд/даунгрейд слакваровского gcc? Вообще странно, что линкер так умирает. Думаю, стоит отпостить багрепорт мейнтейнерам дистрибутива, им было бы полезно знать об этом. Скорее всего, что-то не так со сборкой самого ld, я такое наблюдал, когда пытался использовать нестабильный срез gcc и binutils.
Мы используем debian и ubuntu, в комбинации с дистрибутивным mingw-w64 g++/gcc 4.6.3 для сборки зависимостей и самого клиента. На мой взгляд, самая стабильная сборка mingw-w64 именно у дебиана.
обновился, все хорошо, ну что то очень быстро синхронизировалось минут за 30-40, буквально на днях делал базу с нуля часа2.
https://bitcointalksearch.org/topic/m.4594114
Новые тестовые сборки. Что дают, вкратце:
Имейте в виду, что было много изменений в реализации базового функционала, и потому возможно наличие пока не найденных багов.
// апдейт - похоже, в тестнете stake майнер иногда ведет себя странно в этой сборке. Предположу, что дело в маленьком количестве активных нод, но надо разобраться.
Сборки заменены. Новые тестовые сборки. Что дают, вкратце:
- База UTXO вместо полного индекса транзакций (аналогично Bitcoin, но не во всем);
- Пакетное добавление транзакций в БД (пачками по 5000 штук);
- Транзакции сортируются по дате, а не статусу;
- Функция repairwallet теперь удаляет из него орфаны.
Имейте в виду, что было много изменений в реализации базового функционала, и потому возможно наличие пока не найденных багов.
// апдейт - похоже, в тестнете stake майнер иногда ведет себя странно в этой сборке. Предположу, что дело в маленьком количестве активных нод, но надо разобраться.
- Больше не добавляем записи о coinbase транзакциях PoS блоков в индекс (сэкономит приблизительно ~4мб при текущей длине цепи);
- Исправлены известные на сегодня баги (установка coinstake флага и таймстампов на записи при восстановлении, проверка актуальности текущего best hash в PoS майнере).
UPDATE: Обнаружен новый баг, приводящий к невозможности принятия в цепочку блока #69484. В связи с этим сборки из next ветки непригодны к употреблению до тех пор, пока не будет найдена и устранена причина.
Каталог от старых объектных файлов, созданных 4.9, очищался?
Вообще странно, что линкер так умирает. Думаю, стоит отпостить багрепорт мейнтейнерам дистрибутива, им было бы полезно знать об этом. Скорее всего, что-то не так со сборкой самого ld, я такое наблюдал, когда пытался использовать нестабильный срез gcc и binutils.
Мы используем debian и ubuntu, в комбинации с дистрибутивным mingw-w64 g++/gcc 4.6.3 для сборки зависимостей и самого клиента. На мой взгляд, самая стабильная сборка mingw-w64 именно у дебиана.
Вообще странно, что линкер так умирает. Думаю, стоит отпостить багрепорт мейнтейнерам дистрибутива, им было бы полезно знать об этом. Скорее всего, что-то не так со сборкой самого ld, я такое наблюдал, когда пытался использовать нестабильный срез gcc и binutils.
Мы используем debian и ubuntu, в комбинации с дистрибутивным mingw-w64 g++/gcc 4.6.3 для сборки зависимостей и самого клиента. На мой взгляд, самая стабильная сборка mingw-w64 именно у дебиана.
с 4.6.3 то же самое
Для кросс-компиляции нужен mingw-w64 g++ 4.6.x. Более новые пока не годятся, т.к. там требуется более строгое соответствие стандарту.
Кроме того, сам по себе gcc 4.9 не блещет стабильностью.
Кроме того, сам по себе gcc 4.9 не блещет стабильностью.
Можете по скрину подсказать, в чём у меня ошибка при кросс-компиляции демона в линуксе для Win64?
Можно и в тестовых сборках так и сделано... Просто 0.4.4.6 выпускалась в авральном режиме в новый год, пришлось много кого разбудить. А потому было не до красивостей.
А потому было не до красивостей. Jump to: