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

[penek]

@svost Спасибо.
Собрать получилось по инструкции в ссылке выше.
Penek, может стОит поправить инструкцию на https://wiki.novaco.in/ru/BuildAndInstall ?

обновим

[7Pay.in]

просьба потестить обмен новакоинов на что-нибудь и наоборот - лайтов например на новы (правда их щас нет на сервисе)
https://7pay.in/to_coin

вижу кто-то 12 новы поменял на биткоины
я комиссию поуменьшил до 1%

Тестим. Баланс сайта в новах обновляется почти сразу или после 1 подтверждения. Битки идут. Только вместо 0.05 --> 0.0499. Мне не принципиально, но правильно сразу закладывать все сборы, ведь могут менять на определённые цели конкретную сумму. А сумма заказывалась именно 0.05.

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

[in100]

В клиенте есть вкладка POS, а там - столбец Вероятность POS. Мне кажется в нём нет смысла, т.к. из scaninput достоверно известно, когда это случится.
Может там отображать дату/время, когда ожидается ближайший POS для текущей сложности.

Я думаю, лучше добавить в контекстное меню на этой вкладке пункт "Scan input" с упрощённым режимом работы:
- расчёт вести только для выбранного выхода;
- использовать текущую сложность;
- искать только первый подходящий хэш.
Результат выводить в диалоговом окне с одной-единственной кнопкой ОК.

Всё-таки функция scaninput полезней всего владельцам небольшого числа выходов, а в таком случае несложно подойти индивидуально к каждому из них

[Dimanoid]

 Учитывая, что выходы часто делятся (бывает, до довольно мелких значений, в каких-нибудь 5 монет) - тем, у кого выходов сотня тоже вполне полезно будет. Ведь по мелким часто ближайший POS лежит за рубежом в пол-года.
 И всё же правильней, чтобы результаты scaninput сохранялись и отображались в будущем. Тем более, если рядом будет и максимальная POS-сложность для этого события. Ведь часто сложности хватает с запасом, и дата POS уже не изменится! Зачем терять данные и потом снова давить кнопку расчёта?
 Также странно на мой взгляд отказываться от такого удобства и создавать отдельную таблицу самому - если это можно сделать во вкладке POS.

[Balthazar]

Немного тестов.

Команда:

Code:

scaninput '{"txid" : "bdd760e6d7d957f5d68ff1464307db69e35be9c5e0cdfa21649276563226023b", "days" : 365}'

Реализация  Железка                                Платформа          Кол-во потоков       Время
Generic         Xeon E5 2658v2 @ 2.4 GHz     Win64                    20                       10s
AVX              Xeon E5 2658v2 @ 2.4 GHz     Linux64                  4                        10s
SSE4            Xeon E5 2658v2 @ 2.4 GHz     Linux64                  4                        10-11s
SSE4            Core i7 970 @ 3.2 GHz        Linux64                  12                      5s

Боюсь себе представить, сколько выдаст Xeon c 20 потоками под линуксом... В общем, над причинами этого дисбаланса надо что-то думать.

[svost]

Дополню таблицу MSVC сборка + yasm

Команда:

Code:

scaninput '{"txid" : "bdd760e6d7d957f5d68ff1464307db69e35be9c5e0cdfa21649276563226023b", "days" : 365}'

Реализация  Железка                                Платформа          Кол-во потоков       Время
Generic         Xeon E5410 @ 2.33 GHz        Win64                  4                      30s
SSE4            Xeon E5410 @ 2.33 GHz        Win64                  4                      15s

[Balthazar]

Заменил реализацию на вытащенную из cpuminer и слегка допиленную:

SSE2 4way          Core i7 970 @ 3.2 GHz        Linux64                  12                      3s

Что-то как-то 4way не особенно чуствуется в сравнении с честно-одноблочным интеловским алгоритмом.

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

[Balthazar]

AVX 4way          Xeon E5 2658v2 @ 2.4 GHz        Win64                  20                      2s

Так и до психологической отметки 1s недалеко.

Обновленный билд:

http://sourceforge.net/projects/novacoin/files/novacoin-test/novacoin-test-v0.5.4-50.7z/download

[FAN]

< 1s
 

[in100]

Скачал билд novacoin-test-v0.5.4-50 (предыдущие не пробовал). По-моему, scaninput не реагирует на изменение сложности:

Code:

scaninput '{"txid" : "bdd760e6d7d957f5d68ff1464307db69e35be9c5e0cdfa21649276563226023b", "vout" : [0, 1], "difficulty" : 2000, "days" : 90}'

[
{
"nout" : 0,
"hash" : "00000e6a31812f69b87977d77ad723648a076850021da3c1959c67bd637d2378",
"time" : "2015-12-27 09:49:15 UTC"
},
{
"nout" : 1,
"hash" : "00000aa904facb147ed5187ced7e9de1c184085751765635caa174c0de856cdd",
"time" : "2015-12-04 16:43:30 UTC"
},
{
"nout" : 1,
"hash" : "00000db40c00bd71f90ff4d47c1954456893fdc487203ee7f3ff2af5ecb55160",
"time" : "2016-01-06 06:41:22 UTC"
}
]

[Balthazar]

