No one seems to use this "feature", and at any rate the behavior of relaying transactions when they violate local policy is error-prone, if we ever consider changing the ban behavior of our software from one version to the next.
Defaulting this to off means that users who use -whitelist won't be unexpectedly surprised by this interaction. If anyone is still relying on this feature, it can still be explicitly turned on.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
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.
Needs release note.
No one seems to use this "feature"
From what I vaguely remember bitonic.nl (Dutch exchange) uses, or at least used this.
Concept ACK. If we think there is still use we could add a FORCETX network message that is functionally identical to a TX message, but triggers the forced behaviour (and the user gets to live with the consequences) and is only permitted for WLed peers. I'm not aware of any continued dependency on this behaviour but we can check more.
utACK
Concept ACK. If we think there is still use we could add a FORCETX network message
Well this PR doesn't remove the functionality it only disables it by default, so IMO there is no requirement to provide an alternative here even if it is still used.
Just need to be clear about it in the release notes (could even add a line to contact someone of us if they're still using this functionality)
Updated with a release note.
From what I vaguely remember bitonic.nl (Dutch exchange) uses, or at least used this.
We use bitcoin nodes as relay, but since we don't want them to relay transactions that violate the standard rules, we don't use this feature as default.
Edit: oh, just heard that we did for a while to mitigate an other problem that has since been resolved.
utACK a36d97d
utACK a36d97d, previous behavior is still possible.