Dan, The mailing list is archived at: http://marc.info/?l=btcd
I'm not personally fundamentally opposed to modifying the searchrawtransactions output to include a "prevout" JSON object field which provides the additional information. Something of note if you tackle the change though is that currently the output format is shared with the one returned by getrawtranscations, so you'd need to separate them such that the additional details are only present for searchrawtransactions. I do think it's important to have the field as a separate object rather than just listing additional fields as a part of the input however to make it clear where the data is coming from and more clearly show how it works. Also, if you modify the searchrawtransactions result, a separate PR which modifies btcrpcclient to work with the changes will be needed (https://github.com/btcsuite/btcrpcclient/blob/master/rawtransactions.go). My biggest concern with such functionality is it might help facilitate potentially dangerous usage since it is helps encourage the notion of a "from address" which, as my previous post discussed, simply is not how Bitcoin really works and worse can lead to loss funds. For example, a common issue that crops up is applications improperly sending refunds back to the address the application thinks sent the funds. That is extremely dangerous and should not be done under any circumstances. However, having the data available is still useful in other applications such that the above concern isn't a reason to completely avoid making it available. On 8/16/2015 3:31 PM, Dan Libby wrote: > 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 >
signature.asc
Description: OpenPGP digital signature
