Pages:
Author

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

newbie
Activity: 6
Merit: 0
Electrum может проверять транзакции по заголовкам блоков.
https://github.com/spesmilo/electrum/blob/master/lib/verifier.py
newbie
Activity: 6
Merit: 0
Electrum использует серверы для хранения блоков, как здесь обсуждалось.
MultiBit не использует серверы, но и не требует загрузки полной цепочки для полноценной работы.
Возможность создания тонких P2P-клиентов была заложена в Bitcoin. Это – Merkle tree. Для проверки proof of work достаточно загрузить лишь заголовки блоков. Для проверки факта вхождения транзакции в блок нужен заголовок блока и несколько хешей. Если считать, что в цепочке нет неправильных блоков, то транзакции несложно проверять, даже не имея всех данных.
newbie
Activity: 38
Merit: 0
Почему не сделать все гораздо проще. Пусть Гевин выкладывает на основном сайте два дистрибутива. Маленький и большой. Маленький, как сейчас. Большой - это маленький + вся цепочка блока в момент создания дистрибутива.
member
Activity: 84
Merit: 10
то я сразу скажу кто вы и что из себя представляете.
Особенно смешно будет, если ссылка будет вести на мой же коммит.

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

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

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

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

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

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

Чтобы не плодить субтреды в это теме, я здесь подготовил сюрприз: https://bitcointalksearch.org/topic/balthazar-106453. Всех приглашаю к рассмотрению моего предложения. Любая конструктивная критика приветствуется.
member
Activity: 167
Merit: 10
Т.е. а с чего вы взяли что стоит доверять данным, которые были забиты кем то?  Ведь легко можно пропатчить клиент...
Ну так его в любом случае можно пропатчить — "официальные" сборки выкладываются с контрольными суммами для проверки

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

кто будет решать какому серверу доверять?
А чего ему доверять, если он только выдает блоки по запросу клиентов... Ну да, может не найти то что на самом деле в базе есть, или даже подсунуть какой-нибудь orphan-блок с недействительной транзакцией. Но какая выгода самому сервису от этого? Даже в текущей реализации (без сокращенной БД) тонкие клиенты могут подгружать дополнительные 6 блоков впереди и проверять их proof-of-work
donator
Activity: 968
Merit: 1002
Придумаете алгоритм, который позволит без критичных допущений реализовать функционал
Проще простого — можно зашить в клиент контрольные суммы всех блоков, кстати и загружать их можно будет без дополнительных проверок. А проблему инициализации БД в любом случае нужно решать либо выделенными серверами, либо путем распараллеливания загрузки блоков...
Т.е. а с чего вы взяли что стоит доверять данным, которые были забиты кем то?  Ведь легко можно пропатчить клиент... И где получать эти самые данные для проверки их корректности в клиенте?
Вы не с той стороны смотрите на проблему, кто будет решать какому серверу доверять? А если его ломанут?
member
Activity: 167
Merit: 10
Без достоверности ты будешь плодить трансферы, которые иваледны, т.к. ты тратишь средства которых у тебя нет, или же ты не можешь быть уверен что деньги и в правду до тебя дошли
Чтобы быть уверенным в собственных средствах достаточно 6 подтверждений при их получении. Если перевод совершался на оффлайн кошелек, то в любом случае придется качать все блоки, начиная от даты его создания. Свежие блоки вообще необязательно от централизованного сервера получать (да и не станет он генерировать 6 инвалидов подряд)

