Topic: Доработка официального клиента. (Read 6971 times)

Electrum может проверять транзакции по заголовкам блоков.
https://github.com/spesmilo/electrum/blob/master/lib/verifier.py

Electrum использует серверы для хранения блоков, как здесь обсуждалось.
MultiBit не использует серверы, но и не требует загрузки полной цепочки для полноценной работы.
Возможность создания тонких P2P-клиентов была заложена в Bitcoin. Это – Merkle tree. Для проверки proof of work достаточно загрузить лишь заголовки блоков. Для проверки факта вхождения транзакции в блок нужен заголовок блока и несколько хешей. Если считать, что в цепочке нет неправильных блоков, то транзакции несложно проверять, даже не имея всех данных.

Почему не сделать все гораздо проще. Пусть Гевин выкладывает на основном сайте два дистрибутива. Маленький и большой. Маленький, как сейчас. Большой - это маленький + вся цепочка блока в момент создания дистрибутива.

Неважно будет чей коммит. Достаточно найти противоречие с вашим заявлением. И все.

Вопросов нет не мне решать. Есть люди (здесь на форуме) достойнее вас. Вы - годитесь в седнего юзера (а-ля penek, ukigo, ...) но не более.

Z-z-z-z...


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

Разговор еще не закончен.

Чтобы не плодить субтреды в это теме, я здесь подготовил сюрприз: https://bitcointalksearch.org/topic/balthazar-106453. Всех приглашаю к рассмотрению моего предложения. Любая конструктивная критика приветствуется.

Ну так его в любом случае можно пропатчить — "официальные" сборки выкладываются с контрольными суммами для проверки

Сами данные это по сути сокращенная БД для тонкого клиента, которая содержит только хэши блоков, но распространять ее, конечно, лучше в двоичном виде, и соответственно проверять на корректность также можно с помощью контрольной суммы

А чего ему доверять, если он только выдает блоки по запросу клиентов... Ну да, может не найти то что на самом деле в базе есть, или даже подсунуть какой-нибудь orphan-блок с недействительной транзакцией. Но какая выгода самому сервису от этого? Даже в текущей реализации (без сокращенной БД) тонкие клиенты могут подгружать дополнительные 6 блоков впереди и проверять их proof-of-work

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

Чтобы быть уверенным в собственных средствах достаточно 6 подтверждений при их получении. Если перевод совершался на оффлайн кошелек, то в любом случае придется качать все блоки, начиная от даты его создания. Свежие блоки вообще необязательно от централизованного сервера получать (да и не станет он генерировать 6 инвалидов подряд)

Проще простого — можно зашить в клиент контрольные суммы всех блоков, кстати и загружать их можно будет без дополнительных проверок. А проблему инициализации БД в любом случае нужно решать либо выделенными серверами, либо путем распараллеливания загрузки блоков...

У 100% майнеров, да. Но что плохого может произойти, если пользователь использует лёгкий клиент и подключился к серверу на котором недостоверная цепочка? Он потеряет свои деньги? Нет, на сколько я знаю это невозможно таким путём. Его транзакция не подтвердится? Да, майнеры её не подтвердят, и он не сможет потратить свои деньги. Но всё что ему нужно будет сделать, это подключиться к другому серверу с достоверной цепочкой. А посмотреть дошли ли до тебя деньги можно в онлайне на каком-либо сервисе который держит у себя полную цепочку, их уже несколько, а будет ещё больше.
Я не до конца понимаю как это всё сейчас работает, поэтому и спрашиваю. Но по тому представлению которое я имею, я не вижу проблемы в лёгких клиентах.
И это будет, но даже это не станет той централизацией которая сможет навредить Биткоину.
Единственное что важно, это децентрализация тех кто составляет блоки, остальное не есть проблемой.

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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 до смерти. Если это была попытка троллинга, то не засчитано.

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

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

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


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

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

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

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