Source of a transaction can end up being wrong in the wallet

[GoogleCodeExporter]

There's a race when using the Wallet API in the most obvious way, because using 
sendCoins() will put the transaction onto the network, wait for propagation, 
and then commit it to the wallet. However by this point it's quite possible 
that the transaction was already received back from the network and processed 
it. Then the wallets own commit will be ignored because the tx is already 
there. The wallet ends up with a lower confidence in the tx than is deserved 
and won't spend the change until a confirmation.

I think this doesn't affect most users of the library because most wallet apps 
know their spends cannot fail, so use sendCoinsOffline, or manually commit the 
tx before broadcast.

Original issue reported on code.google.com by mh.in.en...@gmail.com on 18 Dec 2014 at 11:40

[GoogleCodeExporter]

Indeed, I think its bad style to rely on network propagation for committing own 
transactions. Because if the app crashes after creation but before propagation, 
the tx will gone and the user might be tempted to pay again.

Original comment by andreas....@gmail.com on 18 Dec 2014 at 12:42

[GoogleCodeExporter]

I don't think that can happen - if the tx is in the networks memory pool then 
it'll be found next time the app starts and queries the mempools of the newly 
connected peers.

The "commit only on propagation" behaviour has saved me a lot of hassle in the 
past when developing apps, because if you screw up and make a tx that doesn't 
propagate you don't end up with it stuck in your wallet.

On the other hand, it's obviously wrong that we end up confused about the 
origin. I think making maybeCommitTx() update the source if we double-commit 
will be simple and would work.

Original comment by mh.in.en...@gmail.com on 18 Dec 2014 at 12:44

[GoogleCodeExporter]

I see your point about stuck transactions. However, once you're finished 
developing the feature and you play by the consensus rules, there cannot be any 
stuck transactions. One edge case are unintentional double spends during 
replay, but in practise they were always marked as dead so they did not bother.

If stuck transactions appear to be a problem -- why not offer an API to remove 
them after some time?

Not seeing the tx *can* happen -- being connected to peers is a luxory.

Original comment by andreas....@gmail.com on 18 Dec 2014 at 12:55