В API добавлен метод gettransaction

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

Это не совсем то, что можно назвать "wallet", точнее, я бы сказал, что это совсем не то
Там просто сборка подёрганных из разных мест скриптов (генератор адресов, электрум и т.п.), практически не связанных логически, а просто обёрнутых в относительно красивую форму.

В нашем же случае результатом должен стать практически полнофункциональный (можно даже сказать "тонкий") клиент.

Ну раз сама идея поддерживается, но сделаем, думаю, так: для начала реализуем "как есть", т.е. с API функциналом сайта, а уже потом можно будет копать в любую сторону, потому как самое сложное -- это воспроизвести базовый функционал, а всё остальное, считаю, это частности.


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

Да, именно чтобы в браузере и именно чтобы код был открытый и не было претензий, что что-то куда-то на сторону "поедет".


Ну, Doom нам реализовывать не надо, а на остальное, Doom'аем, просто JS и пары мелких скриптов будет достаточно

Поступила "дикая" идея реализовать полностью кошелёк в JS.
Например, взять за основу ExtJS и в нём "наваять окошек", связав всё необходимым для кошеля кодом.
Все данные для кошеля можно получать по API, который расширить нет особых пролем, т.к. основной функционал уже давно работает на "морде".
Для хранения приватных данных можно использовать открытый файл с адресами и, например, файл с JSON-форматом данных в виде "адрес:приватныйключ" в шифрованом gzip.

Add new API method getbalance of available to spend funds, also including array of unspent outputs.

P.S. we began implementing functionalily for MultiSig addresses on JavaScript such as on http://coinb.in/multisig/ 

В ходе работ над MultiSig в API добавлен метод получения доступных к трате средств getbalance, в т.ч. с массивом непотраченных выходов.

Уже.

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

Вообще планируется воссоздать функционал с http://coinb.in/multisig/

Обновление завершено.

P.S. начинаем работать над MultiSig в JS https://novaco.in/multisig.php (генерация по адресам не работает, вводите публичные ключи), проверка тоже относительно "условная", пока не блокирующая дальнейшие действия

Обновление загрузчика блоков в БД закончено, на следующей неделе планируем обновление рабочей БД.

Понятие "вход" локальное и не имеет отношения к транзакциям, имеется в виду минимальный размер значения выхода в транзакции, на который будет обращаться внимание и который будет включен во вход новой транзакции (minimum value of output value in transaction which are used in join process).

Так в чём проблема, можно просто указывать "официальные или официально рекомендуемые".

P.S. Никто же не стал возмущаться [косо посмотрев на Penek] почему в скриншоте наш эксплорер был на последнем месте.

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

Вроде как починили, но нужна, конечно, проверка на других адресах, вдруг что ещё всплывёт.
Заодно слегка поправили отображение расхода и двойного расхода в транзакциях.

Этим уже занимаются...

Почему только напоминает? он для этого как раз и есть

я бы сказал, что скорее весом не вышел
хотя обычно наблюдается обратная ситуация, когда PoS отвергает PoW.
да и смотрю в тот час PoW "доминировал" хотя бычно бывает наоборот.


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

P.S. будем искать ошибку.