At least I don't think so! I'm trying to create a wallet infrastructure to minimise fees, and so I've been experimenting with raw transactions. I'm quite clueless but fortunately have enough sense to use testnet instead of the real thing :) I created a simple raw transaction using a perl script that executes rpc commands to bitcoind. I picked a UTXO that had 0.0625 tBTC on it and tried createrawtransaction, signrawtransaction followed by sendrawtransaction. I ran this a few times over the same utxo with the result:

{"result":null,"error":{"code":-26,"message":"66: insufficient priority"},"id":null}

(I was trying to see how the number of confirmations affected the priority so I did this at intervals)

Then at some point I started getting: {"result":null,"error":{"code":-27,"message":"transaction already in block chain"},"id":null}

and yet as far as I can see, it is not on the block chain. I checked the receiving address both by rpc (of course it is my address) and using blocktrail.com/tBTC. Nothing on the receiving address, the original utxo is still there and nothing has changed in my wallet. I tried restarting bitcoind and a rescan but without any success.

What has happened? I am assuming it is not possible via raw transactions to fool the network into thinking the transaction has been transmitted when it hasn't - that would be a major flaw I think. Perhaps my copy of the blockchain has become corrupt? Do I need to reindex to purge this? (Reluctant to try this because in my experience it can take a long time.) Any other suggestions for dealing with this?

Thanks for any help!


Actually I'd thought the txid would be returned by the network (and thus would be returned on successful submission) but I guess then it is a hash of the info it contains? Anyway, thanks Nick for inadvertently teaching me sthg there :) So I did decoderawtransaction and I get the following output

$VAR1 = {  
   'locktime' => 0,
   'vin' => [{  
      'sequence' => 4294967295,  
      'vout' => 1,  
      'txid' => '5ef8db75b8f3590dda1865f1dc4810b6d4be56775e4af43b6a394dccafe4422f',  
      'scriptSig' => {  
         'hex' =>   '483045022100f24e41182ae3f1663b2bde4f9ff2d2e6ce66c0379ab8559c143a442460573da602206a28496206d5881bbb4eea9aa761bf07b3af2b8a6ca44b59e40a9b77059b91ad012102a3012dad956be238d9e17cd1b1473cd0c66968d479e3311e320b2c7b02dfa8b5',  
         'asm' =>   '3045022100f24e41182ae3f1663b2bde4f9ff2d2e6ce66c0379ab8559c143a442460573da602206a28496206d5881bbb4eea9aa761bf07b3af2b8a6ca44b59e40a9b77059b91ad01 02a3012dad956be238d9e17cd1b1473cd0c66968d479e3311e320b2c7b02dfa8b5'  
  'version' => 1,  
  'txid' => '3bc11bfb7778ad806619f8190231cf907302cfc545d7e5116e24a15795646583',  
  'vout' => [ {  
     'scriptPubKey' => {  
         'hex' =>   '76a91468fd391d83c31283c00bc8b481f3eb698e33799c88ac',  
         'asm' => 'OP_DUP OP_HASH160 68fd391d83c31283c00bc8b481f3eb698e33799c OP_EQUALVERIFY OP_CHECKSIG',
         'type' => 'pubkeyhash',
         'reqSigs' => 1,
         'addresses' => [ 
      'n' => 0,
      'value' => '0.06257'
   } ]

I guess the txid in question is then


? Again, I can't find this on blocktrail.. and I still have the same error?

  • Could you post the TXID so we can search for it ourselves? – Nick ODell Mar 24 '15 at 6:44
  • 1
    Hi Nick - I edited my question – tom Mar 24 '15 at 8:45
  • Thanks tom! That's really odd; it shouldn't do that unless you have a different set of blocks than a testnet block explorer. Could you compare getblockcount on your local system to blockexplorer.com/testnet/q/getblockcount ? – Nick ODell Mar 24 '15 at 9:45
  • 1
    328860 for both? – tom Mar 24 '15 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.