very cool! yes, put this in obelisk. try to keep it modular, and we can
think how to integrate this. obelisk is also a payments backend for
websites.
about bloom filters: they aren't more private, and not efficient. bloom
filters in bitcoin has several big problems.
> On Mon, Mar 24, 2014 at 5:00 PM, Amir Taaki <genjix@???> wrote:
>> 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.
>
> I like this, and the prefix thing is a good idea for privacy. A bloom
> filter could give even better privacy, but might be a lot harder to
> look up efficiently.
>
>> 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.
>
> The watcher will be one or more C++ classes, not a binary (maybe sx
> could wrap it in a binary). I imagine an interface somewhat like this:
>
> class watcher()
> {
> watcher(obelisk::fullnode_interface& connection, watcher_listener&
> listener,
> watcher_state* saved_state=nullptr);
>
> watch_address(payment_address address, frequency);
>
> watcher_state save();
>
> uint64_t get_balance(payment_address address);
> output_info_list get_utxos(payment_address address);
> };
>
> Upon calling watch_address, the watcher will begin monitoring that
> address, and will notify the listener if anything happens there. The
> listener doesn't care *how* this happens, as long as it happens.
> Whether the watcher talks to obelisk, starts up an SPV node, or does
> something else entirely is irrelevant. If obelisk changes to a new
> model, such as what you described, watcher clients wouldn't be
> affected.
>
> Basically, this class abstracts away all networking. The wallet
> doesn't care about networking; it cares about addresses and the
> balanaces available at those addresses. This class provides that
> abstraction.
>
> -William
>
::
Re: [Libbitcoin] Wallet-watcher ser…