Реагирует, просто сложность там задана строго как число с плавающей точкой, что некорректно. Т.е. если вместо 2000  написать 2000.0, тогда поймет и не будет подставлять текущую.

Будет исправлено в ближайшем билде.

[Balthazar]

SSE2 4way          Core i7 970 @ 3.2 GHz        Linux64                  12                      3s

Благодаря pshufb теперь 2s.

Реагирует, просто сложность там задана строго как число с плавающей точкой, что некорректно. Т.е. если вместо 2000  написать 2000.0, тогда поймет и не будет подставлять текущую.

Будет исправлено в ближайшем билде.

Исправлено.

http://sourceforge.net/projects/novacoin/files/novacoin-test/novacoin-test-v0.5.4-53.7z/download

Пока сборки только 64 бит, 32 бит будет позжетеперь в архиве есть и 32 бит сборки.

[Dimanoid]

Последние оптимизации scaninput касаются только многоядерных процессоров? Потому как на Core2 (4 ядра) скорость утроилась, а на одноядерном Sempron осталась без изменений (хотя тоже SSE2 поддерживает).

[Balthazar]

Видимо, у Sempron нет SSSE3.

Кроме того, на тех же AMD K8 часто бывает, что использование SSE2 не дает толком никакого прироста, так что на чем-то вроде Celeron D351 выросло бы где-то в 2.5-3 раза как раз. Пожалели транзисторов на SIMD блоки, очевидно, жаль что они только в K10 додумались это хоть как-то исправить.

Собственно, именно отсутствие оптимизированных под SSE2 приложений и выручило AMD в своё время, ведь многие современные приложения на AMD K8 работают медленнее, чем на их современниках от Intel, хотя для приложений того времени всё было совсем наоборот. Впрочем, по современным меркам и там и там они тормозят так, что разница в 2-3 раза не играет уже никакой роли.

[Balthazar]

Дополню таблицу MSVC сборка + yasm

Команда:

Code:

scaninput '{"txid" : "bdd760e6d7d957f5d68ff1464307db69e35be9c5e0cdfa21649276563226023b", "days" : 365}'

Реализация  Железка                                Платформа          Кол-во потоков       Время
Generic         Xeon E5410 @ 2.33 GHz        Win64                  4                      30s
SSE4            Xeon E5410 @ 2.33 GHz        Win64                  4                      15s

AVX             Core i5 2520M @ 2.5 GHz          Win64               4            8s

[Dimanoid]

То есть, если я правильно понял - сейчас для scaninput автоматически выбирается SSE2, SSE4 либо AVX - в зависимости от того, что поддерживает процессор? Тогда у меня выходит:
Реализация             Железка                         Платформа          Кол-во потоков       Время
SSE4            Core 2 Quad Q9550 2.833GHz            Win64                     4                    30s
SSE2 + SSSE3                                                                                                      26s
Upd: 30s было, видимо, под небольшой нагрузкой (проц ещё чем-то был занят).

[narousberg]

Что означает "Network Weight" в кошельке? Значение постоянно меняется

[Balthazar]

То есть, если я правильно понял - сейчас для scaninput автоматически выбирается SSE2, SSE4 либо AVX - в зависимости от того, что поддерживает процессор? Тогда у меня выходит:
Реализация             Железка                         Платформа          Кол-во потоков       Время
SSE4            Core 2 Quad Q9550 2.833GHz            Win64                     4                    30s

SSE4 функции в клиенте нет, то было просто для экспериментов. Сейчас клиент имеет SSE2, AVX и XOP 4way реализации SHA256. Опционально ещё включается обработка промежуточных результатов с помощью SSSE3, если доступно. Соответственно, в выше приведенном примере использовалась хэш-функция на базе SSE2 + переворачивание промежуточного хэша инструкцией pshufb.

30s это все-таки долго, а сколько было раньше?

Что означает "Network Weight" в кошельке? Значение постоянно меняется

Оценка совокупной мощности всех PoS майнеров, в монето-днях-в-секунду.

[Dimanoid]

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

Ну и ещё SSSE3 тоже должно поучаствовать было (начиная с Core2 Duo)

30s это все-таки долго, а сколько было раньше?

До последних обновлений (но когда scaninput уже стала многопоточной) - 85 или 95 секунд, забыл уже. Я ещё прикинул, что где-то втрое ускорилось.

[Balthazar]

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

Ну и ещё SSSE3 тоже должно поучаствовать было (начиная с Core2 Duo)

SSSE3 для pshufb как раз и нужно. Собственно, непосредственно в хэшировании участия не принимает, но помогает.

Дело в том, что хэширование делается два раза, как и для всех остальных сущностей (транзакций, заголовков блоков и так далее). При этом, на вход второму вызову данной реализации функции нельзя передать просто результат первого, его надо передать в перевернутом виде. Т.е. sha256(sha256(x)) на практике в этом случае выглядит как-то вроде sha256(swap(sha256(x))).

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

К сожалению, это всё верно только для x86/x86_64, на ARM это узкое место сохраняется и потому более чем двухкратный прирост от недавних оптимизаций вряд ли возможен несмотря на то, что есть возможность считать 4 хэша за раз. В принципе, там есть SIMD набор инструкций под названием NEON, в котором могут быть подобные команды для пакетного переворачивания. Но я понятия не имею, что там и к чему, надо читать даташиты.