Ну, тогда клиент Bitcoin, возможно, придется отразить всю функциональность, которая доступна при выполнении запросов SQL против полноценной СУБД.

Я не вижу, как, если вы говорите о проблемах масштабируемости, которые получили бы решены хорошими Bitcoin обратных вызовов.

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

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

Да, этот подход является неоптимальным, но ИМО это только один, что позволяет достаточно гибкости в отношениях, которые вы хотите иметь дело с данными.

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

Это, имхо наилучший подход для веб-приложения.