aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorMacroFake <falke.marco@gmail.com>2022-07-08 11:04:55 +0200
committerMacroFake <falke.marco@gmail.com>2022-07-08 11:06:24 +0200
commita7f3479ba3fda4c9fb29bd7080165744c02ee921 (patch)
treed9c95edd572e1117ae869e6e19c7396fee41df6d /doc
parent172823e4d5da9bbea1ef3d32267db75a59c83276 (diff)
parent4c9666bd73645b94ae81be1faf7a0b8237dd6e99 (diff)
downloadbitcoin-a7f3479ba3fda4c9fb29bd7080165744c02ee921.tar.xz
Merge bitcoin/bitcoin#25353: Add a `-mempoolfullrbf` node setting
4c9666bd73645b94ae81be1faf7a0b8237dd6e99 Mention `mempoolfullrbf` in policy/mempool-replacements.md (Antoine Riard) aae66ab43d794bdfaa2dade91760cc55861c9693 Update getmempoolinfo RPC with `mempoolfullrbf` (Antoine Riard) 3e27e317270fdc2dd02794fea9da016387699636 Introduce `mempoolfullrbf` node setting. (Antoine Riard) Pull request description: This is ready for review. Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions against pinnings attacks and other mempool-based nuisances. The lack of full-rbf transaction-relay topology connected to miners open the way to cheap and naive DoS against multi-party funded transactions (e.g coinjoins, dual-funded channels, on-chain DLCs, ...) without solutions introducing an overhead cost or centralization vectors afaik . For more details, see [0]. This PR implements a simple `fullrbf` setting, where the node always allows transaction replacement, ignoring BIP125 opt-in flag. The default value of the setting stays **false**, therefore opt-in replacement is still the default Bitcoin Core replacement policy. Contrary to a previous proposal of mine and listening to feedbacks collected since then [1], I think this new setting simply offers more flexibility in a node transaction-relay policy suiting one's application requirements, without arguing a change of the default behavior. I [posted](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html) on the ML to invite operators with a bitcoin application sensitive to full-rbf (e.g dual-funded LN channels service providers) or mempool researchers to join a bootstrapped full-rbf activated peers network for experimentation and learning. If people have strong opinions against the existence of such full-rbf transaction-relay network, I'm proposing to express them on the future thread. [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html Follow-up suggestions : - soft-enable opt-in RBF in the wallet : https://github.com/bitcoin/bitcoin/pull/25353#issuecomment-1154918789 - p2p discovery and additional outbound connection to full-rbf peers : https://github.com/bitcoin/bitcoin/pull/25353#issuecomment-1156044401 - match the code between RPC, wallet and mempool about disregard of inherited signaling : #22698 ACKs for top commit: instagibbs: reACK https://github.com/bitcoin/bitcoin/pull/25353/commits/4c9666bd73645b94ae81be1faf7a0b8237dd6e99 glozow: ACK 4c9666bd73645b94ae81be1faf7a0b8237dd6e99, a few nits which are non-blocking. w0xlt: ACK https://github.com/bitcoin/bitcoin/pull/25353/commits/4c9666bd73645b94ae81be1faf7a0b8237dd6e99 Tree-SHA512: 9e288bf22e06a9808804e58178444ef1830c3fdd42fd8a7cd7ffb101f8f586e08b000679be407d63ca76a56f7216227b368ff630c81f3fac3243db1a1202ab1c
Diffstat (limited to 'doc')
-rw-r--r--doc/policy/mempool-replacements.md5
-rw-r--r--doc/release-notes.md4
2 files changed, 9 insertions, 0 deletions
diff --git a/doc/policy/mempool-replacements.md b/doc/policy/mempool-replacements.md
index 18f08daf88..fea0143757 100644
--- a/doc/policy/mempool-replacements.md
+++ b/doc/policy/mempool-replacements.md
@@ -15,6 +15,8 @@ other consensus and policy rules, each of the following conditions are met:
*Rationale*: See [BIP125
explanation](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#motivation).
+ The Bitcoin Core implementation offers a node setting (`mempoolfullrbf`) to allow transaction
+ replacement without enforcement of the opt-in signaling rule.
2. The replacement transaction only include an unconfirmed input if that input was included in
one of the directly conflicting transactions. An unconfirmed input spends an output from a
@@ -74,3 +76,6 @@ This set of rules is similar but distinct from BIP125.
* RBF enabled by default in the wallet GUI as of **v0.18.1** ([PR
#11605](https://github.com/bitcoin/bitcoin/pull/11605)).
+
+* Full replace-by-fee enabled as a configurable mempool policy as of **v24.0** ([PR
+ #25353](https://github.com/bitcoin/bitcoin/pull/25353)).
diff --git a/doc/release-notes.md b/doc/release-notes.md
index 35f0713879..2c3bb27935 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -86,6 +86,10 @@ Changes to GUI or wallet related settings can be found in the GUI or Wallet sect
New settings
------------
+- A new `mempoolfullrbf` option has been added, which enables the mempool to
+ accept transaction replacement without enforcing the opt-in replaceability
+ signal. (#25353)
+
Tools and Utilities
-------------------