search

paulkernfeld / burnie

An SPV Bitcoin burn verification library built on webcoin
6 stars 1 forks source link

Consider use of common-blockchain #3

Open xloem opened 8 years ago

xloem commented 8 years ago

https://github.com/blockai/abstract-common-blockchain common-blockchain is a general Node specification for accessing basic blockchain data. Adaptors exist for many providers.

It might be more general for burnie to use the common-blockchain interface, and to make an adaptor for webcoin or encourage them to provide one.

I have not reviewed the details of the functioning of the common-blockchain adaptors to see if they would effectively replace webcoin, but from reading the functioning of burnie, it seems it would only have to call the commonBlockchain.Addresses.Transactions([addresses]) function and iterate the results.

paulkernfeld commented 8 years ago

@xloem thanks for this suggestion! In fact, I've been looking for something just like this for a related project, paulkernfeld/burn-stream-writer.

Based on the abstract-common-blockchain documentation, it seems like the interface doesn't accomodate SPV clients. Am I reading that correctly?

xloem commented 8 years ago

A writing application may find https://github.com/blockai/abstract-common-wallet more useful instead.

I'm not aware of the limitations of SPV very well to determine if the common-blockchain interface supports them. It would be too bad. I really like the idea of abstracting these things, maybe I could commit to forking the common-blockchain repos and fixing the issue so they can be queried for supported operations. What API funcs are needed when engaging SPV clients, and what are unavailable?

paulkernfeld commented 8 years ago

Ah, okay, yes, now I see that abstract-common-blockchain is for reading.

With an SPV client, you need to set a BIP 37 Bloom filter that advertises to other Bitcoin clients which transactions you're interested in. As far as I know, that's the only functionality that would need to be added.

xloem commented 8 years ago

After looking into it a little, I think an SPV implementation could be coded fine as is. It could accept a bloom filter in its constructor the way other implementations accept a network identifier or authentication information.

But new API functions would be needed to incrementally add new sets to the bloom filter.