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

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

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

Я думаю пользователи быстрее на 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, соответственно механизм пожертвований основан на стандартных транзакциях (без применения мультисигнатур и прочих контрактов), в ближайшей перспективе уже можно думать о реализации на основе контрактов