Author

Topic: sendrawtransaction -> "TX rejected" -> TX appears in block (Read 3988 times)

member
Activity: 80
Merit: 10
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 Smiley

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  Tongue)
legendary
Activity: 1008
Merit: 1007
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 Smiley

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.
legendary
Activity: 1008
Merit: 1007
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 Smiley
member
Activity: 80
Merit: 10
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.
legendary
Activity: 1008
Merit: 1007
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.
member
Activity: 80
Merit: 10
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.
legendary
Activity: 1008
Merit: 1007
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.
Jump to: