Limits / Pagination for get_history

[monsterbitar]

As discussed in https://github.com/BitcoinUnlimited/ElectrsCash/issues/91 the get_history is an expensive call that would be useful to apply limits to.

I propose adding an optional from_height so that wallets can keep track of which blockheight they are fully up to date on and not request old or duplicate information.

[cculianu]

Yeah I will need to look over the code -- and see what the most efficient thing is on the server side for Fulcrum... but in principle from_height should work... I just need to double-check.

[cculianu]

Ok yeah this would work. I wonder if we should do from_height and an additional optional to_height, for clients that really just want small chunks at a time ...

[cculianu]

Meh. to_height may not be very useful. Between 2 blocks there can be anywhere from 0 to 120k tx's involving a particular address. So height difference is not the most useful for pagination... hmm.

[monsterbitar]

I think for the vast majority of usecases, blockheight pagination will be sufficient. having a max_blocks to go with from_height would let the developer make sensible requests based on expected application behaviour - some apps that have activity rarely might ask for 100 blocks at a time, while apps that have very frequent transacitons might ask for 1 block at a time. I would also suggest you let the backend restrict the max_blocks at any time (I can ask for 10 million blocks, but server can choose to only deliver 5), but would need some way for the request to inform the application of what blockheights have been processed to prevent asking for the same data twice.

For the exceptional cases, you would need something that is more fine-grained, but it seems this is somewhat problematic:

• For unconfirmed, can't use CTOR and request in order since new transactions might come along.
• Would strongly prefer not to use database id's as they're not portable.