sendrawtransaction -> "TX rejected" -> TX appears in block

[monsterer]

Hi guys,

Getting this weird problem when calling "sendrawtransaction" on bitcoind. I receive a "TX Rejected" error, but there is no message in the debug.log and in fact the transaction then appears in a block ok?

This is on testnet.

Example transaction: http://testnet.btclook.com/txn/f5c743767b10117340e450639fbdbcfdc4e2b0a355081b70c4c6a1b7efb3803c

Anyone experienced this behaviour?

Cheers, Paul.

[michagogo]

Hi guys,

Getting this weird problem when calling "sendrawtransaction" on bitcoind. I receive a "TX Rejected" error, but there is no message in the debug.log and in fact the transaction then appears in a block ok?

This is on testnet.

Example transaction: http://testnet.btclook.com/txn/f5c743767b10117340e450639fbdbcfdc4e2b0a355081b70c4c6a1b7efb3803c

Anyone experienced this behaviour?

Cheers, Paul.

Hard to say for sure without more details, but keep in mind that you'll get a "TX Rejected" message if you try to sendrawtransaction a transaction which is already in your node's mempool.

[monsterer]

Hard to say for sure without more details, but keep in mind that you'll get a "TX Rejected" message if you try to sendrawtransaction a transaction which is already in your node's mempool.

Aren't those usually accompanied by a debug.log entry about outputs being consumed already? These are unique in that they are fresh transactions using unspent outputs and there is no error in the debug.log after sendrawtransaction appears.

[michagogo]

Hard to say for sure without more details, but keep in mind that you'll get a "TX Rejected" message if you try to sendrawtransaction a transaction which is already in your node's mempool.

Aren't those usually accompanied by a debug.log entry about outputs being consumed already? These are unique in that they are fresh transactions using unspent outputs and there is no error in the debug.log after sendrawtransaction appears.

Did you try a getrawtransaction on the hash to see if it was in the mempool? It wouldn't be rejecting it because the inputs were already spent, it'd be rejecting it as a duplicate.

[monsterer]

Hard to say for sure without more details, but keep in mind that you'll get a "TX Rejected" message if you try to sendrawtransaction a transaction which is already in your node's mempool.

Aren't those usually accompanied by a debug.log entry about outputs being consumed already? These are unique in that they are fresh transactions using unspent outputs and there is no error in the debug.log after sendrawtransaction appears.

Did you try a getrawtransaction on the hash to see if it was in the mempool? It wouldn't be rejecting it because the inputs were already spent, it'd be rejecting it as a duplicate.

I didn't, but I will do thanks. That will help to rule out that possibility

[monsterer]

Did you try a getrawtransaction on the hash to see if it was in the mempool? It wouldn't be rejecting it because the inputs were already spent, it'd be rejecting it as a duplicate.

Bingo! Many thanks for your help - this was being caused by a loop in my code which went awry and tried submitting the same transaction multiple times

For anyone wondering how to get the hash of a transaction (and therefore TXID) before its been submitted, you can simply call decoderawtransaction on the signed transaction.

[michagogo]

Did you try a getrawtransaction on the hash to see if it was in the mempool? It wouldn't be rejecting it because the inputs were already spent, it'd be rejecting it as a duplicate.

Bingo! Many thanks for your help - this was being caused by a loop in my code which went awry and tried submitting the same transaction multiple times

For anyone wondering how to get the hash of a transaction (and therefore TXID) before its been submitted, you can simply call decoderawtransaction on the signed transaction.

(or, ya know, just hash it  )