Resend unconfirmed transactions

[samueltardieu]

Today, I had the case where a 50 BTC transaction was apparently correctly propagated by armory as it appeared on blockchain.info, but since its only input had only one confirmation (and the transaction had no fee), it was not included right away into a block. I had to manually reinject the transaction after more than 90 minutes without confirmation (while the input had been 6-confirmed in the meantime) to finally get the transaction in a block 108 minutes after its original submission.

Armory should resend transactions with 0 confirmations appearing in the ledger when it receives a new block (because conditions for transaction acceptance, such as number of confirmations on inputs, may have been altered by this new block). That would help include incoming or outgoing transactions into the next block, even if it has since disappeared from the various bitcoind memory pools.

[etotheipi]

Unfortunately, there is an inherent problem with the way Armory connects to the Bitcoin network, that makes this idea... useless :(. The issue is that the first time you broadcast the transaction, it goes through the your bitcoind/-qt node which adds it to its memory pool and then broadcasts it. Any attempts to re-send that transaction will be seen by bitcoind/-qt as an already-seen tx and it will ignore it. I'm fairly certain there is no way to convince the node to re-broadcast unless the transaction is part of its own wallet.

This is the inherent problem with force-zero-tx-fee broadcasts too. Armory is willing to broadcast transactions that should require a fee but doesn't ... but it will be DOA when it hits the Satoshi node because it will fail the relay criteria.

Both of these are the same problem. I would consider putting in a request with the main devs to always forward transactions that are sent by localhost, but I suspect there would be concerns about DoS exploits (perhaps there'd be some way to convince nodes to forward packets that they shouldn't forward thus creating DoS vuln)

P.S. -- I have considered how I might rebroadcast a transaction, but I refuse to rely on any third-party services/sites, and I don't want to connect directly to other nodes (other than localhost) until Armory has substantial networking capability. It's current level of networking only works because localhost is completely trustworthy.

[samueltardieu]

I understand that, but at some point the transaction will leave even your own bitcoind memory pool, especially because the inputs and outputs are not handled by it. After that the transaction will be accepted again and not be detected as a duplicate, and it will be broadcast again.

[samueltardieu]

(and what surprised me here is that the satoshi client did relay it, since I could find it on blockchain.info, even though the only input was 1-confirmed and no fee was included — but no miner included it in the chain until I forced a rebroadcast, admittedly with a new bitcoind since I had to recompile it, but using the previous one [if it had the sendrawtransaction command] would probably have worked because the transaction was probably out of its memory pool)