Hey Dave, good info. thanks.
I already separated the prevout data, so it looks like:
"vin": [
{
"txid": "...",
"vout": 0,
"scriptSig": {
"asm": "...",
"hex": "..."
},
"prevOut": {
"addresses": [
"..."
],
"value": 50
},
"sequence": 4294967295
}
]
Also, the default behavior is to NOT include prevOut. This only happens if
prevout=1 is passed as a parameter.
I see what you mean about the Vin data structure being shared. I will
need to separate that out. shouldn't be hard.
Getting the data structures recognized by the help took me a little while
to figure out.
Right now the API is working when I call it directly via RPC from my app,
but btcctl is telling me I'm sending the wrong number of parameters. I
haven't really looked into that yet.
Dan
On Mon, Aug 17, 2015 at 7:54 AM, Dave Collins <[email protected]> wrote:
> 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
> >
>
>
