Closed cculianu closed 8 months ago
Rebased to resolve conflicts after merge of #211
My only remaining concern was whether to return an RPC error on unused address and/or scripthashes or whether to return null
result. Since Rostrum already returns an RPC error, for now, I will do the same, unless I hear from @monsterbitar
and/or @zander in #185 that they prefer returning null
on unused addresses.
My personal use case is to ask for this information only when I don't know. Since I don't know, chances are there won't be any history. I would prefer null to indicate that "there is no such time", but that is my personal preference.
For reference, imagine you get a seed word list and are requested to restore from that, but you aren't told what the derivation path is. You try a couple derivation paths before you find one that has history. That would mean multiple calls where you get errors, as if you had done something wrong. This is where I think null fits better than an error.
Yeah, I'll change it to null
then. We'll differ from Rostrum here but so be it. I figured the common use-case is to ask for an address where you don't know, so an empty result is still a result.
Will change it.
EDIT: I see in #185 that you want to wait for Rostrum to change it to null
, perhaps? Let's see if they will change it and then we can do same.
This is currently implemented identically to the original Electrs implementation of the method.
Note that we do not support the new Rostrum optional 2nd arg "token_filter" for this method since we don't store historical token data in the db.
Also note that unlike Electrs, but like Rostrum, we do not add anything to the features map to indicate support for this method. Instead, protocol 1.5.2 or greater will support this method.
Also in this commit: bumped protocol version to 1.5.2.