Придумаете алгоритм, который позволит без критичных допущений реализовать функционал
Проще простого — можно зашить в клиент контрольные суммы всех блоков, кстати и загружать их можно будет без дополнительных проверок. А проблему инициализации БД в любом случае нужно решать либо выделенными серверами, либо путем распараллеливания загрузки блоков...
sr. member
Activity: 423
Merit: 250
Quote
Цепочка должна быть достоверна
У 100% майнеров, да. Но что плохого может произойти, если пользователь использует лёгкий клиент и подключился к серверу на котором недостоверная цепочка? Он потеряет свои деньги? Нет, на сколько я знаю это невозможно таким путём. Его транзакция не подтвердится? Да, майнеры её не подтвердят, и он не сможет потратить свои деньги. Но всё что ему нужно будет сделать, это подключиться к другому серверу с достоверной цепочкой. А посмотреть дошли ли до тебя деньги можно в онлайне на каком-либо сервисе который держит у себя полную цепочку, их уже несколько, а будет ещё больше.
Quote
Придумаете алгоритм
Я не до конца понимаю как это всё сейчас работает, поэтому и спрашиваю. Но по тому представлению которое я имею, я не вижу проблемы в лёгких клиентах.
Quote
можно создавать "банки"
И это будет, но даже это не станет той централизацией которая сможет навредить Биткоину.
Единственное что важно, это децентрализация тех кто составляет блоки, остальное не есть проблемой.
donator
Activity: 968
Merit: 1002
Цепочка должна быть достоверна, вопрос в том как это обеспечить когда вокруг одни "враги" ? Без достоверности ты будешь плодить трансферы, которые иваледны, т.к. ты тратишь средства которых у тебя нет, или же ты не можешь быть уверен что деньги и в правду до тебя дошли(т.е. что тебе их отправили), а это уже очень печально.
Придумаете алгоритм, который позволит без критичных допущений реализовать функционал, никто не будет против. Сейчас легкие клиенты работают только благодаря тому, что никто не пытается это нарушить.
Здесь рассматриваются варианты с использованием только своих средств, с другой стороны можно создавать "банки", которые будут уже обеспечивать эту самую проверку, вот только им платить придется. По сути это то, что сейчас нам предоставляют blockexplorer и аналоги.
Удобный вариант для "продвинутых" пользователей, это запуск личного сервера, который ведет цепочку, и цепляешь все свои легкие клиенты на него, уже со своими ключами.
sr. member
Activity: 423
Merit: 250
Я вот не в первый раз задаю вопрос, но так и не получил вразумительного ответа кроме "это не секьюрно же".
Какое вобще отношение имеют обычные пользователи к загрузке блоков? Зачем они им?
Вся цепочка нужна только тем кто составляет новые блоки, чем обычные пользователи не занимаются.
Я совершенно не вижу связи между безопасностью сети Биткоин и тем, какие клиенты используют обычные пользователи.
Quote
Спрашивается, за чей счёт банкет?
Когда в сети несколько сот тысяч пользователей (как сейчас), или миллионы/миллиарды (как будет), вопрос поддержания нескольких сотен и даже тысяч хранилищ полной цепочки не есть трудным.
Сейчас как минимум у каждого пула должна быть полная цепочка, вот, за счёт майнеров на пуле.
donator
Activity: 968
Merit: 1002
Эм, а проверка подписей с использованием OpenCL нереальна?
По сути при реализации придется убрать нагрузку с БД, ибо необходимы как можно более линейные структуры на входе, а сама скорость вычисления вырастит существенно при более менее адекватных реализациях...
legendary
Activity: 2317
Merit: 2318
Насчет оптимизаций, на мой взгляд, лучшим решением будет утончить клиента, и вынести базу на отдельный сервер.
Это не решение проблемы ускорения начальной загрузки блоков. Это перекладывание проблемы с плеч обычных пользователей на хозяина этого самого "отдельного сервера". Спрашивается, за чей счёт банкет? 
member
Activity: 167
Merit: 10
Это далеко не лучшее решение, потому что такому серверу придется доверять.
Доверять придется не более, чем обычному интернет провайдеру (клиент необязательно должен быть браузерным в данном примере)
Но если хотите решение лучше... Можно разделить базу на две части: все старые блоки (например, до последнего чекпоинта) запрашиваются по мере необходимости из внешней БД (также, при желании пользователя, эта часть может подгружаться и в локальный кэш); новые блоки и транзакции (после чекпоинта) запрашиваются только из сети/локальной базы
legendary
Activity: 3108
Merit: 1359
Насчет оптимизаций, на мой взгляд, лучшим решением будет утончить клиента, и вынести базу на отдельный сервер. Как вариант, вот решение серверной части: http://bitcoinjs.org
Это далеко не лучшее решение, потому что такому серверу придется доверять.

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

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

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

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

Исходя из этого следует вывод, что вы импульсивный человек с противоречивой моделью поведения. И такое бывает, ничего не поделаешь, как-то реагировать на это смысла нет.
member
Activity: 167
Merit: 10
Из моих наблюдений — два клиента на локальной машине обмениваются базой на общем SSD диске приблизительно за 2 часа (правда клиент-источник был запущен с параметром dbcache=100). Загрузка процессора под конец возрастает, но некритично...
Насчет оптимизаций, на мой взгляд, лучшим решением будет утончить клиента, и вынести базу на отдельный сервер. Как вариант, вот решение серверной части: http://bitcoinjs.org
member
Activity: 84
Merit: 10
Quote from: elbrus
Посмотрим что будет на деле. Заодно мы узнаем а не является ли ваша уверенность лишь формой самоуверенности.
"Человек, который много совершает, и ошибается во многом." (с) Еврипид
"Человек, который ни разу не ошибался, опасен." (с) Ямамото Цунэтомо, Хагакурэ
Дело вовсе не в том что человек может ошибиться, а в том как он себя ведет.

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

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

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

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

PS: По версии 0.7.0 идут уже релиз-кандидаты. 0.7.0 выйдет без каких-либо оптимизации.
legendary
Activity: 3108
Merit: 1359
Было бы неплохо еще раскрыть, для каких именно целей используется OpenSSL в составе "толстого p2p-клиента" (это типа новый термин)
OpenSSL используется в нем для почти что всего, связанного с операциями шифрования. Хэширование транзакций и заголовков блоков, проверка подписей. Кстати, о подписях... На скрине наглядное подтверждение правоты [Tycho], который в этом топике выше говорил о том, что бОльшую часть времени занимает проверка подписей, а не хэширование. Вызовы ECDSA-функций (58%) это как раз оно.

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

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

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

Quote from: elbrus
Посмотрим что будет на деле. Заодно мы узнаем а не является ли ваша уверенность лишь формой самоуверенности.
"Человек, который много совершает, и ошибается во многом." (с) Еврипид
"Человек, который ни разу не ошибался, опасен." (с) Ямамото Цунэтомо, Хагакурэ

Насчет же сути сообщения, жонглирование терминами из психологии без понимания их сути никак не изменит результат работы callgrind, опубликованный выше. Как было не меньше 58%, так и останется, потому что арифметика - это не разговоры о принципах. Если, конечно, вы не намерены заговорить ECDSA до смерти. Если это была попытка троллинга, то не засчитано.
member
Activity: 84
Merit: 10
Единственный способ как-то повлиять на ситуацию - это заменить OpenSSL на что-то более производительное.
Посмотрим что будет на деле.
Заодно мы узнаем а не является ли ваша уверенность лишь формой самоуверенности.
legendary
Activity: 1386
Merit: 1000
Единственный способ как-то повлиять на ситуацию - это заменить OpenSSL на что-то более производительное.

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

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

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

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

А то не все раньше работали с программой callgrind
legendary
Activity: 3108
Merit: 1359


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

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