Bizarre failure on getrawtransaction rpc call

[arnuschky]

Hey,

from time to time, I am seeing a bizarre bug when processing transactions. I have a main loop that looks for new transactions. If it finds any, it gets the raw transaction from bitcoind and processes it. This works fine - so far, so good.

Unfortunately, from time to time, the call of getrawtransaction fails with the following error message:

Code:

{u'message': u'No information available about transaction', u'code': -5}

This happens quite rarely, but the weird thing is that it fails continuously for a few minutes, and only for one specific transaction. After a few minutes, it just automagically rights itself, and I manage to get the raw transaction and process it. Even more bizarrely, during the time that my code fails to retrieve the raw transaction, I can retrieve the raw transaction on the command line just fine!  

I am running bitcoind 0.8.5 with txindex=1.

Any ideas where this might come from? Is this a bug in bitcoind?

[arnuschky]

Nobody? The problem persists, and it really boggles my mind how we can have rpc report one thing while the command line reports another thing - as far as I understand both interface the same rpc call!

[arnuschky]

Some further info:

This happens on unconfirmed transactions. The commandline RPC call does not always work, sometimes I get the same error ("code":-5,"message":"No information available about transaction") as well, so at least this seems to be consistent and might have been a red herring. Just seen this again where the command line reports something else than the rpc call.

What I don't understand is that how bitcoind can show me the transaction id when using listsinceblock but then does not have the details for it present. Even more confusing if the transaction has been created locally - in this case bitcoind must know of this transaction!

Debug log is showing nothing except

Code:

ThreadRPCServer method=getblockhash
ThreadRPCServer method=listsinceblock
ThreadRPCServer method=getrawtransaction

[orz.dk]

Not exactly sure what you are trying to do, but this could probably happen if you somehow lookup a transaction that uses unspents that are not yet known to your wallet. As i understand from a few post by Peter Wuille, plese correct me: When the wallet a few minutes later comes to know about the the utx, the tx using it is moved from wallet transactions to mempool transactions, and is now lookupable with getrawtransaction, -  and you experience it as working again. listsinceblock looks in the wallet transactions (reason for discrepancy)

[arnuschky]

Thanks for replying!

Not exactly sure what you are trying to do

What I am trying to do it pretty simple: poll for new transactions and stick them into a database. My problem is that sometimes, I can't get the raw transaction using the getrawtransaction rpc call.

this could probably happen if you somehow lookup a transaction that uses unspents that are not yet known to your wallet. As i understand from a few post by Peter Wuille, plese correct me: When the wallet a few minutes later comes to know about the the utx, the tx using it is moved from wallet transactions to mempool transactions, and is now lookupable with getrawtransaction, -  and you experience it as working again. listsinceblock looks in the wallet transactions (reason for discrepancy)

This explains the difference that we see between listsinceblock and getrawtransaction. I still don't get why I can sometimes retrieve the raw transaction using the command line, while the rpc call still fails.

Do you happen to have the link of these posts?

[orz.dk]

https://github.com/bitcoin/bitcoin/issues/3220

http://bitcoin.stackexchange.com/questions/5673/debug-log-how-do-i-analyze-an-orphaned-transaction

Afaik commandline commands are also rpc commands to qt server. Can't help you as to why cmdline vs. json-rpc gives different results, guess that shouldn't happen...

[arnuschky]

The interesting part is that some of these transactions have been created by myself, and use only confirmed inputs. So no chance that they are orphaned.