Show Posts
|
Pages: [1] 2 »
|
Насчет графиков, не помешало бы распределение по возрастам.
Для справки: при работе над первичной выборкой по распределения по возрастам был получен следующий результат +-------+----------+ | age | COUNT(*) | +-------+----------+ | < 30 | 20103 | | < 120 | 40627 | | 120+ | 153717 | +-------+----------+ 3 rows in set (6.93 sec)
Выборка сдела без учёта обработки блоков орфанов, которые однозначно повлияют на результат в сторону некоторого увеличения, но, по нашему мнению, как процентное отношение, так и сумма выходов особо не изменится. Этот вопрос больше на уровне точности, а не статистической выборки. Остаётся пока открытым 2 вопроса: 1. достаточно ли этих диапазонов выборки; 2. есть ли необходимость выбирать статистику для каждого блока. Насчет графиков, не помешало бы распределение по возрастам.
и по мелочности. На эту тему общей позиции по необходимости данной выборки выработано не было. Фактически обсуждение было завершено на том, что для данной выборки необходимо формировать двумерный массив с учётом предыдущего запроса, что достаточно сильно нагрузит БД. И тут же встаёт вопрос об актуальных диапазонах размерной выборки. P.S. Небольшое уточнение для опережения отдельных уточняющих вопросов: выборка производится по выходам в транзакциях.
|
|
|
Ошибка найдена и локализована. Проверяйте. Всё-так иногда копипаста спасает от глупых ошибок
|
|
|
Надо понимать, что если жалобы на работу метода listtransactionsbyaddress, а равно как и предложения, не поступают, то его можно ставить как окончательный вариант.
Завершено. А мне вот что выдаёт Warning: mysqli::query(): (21000/1242): Subquery returns more than 1 row in /var/www/novaco.in/api.php on line 422 {"error":"DB request error (1242) Subquery returns more than 1 row"} Строку запроса опубликуй, проверим. Пока как бы всё работает. P.S. Вот почему никто не отзывается сразу, например, когда идёт тестирование?
|
|
|
Надо понимать, что если жалобы на работу метода listtransactionsbyaddress, а равно как и предложения, не поступают, то его можно ставить как окончательный вариант.
Завершено.
|
|
|
implemented new API method listtransactionsabyaddress
|
|
|
Если кому интересно, то в тестирование выведена команда API listtransactionsbyaddress/<address>. ...
По просьбам "трудящейся молодёжи" к выходам транзакций добавлено поле spent указывающее на транзакцию траты данного выхода. P.S. Найден и устранён баг в методе gettransaction из-за которого вывод некоторых транзакций был неполным. Надо понимать, что если жалобы на работу метода listtransactionsbyaddress, а равно как и предложения, не поступают, то его можно ставить как окончательный вариант. К вечеру поменяем вывод на стандартный json.
|
|
|
Novaco.in На главной странице https://novaco.in/ вместо PoS-сложности пишет PoW, когда PoW-блок орфанится Pos'ом. Да, есть такой косяк, всё забываем про него Добавил в багреппорты.
|
|
|
Если кому интересно, то в тестирование выведена команда API listtransactionsbyaddress/<address>. ...
По просьбам "трудящейся молодёжи" к выходам транзакций добавлено поле spent указывающее на транзакцию траты данного выхода. P.S. Найден и устранён баг в методе gettransaction из-за которого вывод некоторых транзакций был неполным.
|
|
|
Implemented new API method listtransactionsbyaddress/<address>. 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/<address>. На настоящий момент вывод исключительно в формате для экранного просмотра, так как проводится тестирование и анализ верности выдаваемых результатов. Будем благодарны, если найдёте какие-то несостыковки и сообщите.
P.S. пока остаётся не ясным один момент: если ли необходимость выводить генерационные транзакции PoS блоков.
|
|
|
Сколько времени прошло, и ни кто не заметил, что на домашней странице ссылка на русскую тему толка отсылает на старую закрытую тему, исправлено. Есть предложения по Novaco.in API. Хотелось бы метод, который учитывал и PoS специфику: - отображает только кол-во входящих и исходящих транзакций(pos игнорируется) - для слежения за средствами на адресе;
Задача примерно ясна, это не было реализовано, т.к. в принципе метод getbalance (а я так понимаю, что речь идёт именно о нём), не был расчитан на развёрнутую схему работы с транзакциями. В данном случае была необходимость в получении только тех транз, которые в настоящий момент могут быть потрачены. Для запрашиваемой схемы работы, думается, надо использовать отдельный метод типа gettransactionlistbyaddress, где выводить всю развёртку по адресу как это сделано в самом эксплорере при работе с адресом. Только тут могут быть большие накладные расходы, связанные с объёмом передаваемых данных, это отдельная тема, требующая обсуждения. Как вариант, возможно будет принято решение реализовать вывод как всех (как указано ранее) транз, так и тех, которые ещё не потрачены, но вне зависимости от возможности их траты. Но тут встаёт "политический" вопрос о наименовании/ключевании методов и их принципиальной необходимости реализации. - отображает сразу увеличение баланса от PoS, или возможность указывать кол-во подтверждений;
В принципе это то, что следует при реализации указанного ранее метода, т.к. там будет необходимым указание на то, была ли потрачена или подтверждена транза. Не хотите выложить реализацию серверной части API? Я бы запилил где то на амазоне хост для таких шалостей.
Реализация серверной части API сайта неизменно за собой потянет реализацию всего механизма работы серверной части сайта (БД, демоны, обработчики по cron и т.п.). Да и вряд ли сейчас разрабы согласятся поделиться этой инфой, т.к. уже были удачные эксперименты для запилки этого движка для работы с другими коинами (в т.ч. в другими алгоритмами хэширования) буквально за считанные часы. Да и принципиально сам движок ещё сыроват. До сих пор остались нерешёнными некоторые проблемы с правильной выборкой транз с учётом всех особенностей работы PoS механизма, т.е. конечный итог считать научили давно, а вот с промежуточными и с некоторыми выборками есть нерешённые проблемы. Да, кстати, Zloy сейчас вспомнил о то, что давно хотел допилить демон серверой части WebSocket, что позволит, надеемся, немного разгрузить сервер в плане запросов при обновлении эксплорера, а заодно, думается, и реализовать обновление некоторых других статистических страниц, на которых изначально от этого отказались.
|
|
|
Нужен список актуальных клиентов на основном сайте, в идеале календарик(до какого будет актуален).
Пример, если не трудно.
|
|
|
Реквестирую у novaco.in фичу по отображению суммарного баланса по заранее определенному множеству адресов. P.S. у блок эскплорера веб апи был?
Это уже обсуждалось, но в связи с тем, что планировалось написать JS тонкий клиент, то остановились пока на апи-методе для https://novaco.in/api . P.S. может создать форум на другой площадке уже чисто для новы? P.P.S. общий тред с обсуждением можно уже вести на сайте nvcbank
Насчёт форума вопрос уже задавался, поднять его не столько проблематично, сколько надо время чтобы настроить и выпустить. Пока просто физически некому заниматься.
|
|
|
Что-то у Пенька графики строятся всегда для текущей сложности сети, а не по рассчитанным данным Возможно и баг, будем проверять. Наконец-то дошли руки обновить portage для gentoo, но оттестировать пока не было времени, так что будем благодарны если кто-то это сделает. И как всегда спасибо sir.miklosh за своевременные ebuild'ы (выложили вместе с portage). P.S. Накопилось много работы на сайте, но руки всё не доходят в связи с занятостью разработчиков в других проектах.
|
|
|
Верните novaco.in - где морда?
Злой решил обновить систему. Selinux не заставил себя долго ждать и залочил то, что до того было разрешено Кстати, появилось предложение по сервису: добавить идентификацию адресов c подтверждением. Планируется сделать следующим образом: создать форму где указывать адрес, наименование и транзакцию, подтверждающую владение адресом. Запрос будет считаться подтверждённым если транзакция находится в последних 6 блоках. Предварительно обсуждалось, что за добавление (изи изменение) необходимо будет отправить "флаг" (01) NVC, а для удаления - (10) NVC.
|
|
|
Зашел к диалог, половину сделал, и тут выясняется, что надо вставить ID транзакции - а оно в окне кошелька, а при переходе в окно кошелька - оно убегает... и т.д. и т.п.
Как раз такой случай был заранее предусмотрен при разработке страницы для работы с мультисигом. Выборку входящих транз для адрес сделать не является большой проблемой.
|
|
|
Кстати, владельцы https://novaco.in/ а можно добавить какую-нибудь страничку разработчиков, где каждый кто в текущий момент делает какой-то патч для кошелька мог бы об этом написать, чтобы не делалось двойной работы(как в случае с виджетом сетевого трафика, когда его одновременно писали я и gades) Плюс всегда интересно что в ближайшее время добавится в кошелёк. Теоретически возможно всё Можно было бы сделать в самом блоге, создав там отдельную рубрику, но оно как-то не особо будет вязаться, я думаю. Предложите варианты движка, а дальше посмотрим и обсудим.
|
|
|
Yes, it is not correct request... Mistakes associated with orphan blocks, we will fix it later... Thanks... Updated.
|
|
|
In API added new method gettransaction
|
|
|
|