#36398 wallet: only rebroadcast transactions originating from the wallet
| Reviewability | Reviews | Agreement | Size | ||||
|---|---|---|---|---|---|---|---|
| #36398 wallet: only rebroadcast transactions originating from the wallet | Waiting on author | 0 -1 | Blocked | 18 + 10 tests | |||
|
|
|
| ||||
Reviewability: ReadyStalePaused Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs. Size: lines added or modified outside tests, then in tests; greener = smaller. | |||||||
Goal
Restricts wallet periodic rebroadcast and mempool resubmission on startup or import to transactions originating from the wallet. Unconfirmed transactions that do not spend any wallet inputs (i.e. incoming payments) are skipped.
Problem: Nodes leak network identity simply by passively running a wallet: if an attacker sends a low-fee transaction to a target address, the recipient node will rebroadcast it after a timeout or retain it across restarts, allowing observers to associate the node's IP address with the wallet.
Evidence of importance:
- Fixes issue #3828 ('Clients leak IPs if they are recipients of a transaction'), open since 2014.
- PR description notes: 'rebroadcast of transactions paying the wallet (but not spending any wallet inputs) is a privacy leak, since anyone can generate these, choose a low fee, and observe who rebroadcasts them.'
Risk of a mistake: medium (wallet). A flaw in identifying originating transactions could cause a user's own outgoing transactions not to rebroadcast if dropped from the mempool.
Changed since the previous assessment: Added release notes detailing that incoming transactions are no longer rebroadcast or reloaded into the mempool on startup.
Reviewability
Paused · Waiting on author
Open objections from achow101, fametrano, vasild with no author reply for 7 days; review would repeat what has been asked.
Waiting on (from the thread read):
- author: response to objections regarding CPFP rebroadcast and mempool re-entry 2026-10-25
Agreement
Blocked
objection that needs a change, nobody has replied (achow101, fametrano)
Thread notes: Added an objection from fametrano detailing that wallet-created CPFP children fail to re-enter the mempool or rebroadcast after restart or expiry because unconfirmed parents are omitted. The PR remains blocked awaiting author reply.
Objections, suggestions, and questions:
| Reviewer | Type | Harm, request, or question | Status | Must be | Author replied | Quote |
|---|---|---|---|---|---|---|
| achow101 (member) | objection, approach | Rebroadcasting incoming transactions is useful to help get them confirmed | open | changed | no | 2026-10-01: 'Rebroadcasting transactions that are not ours is useful as rebroadcasting does have an effect on getting such transactions confirmed.' |
| achow101 (member) | objection, correctness | Incoming transactions must be in the mempool for the wallet to CPFP them | open | changed | no | 2026-10-01: 'Furthermore, if we want to CPFP a transaction, it needs to be in our mempool first, otherwise the wallet will be unable to broadcast the child.' |
| achow101 (member) | suggestion, approach | Consider enabling rebroadcasting in a privacy-preserving manner, such as a node rebroadcast pool, rather than deleting it | open | answered | no | 2026-10-01: 'Instead of trying to delete rebroadcasting in the name of privacy, we should consider other ways to enable rebroadcasting in a privacy preserving manner, such as a rebroadcast pool in the node.' |
| instagibbs (member) | suggestion, approach | Start a fresh issue to lay down and compare rebroadcast alternatives side by side | answered · achow101 opened issue #36403 for discussion | answered | by others | 2026-10-01: 'I think we need to start a fresh issue on the topic and lay down alternatives side by side' Status from: 2026-10-01: achow101: 'I've opened #36403 where we can have more high level discussion about transaction rebroadcast in general.' |
| vasild (member) | suggestion, interface | Make the behavior configurable (such as extending -walletbroadcast) so users can decide what fits their priorities | open | answered | no | 2026-10-06: 'Concept ACK, but make this configurable somehow.' |
| fametrano (contributor) | objection, correctness | A CPFP child created by the wallet stays out of the mempool and is not rebroadcast after a restart without mempool.dat or mempool expiry because its unconfirmed parent is skipped | open | changed | no | 2026-10-25: 'After a restart without mempool.dat, or after mempool expiry, a CPFP child that the wallet itself created for an incoming payment stays out of the mempool on this branch, and no resend timer brings it back.' |
Support:
- vasild (member) (Concept ACK, 2026-10-06): make this configurable somehow to let users decide what is best for them [not substantive]
Participants:
- achow101 (member, objection, 2 statements 2026-10-01 to 2026-10-01): Concept NACK-ish: notes rebroadcasting incoming txs helps confirmation and is needed for CPFP; suggests a node rebroadcast pool
- instagibbs (member, neutral, 1 statements 2026-10-01 to 2026-10-01): linked past rebroadcast pool PRs and suggested opening an issue to compare alternatives
- vasild (member, support, 1 statements 2026-10-06 to 2026-10-06): Concept ACK, suggested making the behavior configurable
- fametrano (contributor, objection, 1 statements 2026-10-25 to 2026-10-25): demonstrated regression where wallet CPFP child transactions fail to re-enter mempool or rebroadcast after restart or mempool expiry
Files
14 lines under test/bench/ci.
- test/functional/wallet_resendwallettransactions.py +10/-4
- src/wallet/wallet.cpp +10/-2
- doc/release-notes-36398.md +8/-0
Card
The short text the ranking pass compares across PRs.
Restricts wallet rebroadcasting and startup mempool resubmission exclusively to transactions originating from the wallet (`IsFromMe`). Currently, running a wallet passively rebroadcasts unconfirmed incoming transactions, enabling an attacker to identify a node's IP address by sending low-fee transactions to an address and watching for rebroadcasts or probing mempool retention across restarts. This resolves long-standing issue #3828, with the tradeoff that recipients must manually resubmit stuck incoming payments if the sender does not rebroadcast.
Data
thread read through 2026-10-25 (5 statements), head f63a38f781
labels: Wallet
Categories
Wallet
P1 · bug fix
Fixes a long-standing network privacy leak where nodes rebroadcast incoming payments. As noted in issue #3828, an attacker can send low-fee transactions to target addresses and observe which node rebroadcasts them, leaking the wallet holder's IP address.
Membership: Has Wallet label and modifies wallet rebroadcast logic in src/wallet/wallet.cpp.
Factors: security/stability 2, bug 2, performance 0, user value 2, leverage 0