Topic: Доработка официального клиента. (Read 7035 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 на что-то более производительное.

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

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

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

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

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

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

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

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

это плохо?

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

Если лишь интерфейс, то соберите шестой Bitcoin на wxWidgets.
Я прекрасно помню, что Bitcoin-Qt изначально был проектом смены
интерфейса, но в настоящий момент это самостоятельный продукт.

Мне показалось, или Balthazar только что обвинил меня в некомпетентности по
данному вопросу (являются ли Bitcoin и Bitcoin-Qt разными программами) лишь
на основании того, что я не являюсь профессиональным программистом, а так
же в том, что я служу некой партии? Я служу лишь сообществу Bitcoin.

Bitcoin-qt как был просто интерфейсом, так и останется. Пока не перепишут полностью файлы Сатоши, что будет нескоро, т.к. незачем переделывать то, что и так работает. Исправляют баги, добавляют плюшки и на этом все. Можно долго спекулировать на эту тему, но фактов это не изменит.

Я, конечно, понимаю что от парторга регулярно приходят установки, какие речевки и как часто надо постить. Но все же, будучи общественным деятелем, в любом случае нельзя позволять себе публикацию некомпетентного мнения, этим вы дискредитируете своего же босса. А мнение это в данном случае в принципе не может быть компетентным, потому что вы не раз сами признавали, что не разбираетесь в данном вопросе. Я бы на вашем месте завел дополнительный профиль для данной деятельности. На правах ИМХО.

Это "морда", если смотреть со стороны разработчиков. Со стороны же пользователей
это пакет ПО, имеющий в своей поставке еще и консольную (серверную) версию.

http://bitcoin.org/clients.html

Думаю, Сатоши имеет такое же отношение к Bitcoin-Qt, как Стив Джобс - к iPhone 5.

Нет никакого "клиента bitcoin-qt". Bitcoin-qt это всего лишь морда. Так что все замечательно подходит... Да и потом, theymos, gavin, satoshi (пусть даже последний и пропал) имеют копию приватного ключа для рассылки алертов, а следовательно, вполне себе официальные лица, как бы ни хотелось обратного в угоду своим убеждениям.

Официальным/эталонным/авторским клиентом был Bitcoin от Сатоши.
Клиент Bitcoin-Qt развивается параллельно с другими реализациями,
так что данные слова к нему не очень подходят. Да и нужны ли они?
По факту - Bitcoin-Qt это просто доминирующая реализация Bitcoin.

Благодарю за развернутый ответ.

Надо предложить Bitcoin-QT переименовать в "Биталон", но звучит как лекарственный препарат .


И в контрактах есть недостатки как только задумаетесь о недобросовестных пользователях и о недобросовестных исполнителях (вот как вступят в дело деньги, то сразу же вам такие исполнители понабегут - мало не покажется). Но вцелом - согласен. Схема нужная (в идеале все выглядит очень заманчиво, но реалии внесут свои корректировки).

1. Ну а по поводу гаранта - это все равно надежнее (вопрос доверия к гаранту остается в силе), тем более что можно согласовать эксклюзивные условия сделки на три стороны что резко расширяет возможности.

2. Далее, насчет тестирования программы - тут не обязательно нагружать гаранта. Тестовую версию можно высылать всем желающим.

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

Не так важно какой будет перевод вики. Проблема здесь в том, что словосочетание "официальный клиент" понимается двусмысленно (государственный/строгий), и не очень хочется, чтобы оно становилось устойчивым общепринятым выражением. Это плохой "мем" и от него нужно избавляться. Ваш вариант названия "эталонный" в этом смысле даже лучше чем просто "Bitcoin-QT", но приживется ли оно в русскоязычном сообществе...

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

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

Например:
1. Разработчик создает тему "[идея] Хочу реализовать периодические платежи" на различных форумах соответствующей целевой аудитории, где размещает описание и адрес для взносов
2. Пользователи желающие поддержать разработку просто совершают платеж вида аванс+вознаграждение (соотношение зависит от уровня доверия)
3. Когда фича реализована клиенты получают соответствующее уведомление, и каждый по своему усмотрению может проверить и подтвердить или отменить запланированное вознаграждение

По существу, сообщество создает свой независимый форк, и сами пользователи непосредственно заинтересованы в его развитии (они его делают под себя)
Конечно, многое из перечисленного реализуемо и по вашей схеме, но проблема как раз в том, что это все будет менее эффективно, более трудоемко, и не так удобно как для "заказчиков" так и "исполнителей"... так-то и картошкой возможно торговать по схеме "ебэй через гаранта пэйпал"

С гарантами схема лучшая на мой взгляд..

Предложенная схема с гарантами не годится?

О чем-то подобном тоже думал, но остановился на том что первоочередная проблема - это текущие препятствия в использовании эталонного клиента ("тормоза" БД; "здесь и сейчас"). Ну и чтобы не зялегло в долгий ящик - предложил возможную на текущий момент схему сотрудничества через гарантов. Вроде бы неплохой вариант, нет?

PS: Не знаю на что там народ ругается по поводу кода клиента, но код достаточно простой и очень логичный (как обычно бывает, но не неосиляторы ли ноют вновь?).

1. Насчет перевода "reference code" - вероятно вы правы (прошу прокомментировать предложенный мной вариант перевода).
2. Поддерживаю, ссылки на whitepaper не помешают.
3. А насчет исходных кодов вроде все в порядке. Ссылка указывает на репозитории который лежит на гитхабе. Репозитории включает все изменения кода (от самых ранних и до последних правок). Рекомендую ознакомится с git (хотел посоветовать отличную книгу на ангельском языке, но сходу не нашел ). То есть скачать вы можете весь репозитории и в любой момент времени достать из него любую нужную версию иходных кодов.

В подтверждение моих слов:

Там только ссылка на гитхуб, то есть на последнюю версию исходников. А "reference code" лучше перевести как "авторский клиент", но тогда внутри разместить ссылки на whitepaper и исходники ранних версий

Есть сообщество майнеров, сообщество трейдеров, разработчиков... спонсоров и меценатов крайне мало

Мне кажется скорость инициализации базы это проблема майнеров и тех пользователей, которые неосведомлены о наличии легких клиентов. Только новички врядли будут делать донейты, да и майнеров объем БД пока что мало волнует. Но тема правильная...

По большому счету разработка и так ведется исключительно за счет донейтов — потратить личное время и реализовать какой-то функционал это такое же пожертвование. Непрограммисты почти не участвуют в процессе разработки (совершенно справедливо, поскольку опасаются лохотронов). Почему бы не решить сначала эту проблему?

Выглядеть это может приблизительно так:

http://i074.radikal.ru/1209/ce/931c85b586ad.png

http://s57.radikal.ru/i158/1209/98/daab58c47950.png

По задумке здесь должна быть еще вкладка (пока не реализовано) для управления сделанными пожертвованиями (подтвердить/изменить/отменить), так чтобы простые пользователи могли мотивировать разработчиков и самостоятельно завершать транзакции уже по факту выполнения работы

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

Нет претензии к переводу. Но раз уж спросили: эталонный (базисный) код вероятно более подошел бы, не? Идея такая: среди множества клиентов должен быть эталон (термин "базис", вероятно, более знаком тем кому выпала честь соприкоснуться хоть как-то с элементами высшей математики). Логично что эталоном будет код первого клиента который и будет формировать базис (всмысле отображения модели).

// Внимание! Опасное погружение в оффтоп

Ну это я туда вписал. А как по-вашему надо было перевести словосочетание "reference code" ?

Да простят модераторы за оффтоп: истина где-то рядом

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

Я из вторых, но прекрасно осознаю существование другого класса людей и мои действия идут с поправкой на этот фактор.

PS: По схеме сделки вариант тут вероятно один (поскольку ко мне сейчас нулевой уровень доверия): ищем надежных гарантов (лучше несколько - тут работает принцип яиц и одной корзины). Оплата после результата: я показываю закрытый бинарник для тестов (под linux), после тестов и оплаты публиккую патч к сорцам по той же лицензии по которой идет "официальный" () клиент.


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

2. Много чего можно добавить клиенту. Это лишь вопрос времени (с сожалению, это вырождается в вопрос цены).

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

Примерно такое и приходило на ум в первую очередь. Рассматривался уже упомянутый вариант "облегченного" клиента. Однако православный подход тут единственный: анализ кода с целью поиска узких мест с последующим поиском решении.

Здесь рынок, хотите чтото продать, покажите что вы можете, никто вперед платить не будет, но вознаграждения возможны. Мб если пират расплатиться, то будет даже фонд)
PS Не найду себе работы в ближайшее время, мб займусь вопросом за даром, давно хотел покопаться)

