This optional parameter is used to specify the block which is used to look up the raw transaction.
Adding blockhash parameter to getrawtransaction RPC function. (Issue #…
You know if you set txindex=1 this works without the blockhash, right?
I guess this isn't so bad— it's incompatible with pruning but so is txindex=1.
Ok. But txindex requires reindex and it's bad for me (now).
"If you need that functionality, you must run once with -txindex -reindex to rebuild block-chain indices (see below for more details)"
I'm unsure about this.
On the one hand, the blocks are available, and getblock() exists- it's stupid that it cannot give you the transactions in it.
On the other hand, I really don't want to encouraging services that depend on the presense of (indexable) block chain data in the first place.
Well ... Maybe you must check this addon with the user community and decide if this is useful/compatible/promotable or not.
Meanwhile, as I say, the fork is fine for me now and I can use it.
Regards (and sorry by my basic English!)
I don't feel strongly one way or the other; code looks fine, I haven't tested (only question: do you get a reasonable error message if you specify an invalid block hash?)
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/303101f2da0550ff3b51693b65171b2b02d7f2d5 for binaries and test log.
This is an automated test script which runs test cases on each commit every time is updated.
It, however, dies sometimes and fails to test properly, if you are waiting on a test, please check timestamps and if the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
and contact BlueMatt on freenode if something looks broken.
getrawtransaction: add test for invalid block hash
Add a reasonable error message on invalid blockhash parameter at getr…
…awtransaction API function.
GetTransaction now assumes lookupHashBlock is zero or valid hash block.
Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/8b011a4871fab786913489abf3b78121a8452396 for binaries and test log.
This could happen for one of several reasons:
If you believe this to be in error, please ping BlueMatt on freenode or TheBlueMatt here.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.
I'm interested in this feature as well. I like being able to parse transaction data, regardless of whether it has been spent or no.
silvioq, do you know why it failed to build? I can't access the build log.
So, some more thoughts. The generic problem this pullreq tries to solve is very worthwhile: right now, we have the full blocks stored and indexed, but retrieving anything more than the headers and the txids in them is not possible without txindex=1. This shouldn't be necessary - just a sequential scan through the blocks is perfectly meaningful.
I'm still unconvinced about the implementation though. Doing such a sequential scan using this code here results in every block being read from disk and parsed N times, with N the number of transactions in it - only to fetch a single one from it. I have some suggestions for alternatives, but neither is perfect imho either:
Agree w/ @sipa. This functionality is OK to have, but in a different form.
The first suggestion is the most powerful, and would seem to solve many common requests: 'getblock' simply returns a full block, including all transactions.
Closing, as consensus seems to point elsewhere.