wallet: add an option to control rebroadcasts #36380

pull vasild wants to merge 1 commits into bitcoin:master from vasild:walletrebroadcast changing 6 files +29 −11

vasild commented at 9:01 AM on September 29, 2026: contributor

Rebroadcasting transactions that are already known to the network reveals that the wallet is related to them. The way this is done (periodically send to everybody) could have bad implications for privacy, depending on other configuration options (e.g. if the node connects to clearnet directly). Thus introduce a way to disable the rebroadcasts while keeping the initial broadcasts enabled.

Before this PR -walletbroadcast controlled both the initial broadcast and the subsequent periodic rebroadcasts (done every 12-36h). Add a new option -walletrebroadcast to control the rebroadcasts separately.

The new -walletrebroadcast is introduced with a default to false, which is a change in the default behavior.
DrahtBot added the label Wallet on Sep 29, 2026
DrahtBot commented at 9:01 AM on September 29, 2026: contributor


The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/36380.



Reviews

See the guideline and AI policy for information on the review process.

Type Reviewers

Concept NACK achow101

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.



Conflicts

Reviewers, this pull request conflicts with the following ones:
- #36330 (wallet: don't resubmit transactions under -privatebroadcast by instagibbs)
- #17783 (common: Disallow calling IsArgSet() on ALLOW_LIST options by ryanofsky)
- #17581 (refactor: Remove settings merge reverse precedence code by ryanofsky)
- #17580 (refactor: Add ALLOW_LIST flags and enforce usage in CheckArgFlags by ryanofsky)
- #17493 (util: Forbid ambiguous multiple assignments in config file by ryanofsky)
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Type	Reviewers
Concept NACK	achow101

wallet: add an option to control rebroadcasts

Rebroadcasting transactions that are already known to the network reveals that
the wallet is related to them. The way this is done (periodically send to
everybody) could have bad implications for privacy, depending on other
configuration options (e.g. if the node connects to clearnet directly).
Thus introduce a way to disable the rebroadcasts while keeping the initial
broadcasts enabled.

Before this PR `-walletbroadcast` controlled both the initial broadcast and
the subsequent periodic rebroadcasts (done every 12-36h).
Add a new option `-walletrebroadcast` to control the rebroadcasts separately.

The new `-walletrebroadcast` is introduced with a default to `false`,
which is a change in the default behavior.

57cbe86d86

vasild force-pushed on Sep 29, 2026
DrahtBot added the label CI failed on Sep 29, 2026
DrahtBot commented at 9:12 AM on September 29, 2026: contributor


🚧 At least one of the CI tasks failed. <sub>Task lint: https://github.com/bitcoin/bitcoin/actions/runs/36546473252/job/109333967547</sub> <sub>LLM reason (✨ experimental): CI failed because the lint “doc” check detected undocumented command-line arguments: -walletbroadcast and -walletrebroadcast (AssertionError).</sub>

<details><summary>Hints</summary>

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:
- Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
- A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
- An intermittent issue.
Leave a comment here, if you need help tracking down a confusing failure.

</details>
DrahtBot removed the label CI failed on Sep 29, 2026
in src/wallet/wallet.h:137 in 57cbe86d86
```
 133 | @@ -134,6 +134,7 @@ inline constexpr unsigned int DEFAULT_TX_CONFIRM_TARGET = 6;
 134 |  //! -walletrbf default
 135 |  inline constexpr bool DEFAULT_WALLET_RBF = true;
 136 |  inline constexpr bool DEFAULT_WALLETBROADCAST = true;
 137 | +inline constexpr bool DEFAULT_WALLETREBROADCAST{false};
```
vicjuma commented at 4:26 PM on September 29, 2026:

Why default to false? I feel like the responsibility for privacy should be left to users desiring privacy. The majority of them probably just want convenience. The initial -walletbroadcast did not require any setup from the user. For this, what if the user forgets to set up the -walletrebroadcast option?. IMO, I think rebroadcasting outweighs privacy so defaulting to true would be convenient. Just a thought though, I might be missing something.

vasild commented at 7:51 AM on September 30, 2026:

No strong opinion. I was influenced by #36330 which would completely disable wallet re-broadcast with no way to enable it, if privatebroadcast=1. So, this PR, even with the default to "off" is softer than that because it makes it possible to enable the wallet rebroadcast if needed.

Also, my thinking, ignoring #36330 is that the wallet re-broadcast does more harm than good. It is a privacy nightmare and only provides some service in rare cases. But this is just my guess. For sure, there are users that use it and for them it is not "rare".

This is why I think it makes sense to have the wallet re-broadcast configurable in the first place. I am fine with a default to "on" (as in master without this PR).
w0xlt commented at 6:53 PM on September 29, 2026: contributor

Can we safely disable wallet re-broadcasting? If so, why do we need re-broadcasting at all?

Even if we choose this approach, I think extending -walletbroadcast with new modes would be cleaner than introducing another parameter with a very similar name.
vasild commented at 8:04 AM on September 30, 2026: contributor
Can we safely disable wallet re-broadcasting?

I think yes. Most users don't need it, but are nevertheless exposed to the privacy leaks it brings even if they never use it.

If so, why do we need re-broadcasting at all?

It serves this scenario:
- The user creates a transaction in the wallet and broadcasts it to the network. So far so good.
- The transaction is not very high fee so is not mined immediately.
- Global mempool pressure increases and that causes the transaction to be evicted from everybody's mempools.
- Global mempool pressure decreases.
- Nobody knows about the transaction, except the user that created it.
- It would have been mined if miners where aware of it but is never mined because the network "forgot" about it. In this case the user rebroadcasting the transaction would help.
Up to your judgement if this is rare or not, but is good to have wallet rebroadcast in such cases.

Even if we choose this approach, I think extending -walletbroadcast with new modes would be cleaner than introducing another parameter with a very similar name.

Hmm, sounds like something worth considering. Currently -walletbroadcast is a boolean. What would you suggest? Something like this maybe:
- 0 no initial, no rebroadcast
- 1 initial and rebroadcast
- initialonly initial, no rebroadcast
?
mzumsande commented at 2:29 PM on October 1, 2026: contributor

I opened #36398 for a fix escpecially targeted at #3828, which doesn't have an option. One thing to note is that if we disable rebroadcast, we should probably also disable artificial resubmission to mempool (as explained there).
achow101 commented at 7:49 PM on October 1, 2026: member

I've opened #36403 where we can have more high level discussion about transaction rebroadcast in general.
achow101 commented at 9:02 PM on October 1, 2026: member

The new -walletrebroadcast is introduced with a default to false, which is a change in the default behavior.

Concept NACK

Disabling rebroadcasts by default has bad effects for the wallet.

Contributors

Labels

Linked (view graph)

#36398 wallet: only rebroadcast transactions originating from the wallet #36403 Rethinking Transaction Rebroadcasting

wallet: add an option to control rebroadcasts #36380

Code Coverage & Benchmarks

Reviews

Conflicts