Для справки:
при работе над первичной выборкой по распределения по возрастам был получен следующий результат
Выборка сдела без учёта обработки блоков орфанов, которые однозначно повлияют на результат в сторону некоторого увеличения, но, по нашему мнению, как процентное отношение, так и сумма выходов особо не изменится. Этот вопрос больше на уровне точности, а не статистической выборки.

Остаётся пока открытым 2 вопроса:
1. достаточно ли этих диапазонов выборки;
2. есть ли необходимость выбирать статистику для каждого блока.


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

P.S. Небольшое уточнение для опережения отдельных уточняющих вопросов: выборка производится по выходам в транзакциях.

Ошибка найдена и локализована. Проверяйте.
Всё-так иногда копипаста спасает от глупых ошибок

Строку запроса опубликуй, проверим. Пока как бы всё работает.

P.S. Вот почему никто не отзывается сразу, например, когда идёт тестирование?

Завершено.

implemented new API method listtransactionsabyaddress

Надо понимать, что если жалобы на работу метода listtransactionsbyaddress, а равно как и предложения, не поступают, то его можно ставить как окончательный вариант.
К вечеру поменяем вывод на стандартный json.

Да, есть такой косяк, всё забываем про него
Добавил в багреппорты.

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

P.S. Найден и устранён баг в методе gettransaction из-за которого вывод некоторых транзакций был неполным.

Implemented new API method listtransactionsbyaddress/

.
Now the method works in test mode, only structured for display view.

We think about the need to include PoS generation transactions (zero transactions of PoS block).

Если кому интересно, то в тестирование выведена команда API listtransactionsbyaddress/

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

P.S. пока остаётся не ясным один момент: если ли необходимость выводить генерационные транзакции PoS блоков.

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


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


В принципе это то, что следует при реализации указанного ранее метода, т.к. там будет необходимым указание на то, была ли потрачена или подтверждена транза.


Реализация серверной части API сайта неизменно за собой потянет реализацию всего механизма работы серверной части сайта (БД, демоны, обработчики по cron и т.п.). Да и вряд ли сейчас разрабы согласятся поделиться этой инфой, т.к. уже были удачные эксперименты для запилки этого движка для работы с другими коинами (в т.ч. в другими алгоритмами хэширования) буквально за считанные часы.
Да и принципиально сам движок ещё сыроват. До сих пор остались нерешёнными некоторые проблемы с правильной выборкой транз с учётом всех особенностей работы PoS механизма, т.е. конечный итог считать научили давно, а вот с промежуточными и с некоторыми выборками есть нерешённые проблемы.
Да, кстати, Zloy сейчас вспомнил о то, что давно хотел допилить демон серверой части WebSocket, что позволит, надеемся, немного разгрузить сервер в плане запросов при обновлении эксплорера, а заодно, думается, и реализовать обновление некоторых других статистических страниц, на которых изначально от этого отказались.

Пример, если не трудно.

Это уже обсуждалось, но в связи с тем, что планировалось написать JS тонкий клиент, то остановились пока на апи-методе для https://novaco.in/api .


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

Возможно и баг, будем проверять.

Наконец-то дошли руки обновить portage для gentoo, но оттестировать пока не было времени, так что будем благодарны если кто-то это сделает.
И как всегда спасибо sir.miklosh за своевременные ebuild'ы (выложили вместе с portage).

P.S. Накопилось много работы на сайте, но руки всё не доходят в связи с занятостью разработчиков в других проектах.

Злой решил обновить систему.
Selinux не заставил себя долго ждать и залочил то, что до того было разрешено

Кстати, появилось предложение по сервису: добавить идентификацию адресов c подтверждением.
Планируется сделать следующим образом: создать форму где указывать адрес, наименование и транзакцию, подтверждающую владение адресом.
Запрос будет считаться подтверждённым если транзакция находится в последних 6 блоках.
Предварительно обсуждалось, что за добавление (изи изменение) необходимо будет отправить "флаг" (01) NVC, а для удаления - (10) NVC.

вообще-то там ноды p2poll'а

если надо ноды кошелей, то это лучше брать в DNS Seeders summary information

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

Теоретически возможно всё

Можно было бы сделать в самом блоге, создав там отдельную рубрику, но оно как-то не особо будет вязаться, я думаю.

Предложите варианты движка, а дальше посмотрим и обсудим.

Updated.

In API added new method gettransaction