A transaction paying to a key in the wallet gets conflicted (orphaned, but marked as -1) after a restart, if it's part of a chain of unconfirmed transactions #3858

Probably it would be a desired behavior to save all the ancestors on the wallet on shutdown, or at least asking for them to other peers on launch.

Yes this can happen now, as we start with an empty mempool.

I think that we should store ancestor transactions in the wallet in this case. This is what vtxPrev (which was removed) was for but it never worked.

Another option (not exclusive) would be to save/restore the mempool. This is also necessary for floating fees (implemented in #3335).

I'd mark this as low priority; lets say you have a chain of unconfirmed transactions A->B->C.

The sender and receiver of A will rebroadcast it until it gets mined.

And the senders of B and C will rebroadcast them until they get mined. The receivers may not, if they restart and lose their memory pool. But imagine A does get mined-- now all of the dependencies of transaction B are in the block chain, and sender and receiver will both rebroadcast until it is mined.

Also: part of the smart transaction fee work is to save and restore the memory pool, so there is no need to save parent transactions in the wallet.

The mempool save/restore would solve the immediate issue, but I do think it would be safer to keep a copy of parent transactions in the wallet, and rebroadcast them if needed.

It will usually be the case that the owner(s) of those transactions will rebroadcast them themselves, but what if they do not? What if the transactions expire out of the mempool (or other nodes' mempools)? The child transaction would never confirm and data of parent transactions is just lost (also reorganizations could mess with this)

In the end the receiver wants to make sure that the transaction gets confirmed, and within that responsibility could be keeping a record of parent transactions 'just in case'. This was the idea behind vtxPrev.

But maybe I'm overly paranoid.

Mmm.... You open yourself up to a fill-up-memory DoS attack if you just blindly save parent transactions. There are probably also privacy-destroying attacks if you blindly rebroadcast unconfirmed parents.

I'd vote for keeping the current simple behavior, and re-examining this if there is actually a problem in practice.

This is a financial system. You can't be paranoid enough. :P

Having to rely on other peers to keep broadcasting transactions needed to confirm a payment sound like poor security to me, and may open the door to some kinds of social engineering attacks...

If you are paranoid, then DO NOT ACCEPT ZERO CONFIRMATION TRANSACTIONS. THEY ARE NOT SAFE.

Rebroadcasting them will not make them safer, and may lead to a false sense of security.

This doesn't seem to be an issue that people encounter in practice.