Hey Dave.
Thanks for the reply. I wasn't sure my message had gone to the list. Is
there a list archive somewhere I can browse?
I quickly realized my mistake about trying to use the signature script and
figured out how to get the prev tx outputs instead. So that is working now.
I understand the points you make about the address index being a hack,
etc. However, it is a very useful hack for my application where I need to
display a list of transactions (in/out) for an arbitrary set of addresses.
I guess it is useful for others also or it wouldn't be there. Indeed, the
existence of the address index and searchrawtransactions API is what
motivated me to try out btcd in the first place. Then I found that the
API is 95% of the way there, but needs one tweak to provide the data I need
and another tweak (filtering) for efficiency.
So I am working on those two things (separately). I hope to get my changes
merged in, but if that's not possible I guess I'll just have to run a
fork. Either way, btcd is making possible what other offerings couldn't.
I've actually conducted a pretty thorough review of presently available
blockchain APIs before finding btcd.
Specifically:
bitcoind -- doesn't maintain address index and has no way to query
transactions for arbitrary addresses.
toshi -- provides addr tx API without limits/paging and works for my
needs. However:
1) too slow with large transactions.
2) I hacked the code and added filtering for massive API speedup,
however:
the giant DB takes forever (months) to fully sync without
SSD.
obelisk -- difficult to interface with. didn't investigate further.
other online APIs -- do not offer self-host. Also all require paging of
tx data, which is too slow and cumbersome for my needs. At least one has
hard-coded limit of 100 with no paging. some require API key which is
annoying and limits usefulness of my open-source tool.
In case anyone is wondering, the (optional) filtering I refer to above
would modify searchrawtransactions so that it only returns inputs and
outputs that reference the input address. ( technically: the vin's
prev_out tx references... ) This should result in huge speedups for
large transactions with hundreds of outputs. With toshi, this change made
a 28mb json result drop to a few k and go from 10+ seconds to about .01 sec.
regards,
Dan
