Don't resend wallet txs that aren't in our own mempool

[morcos]

No description provided.

[pstratem]

utACK

5a2b1c0

[sipa]

utACK

@pstratem Unnested ACK?

[morcos]

@laanwj sorry, needs backport

[pstratem]

@sipa typo

[luke-jr]

Why not? How will they get relayed then?

At least attempt to add it to our own mempool again before failing...

[morcos]

@luke-jr My original attempt included trying to add it to your own mempool again first, but its an unfortunate amount of cs_main locking that would be needed.
Also this behavior preserves the functionality from 0.11 when txs not in your mempool had GetDepthInMainChain return less than 0.

[gmaxwell]

ACK (with moderate testing)

[luke-jr]

Also this behavior preserves the functionality from 0.11 when txs not in your mempool had GetDepthInMainChain return less than 0.

That's a bug. They shouldn't be negative until a conflict is mined.

[luke-jr]

My original attempt included trying to add it to your own mempool again first, but its an unfortunate amount of cs_main locking that would be needed.

Rebroadcasts are rare anyway, right? I don't see why locking would be an issue...

[gmaxwell]

@luke-jr This needs to be the simplest and most obviously-does-no-harm change to avoid a serious behavior regression in 0.12. The whole rebroadcast logic in general is brain-damaged and privacy destroying and we should fix it more completely, but this PR is not the time.

[morcos]

@luke-jr yes, i'm saying that in 0.11 they were negative so weren't rebroadcast. now they aren't negative, so we need to explicitly not rebroadcast them. i dont think they are rare are they?

[luke-jr]

@morcos It was literally impossible to have a wallet transaction that was rejected by your own mempool, in 0.11.

@gmaxwell What behaviour is regressed right now? The PR is severely lacking in details on what it's trying to fix...

[gmaxwell]

@luke-jr In 0.11 same as in 0.12, a wallet transaction will be rejected by your mempool if your fee settings are higher than the tx pays.

The regressed behavior is that in 0.12 the node will continually rebroadcast non-mempoolable (and non-mempool) transactions; which is incredibly deanonymizing (and somewhat bandwidth wasting). E.g. you pay someone a tiny amount with a 1e-8/byte fee when their mempool isn't full and then their client will continue to beacon forever... and because their own node hasn't and wouldn't mempool the transaction, it's completely clear that they're the origin.

[luke-jr]

Oh! So this doesn't restore the "-1 if not in mempool" bug, it only restores the side effect of that preventing rebroadcast. Makes [enough] sense for now. Concept ACK.

[luke-jr]

@morcos Can you document the rationale here better in the commit message? Maybe something like:

wallet: Don't resend wallet txs that aren't in our own mempool

Rebroadcasting of wtx for not-in-mempool transactions was previously prevented by GetDepthInMainChain erroneously returning -1 for them. This restores that previous behaviour.

[luke-jr]

Actually, this is a new condition in 0.12, since 0.11 never would create a transaction that wouldn't be accepted to the mempool (and why the -1 bug wasn't really quite a bug in 0.11). So this does seem to indeed still change the behaviour negatively... so I guess I'm back to not seeing a justification for this change. :(

[gmaxwell]

@luke-jr "wouldn't create" is too limited, people sendrawtransaction, wallets get copied, nodes get restarted with different settings, and this covers received transactions too.

[jonasschnelli]

orange flag: another coupling between the wallet and the full-node.

[laanwj]

@jonasschnelli Sometimes I think 'outgoing' transactions need to be in a special section of the wallet. A bit like how mail programs have an 'outbox'. Newly created transactions will end up there, and are removed after trying to broadcast for a while - or when the user wants to give up on them.

It would be better than considering all transactions for rebroadcast. At the least it would give the user explicit control over that.

In any case, it doesn't need to block this sensible privacy improvement, but I agree that the rebroadcast logic is still far from optimal.

[dcousens]

utACK 5a2b1c0

[sdaftuar]

utACK

[laanwj]

utACK 5a2b1c0

[MarcoFalke]

Backported as part of #7938. Removing label 'Needs backport'.