|
Title: sendrawtransaction -> "TX rejected" -> TX appears in block Post by: monsterer on October 12, 2013, 05:04:44 PM 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. Title: Re: sendrawtransaction -> "TX rejected" -> TX appears in block Post by: michagogo on October 12, 2013, 09:20:05 PM 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. Title: Re: sendrawtransaction -> "TX rejected" -> TX appears in block Post by: monsterer on October 12, 2013, 09:38:26 PM 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. Title: Re: sendrawtransaction -> "TX rejected" -> TX appears in block Post by: michagogo on October 13, 2013, 07:51:00 AM 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. Title: Re: sendrawtransaction -> "TX rejected" -> TX appears in block Post by: monsterer on October 13, 2013, 10:21:23 AM 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 :) Title: Re: sendrawtransaction -> "TX rejected" -> TX appears in block Post by: monsterer on October 13, 2013, 11:34:52 AM 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. Title: Re: sendrawtransaction -> "TX rejected" -> TX appears in block Post by: michagogo on October 13, 2013, 12:26:14 PM 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. |