ну я - не прогарммист, помог лишь тем, что сказал что это "не дело", нужно искать решение, как сделать что бы "работало быстрее"... Готов 5 BTC потратить на НЕ ЛОХОТРОН, где реально решать проблему будут, но это Рассия, никому ниче не надо....

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

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

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

Насиловать диск журналированием данных, которые в случае потери легко скачиваются из сети – не годится. Надо улучшать.

Есть ли ссылки по теме?

База выросла вдвое за последний год. Ты это серьёзно?
А во вторых, компы уже на том уровне быстродействия когда их менять не имеет смысла. Это четвёрку нужно было менять на пентиум, потому что всё тормозило и ничего не работало. Те времена прошли. Я знаю много людей у которых компы 2005 года примерно. И их незачем менять: браузер работает, фильмы идут.
Да и скорость интернета в развитых странах растёт не очень быстро.

Юзабельным он станет хотя бы потому, что скорость и объемы дисков растут намного быстрее, чем объем базы.

За последнее время уже не в первый раз вижу здесь это словосочетание. Раньше я спрашивал у пишущего, на тот ли он форум зашёл. Теперь же сомневаюсь на тот ли форум зашёл я.
Не такая уж большая, как принято думать: простым смертным полный клиент ни к чему, а майнерам и хардкорщикам не так уж и важно что инициализируется это всё несколько суток.
Ну это не помешает, если нету других более важных задач. Но что это даст? Юзабельным для простых смертных полный клиент всё-равно не станет. Ну пусть увеличится скорость обработки даже в 5 раз, а что будет через 5 лет, когда база будет 20 гигабайт? Та же история. Увеличение скорости обработки в полном клиенте это не решение которое сделает его юзабельным для домохазяек. Тонкие клиенты, это решение.

