Мне всегда казалось, что возраст входа считается с 0 дня, а вот его вес только с 30. Либо мой тул глючит, либо в мае были ПОС блоки, сгенерированные инпутами 90+ дней (от создания) и при этом не поделившиеся. Если есть сомнения, могу пойти вручную пересчитать используя блокэксплорер и скинуть ссылки?

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

Стоит ли ожидать такую или схожую функциональность в ближайшее время

Приветствую!
Есть подозрения, что при нахождении ПОС блока происходит деление инпутов возрастом даже более чем 90 дней. После обновления клиента до апдейт7 видел такое для инпутов 97 и 100 дней. Изменилась политика?

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

На сколько я помню, текущая реализация предполагает, что вес инпутов становится константным после 120 дней, но склеивание делается уже после 90.
В предложенном мной примере я и описал два случая до 90 дней и 90+. Склеивание инпутов указал только для случая старше 90 дней. Для инпута меньше 90 дней доступно только два варианта делить инпут или нет в зависимости от его размера. Или я где то не там ищу пример недостатков? =)

Приветствую!

Balthazar, когда предполагается ввод (крайне полезной и долгожданной) фичи, позволяющей отключить деление входа пополам при генерации ПОС?

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

Например, пользователь устанавливает это значение равным 40. Тогда:
POS для инпута возрастом 30-90 дней
   а) инпут меньше 40 монет  -  Не использовать деление на два инпута. К текущему инпуту добавить награду.
   б) инпут больше 40 монет  -  Разделить инпут пополам (текущая реализация)

POS для инпута возрастом старше 90 дней
   а) инпут меньше 40 монет -  К текущему инпуту добавить награду. При возможности подклеить другие старые(90+дней) инпуты.  (текущая реализация)
   б) инпут больше 40 монет -  Разделить инпут пополам.

Сейчас, из-за бесконтрольного деления инпутов, "наплодилась" целая куча мелких инпутов, в следствии чего и возникла необходимость добавить опцию отключающую деление. В дальнейшем, отключение деления может привести к ситуации, когда на кошельке будет несколько больших входов, рискующих попасть под обрезание награды (10 монет) и целой куче все еще мелких входов. И у пользователя опять возникнет дилемма - включать обратно деление или же смириться с обрезанием награды. Это немногим лучше текущей ситуации, когда многие решают склеивать вручную поделившиеся инпуты или нет.
Предложенный мной вариант должен решить все эти проблемы - один раз установил нужное значение и забыл. Допускаю, что я упустил какой то важный момент, который делает невозможным описанное выше =)

Hello

I am a newbie here. I have a question. I have some AM1 and AM100 shares on the havelockinvestments.com. And I received next email
"February 27th, 2014 - REMINDER: AM1, AM100, and the SMG passthrough will all be controlled by Havelock Investments by March 1st, 2014. "

Could someone please describe me what does this mail mean? And what I have to do to save my shares and continue receive dividends?

Thanks a lot for your help.

Сейчас же ведь вес входа растет 120 суток?

Изменились ли, в связи с этим, условия для автосклейки монет? Я имею в виду, осталось "инпуты старше 90 дней" или же заменилось на "инпуты старше 120 дней"?

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

Баг или так и задумано?

Поизучал вопрос. К той ситуации, которую я описывал, это не имеет никакого отношения

А ситуация, хочу напомнить, там следующая: осталось ВСЕГО 3 инпута, которые старше 90 дней (0.10, 0.15, 1.5). Инпут 1.5 сгенерировал блок, но к нему не подклеился ни один из оставшихся маленьких инпутов, хотя по требованиям они вполне подходили. Причем, подобная ситуация была не единожды. Отсюда я могу сделать вывод что возможны три варианта:
1) Все работает правильно, и я просто не до конца понимаю алгоритм выбора инпутов для подклейки.
2) В кошельке есть баг, который в определенных условиях не делает подклейку.
3) У меня есть какая то проблема в блокчейне из-за которой кошелек работает не правильно.

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

Полагаю, что адреса одинаковые. Я эту ситуацию наблюдал в своей проге, а она (пока) работает только для одного адреса. Думал, что может моя прога глючит и пропустила этот момент, но нет, проверил транзакцию, что создала этот инпут в эксплорере, статус: Not yet redeemed.

Если зависит только от рандомизации, то тогда непонятно, почему не произошла подклейка хотя бы одного мелкого инпута в случае нахождения второго блока (инпутом 1.5nvc)?

Update: И еще один момент. К вопросу о рандомизации. Это я для примера показал, что инпутов было всего 5 штук. На самом деле их было несколько больше. Так вот, они все по одному или парами нагенерировали блоки и "ушли", а эти два мелких инпута остались.

А не подскажет ли кто-нибудь, по какому принципу выбираются инпуты для склейки? Про 90 дней и POW/3 я конечно же в курсе =) Свой вопрос продемонстрирую на примере.

Есть след инпуты старше 90 дней:
1) 0.10 nvc
2) 0.15 nvc
3) 1.50 nvc
4) 2.50 nvc
5) 1.50 nvc

Инпут 1 самый древний (200+ дней) инпут 5 самый молодой (90+ дней).

Находится POS блок и происходит склейка инпутов 3 и 4. Находится еще один POS блок в которм учавствует инпут 5. А вот инпуты 1 и 2 не подклеились ни к первому блоку, ни ко второму. Может кто знает, почему так? Вижу только одно объяснение: подклеиваются только те инпуты, что следуют после инпута, сгенерировавшего блок. Так ли это?

Да, приложение .NET. А что за нативные методы (я всю жизнь embedded программированием занимался) и с программированием под виндой не сильно знаком?  Из наиболее критического я там вижу только использование Thread, да и не вдавался в подробности того как реализован WebClient. Я просто ща многое там переписываю с нуля и мог бы это учесть.

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

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

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

2svost

Ну хоть не крэшнулась на этот адрес - уже хорошо =)))))) Действительно, не ясно пока что делать с такими адресами.


Резервным обязательно возьму. Было в туду листе, забыл отразить.

Всем доброго вечера!

Я тут написал небольшую тулину для себя, поюзал ее недельку и подумал, вдруг она кому тоже будет полезна =)

Заранее прошу сильно тапками не кидать - практически первая прога на с# и практически вторая под винду.

Делает она следующее: Читает страницу на http://novacoin.ru/address/ваш_адрес, парсит ее и генерит, надеюсь, удобочитаемые таблички =) Раз в 5 минут процедуру полностью повторяет.

Screen: http://yadi.sk/d/NTlNfp8FAbtPu

Левые три таблички:
Max age - текущие инпуты старше 90 дней
Mid age - текущие инпуты от 30 до 90 дней
Low age - текущие инпуты младше 30 дней

Правая табличка представляет собой некоторую хистори. Показывает когда и какие движения монет были по данному адресу.
TRA - обычный трансфер монет, например, с пула на данный адрес
POS - сгенерированный пос.
Следом после POS идут одна или несколько строк Input (серого цвета). Это инпуты которые участвовали в генерации данного пос блока.

Собственно, ссылка на прогу: http://yadi.sk/d/k8Lkq9NiAbcc2

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

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

Miner Status (для андроида) добавил поддержку itzod. У кого-нибудь заработало? у меня почему то не желает =(

да, вот только и остается, что дудеть

потому что есть ограничение на 5 постов

+1 шаг к снятию ограничения

еще на шаг ближе к снятию ограничения