question: inv mempool on connect #3721

What would be the implications of bitcoind inv'ing its mempool to a peer on connect?

In theory, miners starting a node with an empty mempool would have an incentive to download other memory pools, to avoid missing out on fee-paying transactions after a restart.

Generalized over the entire network, it might enable more deterministic transaction lifetime behavior, when coupled with existing mempool-expiration proposals. On the flip side, there may also be propagated dangers involved in semi-synchronized mempools.

In the past we'd avoided doing this because of it making the immortal transaction problem worse. Right now periodic restarts are the only things that get non-confirming objects out of mempools.

does sendrawtransaction have "currently has connected peers" as a conditional?

So, if you have no connected peers (say you disconnected the network cable or your network connection dropped for whatever reason), and you send a transaction via sendrawtransaction, it gets added to the memory pool but not relayed. There is now a dead transaction that will never be relayed. Attempting to resubmit the transaction will reject it because it's already in the mempool.

No. The ResendWalletTransactions() directly hits RelayTransaction().

Doesn't ResendWalletTransactions only apply to transactions in the wallet though? It iterates mapWallet.

I'm referring to transactions submitted through RPC via sendrawtransaction from an external source. I believe that code path only adds the transaction to the wallet through the SyncTransaction path if it involves an address the wallet cares about via AddToWalletIfInvolvingMe. So, transactions which are from an external source and don't include an address the wallet currently knows about are added to the mempool and relayed to all connected clients. When there are no connected clients, won't you end up in the situation described?

Also, sendrawtransaction does not require wallet, so it could be used with -disablewallet making the above apply to all transactions.

sendrawtransaction should really have a way to force rebroadcast of a transaction. Currently it fails when the transaction is already in the mempool, there is no way to force a rebroadcast (and if it's not in the wallet it won't automatically rebroadcast either).

Sorry, long day— I somehow missed you were asking about sendrawtransaction. I believe we have an issue someplace for making sendraw able to retransmit.

Question about that, would the design there be for clients to keep sending sendrawtransaction requests, and for each request, invs are sent out even if mempool already has the tx? Or would mempool need to do what ResendWalletTransactions currently does and keep resending txs submitted via sendrawtransaction at random intervals?

#2512 appears to be the issue @gmaxwell was referencing.

@jrick IMO for using sendrawtransaction without the built-in wallet, the design should be that you handle your own periodic rebroadcasts. This gives the most flexibility, as depending on your application you may or may not want rebroadcasts, and you may want control over when these happen. Edit: as of #3730 sendrawtransaction allows re-send.

Closing, as github is not a support center -- even though IMO it was a good question!

A better place for questions is http://bitcoin.stackexchange.com/