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

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

"walletnotify" а также "blocknotify" действительно писаки, которые пересекают домен безопасности в неправильном направлении: от Интернета переднего конца на сервера учета. Только Desperados одобрит такую ​​архитектуру. Другая проблема с обратными вызовами событий являются:
1) является то, что они требуют и вызывающего абонента & системы и вызываемый модуль онлайн одновременно
2) они не имеют никаких признаков отставания отложенных обратных вызовов.

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

Другая проблема заключается в подразумеваемой масштабируемости, имеющие один blockchain и несколько бумажника. Опять же практика была показать, что люди обработки они код бумажника синхронизации с жесткими петлями опроса и другой аналогичной хромотой, что на практике несколько копий bitcoind занимают меньше процессора и пропускную способность ресурсов только больше памяти. Я думаю, что Stratum & Электрум является хорошим примером: протокол Stratum в теории обрабатывает асинхронные уведомления хорошо, но ее практическая реализация в Электруме страдает от ужасной неэффективности.

Последнее дело в том, что даже если вы решить все вышеуказанные проблемы, вы до сих пор не имеете чистый интерфейс к промышленным стандартам бухгалтерского учета инструментов: протокол Фикса в ценных бумагах и различных "промежуточные программное обеспечение / очередь сообщений" (Как, например, ZeroMQ) в общем бухгалтерском учете. С другой стороны, сырье bitcoind может быть запущен с -privdb = 0 (и минимальных заплат) и позволяет полностью интегрировать с учета бэкендов благодаря поддержке X распределенного мониторинга / Open транзакций в BerkeleyDB, чем обрабатывает бумажник.

В итоге: отдельные проблемы не трудно сам по себе, сложности в интеграции всех из них. Печальное положение в том, что различные люди вразнос неполные решения изводили с плотными петлями опроса и с непроверенной / неправильной работе цепи реорганизаций. Единственное исключение было bitsofproof но вернулся, чтобы быть закрытым исходным кодом. Почти ничего не изменилось в этом пространстве, так как я присоединился этот форум когда-то в середине 2011 года.

Вы, кажется, быть сторонником Synala. У меня есть один вопрос: было ваше решение сохранилось, по меньшей мере, один бухгалтерский аудит, проводимый с действующими стандартами бухгалтерского учета в вашей стране?

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