Доработка официального клиента.

[[Tycho]]

Вообще любая версия "официального" биткойн-клиента, в том числе и Qt - очень сатошистая.
Основное ядро, работа с БД, сетевой код и.т.п. - в основном осталось от клиента Сатоши. Да, там добавлены багфиксы и секьюрити-фиксы, но принцип тот же. И в том числе - вещи, которые "так сделал Сатоши, но мы не знаем, почему именно".

[Azrace]

Вообще любая версия "официального" биткойн-клиента, в том числе и Qt - очень сатошистая.
Основное ядро, работа с БД, сетевой код и.т.п. - в основном осталось от клиента Сатоши. Да, там добавлены багфиксы и секьюрити-фиксы, но принцип тот же. И в том числе - вещи, которые "так сделал Сатоши, но мы не знаем, почему именно".

это плохо?

[ShadowAlexey]

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

[[Tycho]]

Вообще любая версия "официального" биткойн-клиента, в том числе и Qt - очень сатошистая.

это плохо?

Отнюдь. Я просто отвечал на пост LZ.

[[Tycho]]

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

Сам код-то весьма понятный. Просто не про все вещи точно известно, почему оно сделано именно так.
А вообще - его постоянно меняют, фиксят и дорабатывают. Из серьёзных вещей вот БД менять точно пора, БДБ уже не очень справляется.

[elbrus]

Сам код-то весьма понятный. Просто не про все вещи точно известно, почему оно сделано именно так.

Не могли бы подкинуть ссылок/материал где обсуждается/обсуждалось подобное?

А вообще - его постоянно меняют, фиксят и дорабатывают. Из серьёзных вещей вот БД менять точно пора, БДБ уже не очень справляется.

Насчет того что BDB не справляется - вопрос спорный. Кажется (не уверен до конца, т.к. выяснить еще руки не дошли) мне удалось обнаружить первое узкое место в клиенте. Если все-таки руки дойдут - то выдам патч который ускорит один из участков работы с BDB в несколько раз (до доработки надо еще вопрос выяснить до победного).

[nLockTime]

Я думаю пользователи быстрее на SSD перейдут, чем на Bitcoin. Кроме того, в клиенте уже реализована возможность указания размера кэша БД, кто-нибудь тестировал его с этим параметром в пару гигабайт?

[elbrus]

Я думаю пользователи быстрее на SSD перейдут, чем на Bitcoin. Кроме того, в клиенте уже реализована возможность указания размера кэша БД, кто-нибудь тестировал его с этим параметром в пару гигабайт?

Я тестировал. Разницы не получил. Возможно что плохо тестировал.

// Я тестировал не полную работу программы, а лишь конкретный участок кода к которому и есть мысль патч подготовить. Позже выяснил что участок реализовать так что размер кэша на скорость работы там влиято не может. Сейчас стоит вопрос о возможности/невозможности рационализации процесса обработки данных. Как разберусь с этим участком - перейду ко второму узкому месту, но буду благодарен если кто-нибудь выложить результаты полного тестирования.

[Balthazar]

Посвящается любителям "замены базы данных", "оптимизации скачивания" и прочей ерунды.

Единственный способ как-то повлиять на ситуацию - это заменить OpenSSL на что-то более производительное.

[ArsenShnurkov]

Единственный способ как-то повлиять на ситуацию - это заменить OpenSSL на что-то более производительное.

Было бы неплохо еще раскрыть, для каких именно целей используется OpenSSL в составе "толстого p2p-клиента" (это типа новый термин)

Если для этого:

Самое простое - замена используемой функции хэширования на оптимизированную из crypto++ дает прирост в районе 20% если "тупо под ноль" заменить. Если же прикрутить буферизацию и на проверку брать по 4 заголовка за раз, то на 64-битных процессорах при быстром интернете возможен куда более существенный прирост.

то как предоставленная картинка это демонстрирует.

А то не все раньше работали с программой callgrind

[elbrus]

Единственный способ как-то повлиять на ситуацию - это заменить OpenSSL на что-то более производительное.

Посмотрим что будет на деле.
Заодно мы узнаем а не является ли ваша уверенность лишь формой самоуверенности.