Подытожим:

1) есть официальный клиент;
2) есть проблема в нем;
3) надо проблему решать.

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

// Статистика: 112 просмотров; 4 участника в треде; 0 действующих целенаправленно. Мнение о существующем сообществе было несколько выше (все-таки здесь гигахэши, криптовалюта, много IT-шников), а оказалось что существующе сообщество проявляет те же свойства что и обычное население. Печально.

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

Вот видите, вы уже перечислили несколько вариантов (но это лишь элементарные соображения).

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

А так - решения могут быть. Встроить поддержку OpenCL, например, или написать 4 Гб памяти в минимальных требованиях и.т.п. :)
Некоторые разработчики, как я уже сказал, пробуют использование другой БД, более быстрой.

Не работоспособно, факт. Но полный клиент сейчас - это довольно экспериментальная штука, и если человек ставит его вместо лёгкого клиента - то должен быть готов бороться с трудностями. Это ведь даже не релизная версия.

А то, что готовый продукт должен легко ставиться и работать - это да, я согласен, конечно.

В точку! Если бы у меня почти 2 года назад когда я узал об этом проекте тааак тормозило - я бы не стал связываться, это точно..... Простите, но ЭТО не работоспособно по моему .. 

Так я не про цель, я про решение.
Я уж думал что раз хотите деньги собирать - то уже знаете, в каком направлении двигаться.

В последнее время основной расход идёт не на само скачивание и не на хэширование, а на проверку подписей - это очень интенсивная задача по количеству рандомных обращений к диску в существующей реализации. Один из вариантов, который сейчас пробуют - это замена типа используемой базы данных.
Как временный вариант для пользователей - можно пока предложить ставить биткойн на  SSD :)

Цель - уменьшить время загрузки блоков. Оптимальный вариант еще надо найти (в коде еще не разбирался).

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

В чём же суть решения ?
Вкратце.

А можно ramzswap засунуть в видеопамять. Все эти "костыли" я понимаю, но смысл был не в этом.

Если нужен именно официальный клиент то можно скачать готовую цепочку отсюда http://eu1.bitcoincharts.com/blockchain/ и подсунуть ее клиенту. Либо можно положить файлы клиента на tmpfs/ramdisk, что сильно ускорит загрузку, но потребует довольно большого количества оперативной памяти.

  Здравствуйте.
 Предыстория такая: часть выполненной работы мне оплатят биткойнами и теперь я здесь. Сейчас тянутся цепочки, но скорость процесса явно оставляет желать лучшего. Есть желание доработать в официальном клиенте этот участок. Эта проблема будет сильным препятствием в расширении использования криптовалюты и ее надо будет рашить. Думаю все понимают что эта работа себя никак не окупит. Поэтому я решил начать переговоры с сообществом: есть ли желающие кто поддержит разработку (через донейты) ?

PS: Запрос модератору(ам): буду благодарен если снимите с меня ограничения новичка по форуму. Безобразия на форуме с моей стороны не будет.