Hey, I agree with the subscription stuff. I want to get rid of it and
move towards a history polling method.
I think it's possible to make fetch_history from a specific block height
to be very fast. Then you will fetch_history by prefix and we have a
superior privacy model for clients with the server.
The problem is when new blocks arrive you suddenly get lots of queries
from many wallets who don't need an update, so my solution is that the
blockchain server caches a tree of prefixes which are published to
clients. Then they can make a query.

The thing I like about this model is that fetch_history is
deterministic, has no state and then I can focus on optimising one thing.

The tricky question though is how to handle spends. If you take the
current stealth database, how would I add spends.
https://wiki.unsystem.net/index.php/DarkWallet/Stealth#Server_query

libbitcoin is going to be split up:
https://wiki.unsystem.net/index.php/Libbitcoin#split_project

if it's a small binary, then contrib/ or tools/ under libwallet could
work. We can also make it work as a plugin for Obelisk too which would
be cool.

On 25/03/14 00:29, William Swanson wrote:
> Hello,
> Now that the URI parser and HD wallet keys are out of the way, my next
> task is to implement a wallet-watcher service.
>
> This module is basically responsible for sitting on an obelisk
> connection and watching for incoming transactions. That way, when
> funds enter or leave the wallet, our GUI can respond appropriately.
> Equally importantly, this module will maintain a list of UTXO's for
> the wallet to pull from when spending funds. This list can be written
> to disk and re-loaded, so we can avoid re-fetching all transactions
> each time the app starts up (only new things would need to be
> fetched).
>
> I currently do about 50-70 transactions per month using the legacy
> banking system, or about 600-800 transactions per year. If we take
> this as a rough order of magnitude, we can expect our serious users to
> eventually have a few thousand distinct bitcoin addresses in their
> wallets (each transaction would get a fresh change address).
>
> Obelisk supports subscriptions, but I don't think it can handle
> thousands of subscriptions at once from the same client. Plus, there
> is no reason to be constantly checking old change addresses that will
> probably never be used again. We could probably re-check these old
> addresses once a week or so without causing problems. So, for each
> address in the wallet, the watcher service needs some sort of "check
> frequency" heuristic to keep the server load manageable, as well as a
> "last check" timestamp.
>
> Note that I don't want to put any intelligence in the watcher itself;
> the higher-level wallet will tell the module which addresses to check
> and how often.
>
> In the future, the wallet watcher server could learn to act as an SPV
> bitcoin network node, solving the check frequency problem and allowing
> it to work securely with untrusted obelisk servers.
>
> Since this is something all wallets need, I think it makes sense to
> put it in one of the libbitcoin libraries, rather than keeping it
> proprietary. The question is, which one? It probably belongs in
> libwallet, but that would create a new dependency between libwallet
> and obelisk. Maybe it belongs in libobelisk itself? Thoughts?
>
> -William Swanson
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>