[Balthazar]

Было бы неплохо еще раскрыть, для каких именно целей используется OpenSSL в составе "толстого p2p-клиента" (это типа новый термин)

OpenSSL используется в нем для почти что всего, связанного с операциями шифрования. Хэширование транзакций и заголовков блоков, проверка подписей. Кстати, о подписях... На скрине наглядное подтверждение правоты [Tycho], который в этом топике выше говорил о том, что бОльшую часть времени занимает проверка подписей, а не хэширование. Вызовы ECDSA-функций (58%) это как раз оно.

Собственно, даже простая пересборка клиента с OpenSSL 1.0.1c вместо дистрибутивного дебиановского 0.9.8 приводит к заметному на глаз ускорению загрузки.

то как предоставленная картинка это демонстрирует.

Пятая часть времени загрузки (20% с копейками) была потрачена на вычисление хэшей SHA256. Плюс, можно привести в пример практическую реализацию от автора клиента Ufasoft, который получил как раз примерно такое ускорение путем использования собственной реализации SHA256 (по его собственным данным).

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

Посмотрим что будет на деле. Заодно мы узнаем а не является ли ваша уверенность лишь формой самоуверенности.

"Человек, который много совершает, и ошибается во многом." (с) Еврипид
"Человек, который ни разу не ошибался, опасен." (с) Ямамото Цунэтомо, Хагакурэ

Насчет же сути сообщения, жонглирование терминами из психологии без понимания их сути никак не изменит результат работы callgrind, опубликованный выше. Как было не меньше 58%, так и останется, потому что арифметика - это не разговоры о принципах. Если, конечно, вы не намерены заговорить ECDSA до смерти. Если это была попытка троллинга, то не засчитано.

[elbrus]

Посмотрим что будет на деле. Заодно мы узнаем а не является ли ваша уверенность лишь формой самоуверенности.

"Человек, который много совершает, и ошибается во многом." (с) Еврипид
"Человек, который ни разу не ошибался, опасен." (с) Ямамото Цунэтомо, Хагакурэ

Дело вовсе не в том что человек может ошибиться, а в том как он себя ведет.

Насчет же сути сообщения, жонглирование терминами из психологии без понимания их сути никак не изменит результат работы callgrind, опубликованный выше. Как было не меньше 58%, так и останется, потому что арифметика - это не разговоры о принципах. Если, конечно, вы не намерены заговорить ECDSA до смерти. Если это была попытка троллинга, то не засчитано.

Вот ваше заявление:

Единственный способ как-то повлиять на ситуацию - это заменить OpenSSL на что-то более производительное.

Смотрите теперь как карта легла: теперь уже не сильно важно кто оптимизирует код (я или кто-то другой). Как только найдется путь оптимизации без замены OpenSSL то я сразу скажу кто вы и что из себя представляете. Теперь уже от вас ничего не зависит, а зависит лишь от времени.

Сейчас уже понятны лишь две вещи:
1) вам в модераторы никак нельзя (из-за ваших манер);
2) инженер из вас так себе (пока это очевидно мне; не уверен что всем);
3) время нас рассудит.

PS: По версии 0.7.0 идут уже релиз-кандидаты. 0.7.0 выйдет без каких-либо оптимизации.

[nLockTime]

Из моих наблюдений — два клиента на локальной машине обмениваются базой на общем SSD диске приблизительно за 2 часа (правда клиент-источник был запущен с параметром dbcache=100). Загрузка процессора под конец возрастает, но некритично...
Насчет оптимизаций, на мой взгляд, лучшим решением будет утончить клиента, и вынести базу на отдельный сервер. Как вариант, вот решение серверной части: http://bitcoinjs.org

[Balthazar]

Насчет оптимизаций, на мой взгляд, лучшим решением будет утончить клиента, и вынести базу на отдельный сервер. Как вариант, вот решение серверной части: http://bitcoinjs.org

Это далеко не лучшее решение, потому что такому серверу придется доверять.

Дело вовсе не в том что человек может ошибиться, а в том как он себя ведет.

