Blocks

[xloem]

This adds api functions for retrieving blocks. Merges on top of #78.

[AustEcon]

At first look (on my cell phone) looks good but want to think about it more just because it is a long-term commitment to support queries for blocks going forward. But most 3rd party apis do provide that so... should be fine I guess.

[AustEcon]

where's the merkle root? It's available in the json response from all apis... and if there was any reason to be pulling block headers like this it would be for SPV verification - which needs merkle root

[AustEcon]

I'm not sure about this.

I just tried to use bsvbookguarda.get_block("000000000000000005bcd41e65b53715f7ca19344e3c1315bb2ea7e8779b7ff7") and there are 56,439 txs (which is only a tiny 14MB but it blocked up and took forever to process - I am not sure if pulling entire blocks worth of json txids over http REST APIs is such a good idea...

I wonder if this may be beyond the scope of bitsv until/unless there are APIs that support just fetching the 80 byte block headers. I think the business of collating all of the txids in a block is more something that should be done on a server whereas bitsv is meant to be lightweight client software.

If you wanted just the 80 byte headers, that would be different and maybe ElectrumX could be a better fit (only fetches the headers and is a more efficient protocol)? (aiorpcx is the client for it - but it's async so would have to wrap it to make it blend in to the rest of bitsv)

What do you think @teran-mckinney ?

[xloem]

Thanks for your replies; I haven't found them all yet. It sounds like it would be good for transaction fetching to be in a separate generator, so the block metadata can be retrieved without all the transactions. It might be a while for me to get back to this.

[AustEcon]

Sorry I don't think it is appropriate for bitsv to be pulling entire blocks from an http REST API.

There's no point including it because it won't ever scale and is out of scope for bitsv