Я говорю что думаю по вопросу, без лирических приукрашиваний и прочего. Высказывать мнение исходя из холодных фактов, а не собственных заблуждений - это плохо и неправильно?   Тогда вам надо на форум 146%-ников, а здесь двоемыслие до сегодняшнего дня не приветствовалось, если я ничего не путаю.

Смотрите теперь как карта легла: теперь уже не сильно важно кто оптимизирует код (я или кто-то другой). Как только найдется путь оптимизации без замены OpenSSL то я сразу скажу кто вы и что из себя представляете. Теперь уже от вас ничего не зависит, а зависит лишь от времени.

От оптимизаций кода, забирающего на данный момент оставшиеся 42% времени выполнения те 58% никуда не денутся. Либо что-то менять с проверкой подписей, занимающей 58% времени, либо продолжать закрывать на это глаза, добавляя косметические плюшки и оптимизируя не самую медленную в перспективе часть. Почему не самую медленную? А потому что с ростом количества транзакций и их сложности (помимо обычных есть еще мультисиг-транзакции, да и "обычные" могут быть весьма непростой структуры) в блоках ситуация будет все больше и больше усугубляться и дойдет до того, что в текущем варианте проверка подписей будет занимать этак 90% времени. Вот как лежит карта на самом деле. Логично это или нет? Простой ответ на вопрос без воды хотя бы один раз дадите, или продолжите практиковать психоанализ на дому, как обычно?

то я сразу скажу кто вы и что из себя представляете.

Особенно смешно будет, если ссылка будет вести на мой же коммит.

Сейчас уже понятны лишь две вещи:
1) вам в модераторы никак нельзя (из-за ваших манер);
2) инженер из вас так себе (пока это очевидно мне; не уверен что всем);
3) время нас рассудит.

1) у кого что болит, да и не вам это решать при всем возможном уважении;
2) вам нужно перезарядить хрустальный шар, к тому же профайлинг - это первое, о чем должен вспоминать нормальный инженер;

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

[nLockTime]

Это далеко не лучшее решение, потому что такому серверу придется доверять.

Доверять придется не более, чем обычному интернет провайдеру (клиент необязательно должен быть браузерным в данном примере)
Но если хотите решение лучше... Можно разделить базу на две части: все старые блоки (например, до последнего чекпоинта) запрашиваются по мере необходимости из внешней БД (также, при желании пользователя, эта часть может подгружаться и в локальный кэш); новые блоки и транзакции (после чекпоинта) запрашиваются только из сети/локальной базы

[A-Bolt]

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

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

[ShadowAlexey]

Эм, а проверка подписей с использованием OpenCL нереальна?
По сути при реализации придется убрать нагрузку с БД, ибо необходимы как можно более линейные структуры на входе, а сама скорость вычисления вырастит существенно при более менее адекватных реализациях...

[rastapool]

Я вот не в первый раз задаю вопрос, но так и не получил вразумительного ответа кроме "это не секьюрно же".
Какое вобще отношение имеют обычные пользователи к загрузке блоков? Зачем они им?
Вся цепочка нужна только тем кто составляет новые блоки, чем обычные пользователи не занимаются.
Я совершенно не вижу связи между безопасностью сети Биткоин и тем, какие клиенты используют обычные пользователи.

Спрашивается, за чей счёт банкет?

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

[ShadowAlexey]

Цепочка должна быть достоверна, вопрос в том как это обеспечить когда вокруг одни "враги" ? Без достоверности ты будешь плодить трансферы, которые иваледны, т.к. ты тратишь средства которых у тебя нет, или же ты не можешь быть уверен что деньги и в правду до тебя дошли(т.е. что тебе их отправили), а это уже очень печально.
Придумаете алгоритм, который позволит без критичных допущений реализовать функционал, никто не будет против. Сейчас легкие клиенты работают только благодаря тому, что никто не пытается это нарушить.
Здесь рассматриваются варианты с использованием только своих средств, с другой стороны можно создавать "банки", которые будут уже обеспечивать эту самую проверку, вот только им платить придется. По сути это то, что сейчас нам предоставляют blockexplorer и аналоги.
Удобный вариант для "продвинутых" пользователей, это запуск личного сервера, который ведет цепочку, и цепляешь все свои легкие клиенты на него, уже со своими ключами.