diff --git a/bip-v3.mediawiki b/bip-v3.mediawiki
new file mode 100644
index 0000000000..6ad63b67e4
--- /dev/null
+++ b/bip-v3.mediawiki
@@ -0,0 +1,298 @@
+<pre>
+  BIP: ???
+  Layer: Applications
+  Title: Opt-in Policy For More Robust Fee-bumping
+  Author: Gloria Zhao <gloriajzhao@gmail.com>
+  Comments-URI:
+  Status: Draft
+  Type: ???
+  Created: 2024-01-10
+  License: BSD-3-Clause
+</pre>
+
+==Abstract==
+
+Users can set <code>nVersion=3</code> on a transaction (making it a "v3 transaction") to opt in to restrictions on spending unconfirmed outputs in exchange for improved fee-bumping reliability.
+Mempools apply a different set of policies to these transactions, including topology restrictions that make it easier to assess their incentive compatibility.
+
+==Motivation==
+
+Mempools typically accept and relay transactions that spend outputs from other unconfirmed transactions, restricting package sizes through ancestor and descendant limits
+<ref>https://github.com/bitcoin/bitcoin/blob/632a2bb731804dffe52bd4cbd90bfee352d25ede/doc/policy/mempool-limits.md</ref>
+to limit the computational complexity of mempool operations and mitigate Denial of Service attacks.
+
+Users may also create unconfirmed transactions that conflict with -- or are "double spends" of -- each other by spending the same input(s) in both.
+Instead of always keeping the first transaction, many mempools also have some kind of Replace by Fee (RBF) policy
+<ref>
+[https://github.com/bitcoin/bitcoin/blob/632a2bb731804dffe52bd4cbd90bfee352d25ede/doc/policy/mempool-replacements.md Bitcoin Core's RBF policy] at the time of writing. It is slightly different from what is described in BIP 125.
+</ref>
+to keep the transaction that would be more profitable for a miner. RBF is often employed by users as a fee-bumping mechanism.
+
+However, these policies that make trade-offs between incentive compatibility and DoS-resistance are not always perfect. In some cases, malicious actors may exploit limitations to prevent incentive-compatible transactions from being accepted or fee-bumped (''pinning'').
+
+Pinning is very relevant to contracting protocols in which untrusted parties construct and sign time-sensitive transactions to be broadcast on-chain later
+<ref>Posts about pinning in LN and LN-Symmetry:
+* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020458.html "Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning"]
+* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html "RBF Pinning with Counterparties and Competing Interest"]
+* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html "Pinning : The Good, The Bad, The Ugly"]
+* [https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md "Pinning Attacks"]
+* [https://gist.github.com/instagibbs/60264606e181451e977e439a49f69fe1 "Eltoo Pinning"]
+</ref>.
+When the funds available to be redeemed by each party depend on a transaction confirming within a specific time window, a malicious party may be able to steal money if the honest party cannot get their transaction confirmed. As such, the ability to fee-bump a transaction to entice miners to include it in their blocks is important to security.
+
+===RBF pinning through Rule 3===
+
+Imagine that counterparties Alice and Mallory have transactions (or packages) A and B, respectively, which conflict with each other. Alice broadcasts A and Mallory broadcasts B. RBF rules require the replacement transaction pay a higher absolute fee than the aggregate fees paid by all original transactions ("Rule 3"). This means Mallory may increase the fees required to replace B beyond what Alice was planning to pay for A's fees.
+
+1. Adding transaction(s) that descend from B and pay a low feerate (too low to fee-bump B through CPFP)<ref>Example: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022216.html</ref>.
+
+2. Adding a high-fee descendant of B that also spends from another large, low-feerate mempool transaction (where the ancestor feerate of the descendant is too low to fee-bump B through CPFP)<ref>Example: https://github.com/bitcoin/bitcoin/pull/25038#issuecomment-1320295394</ref>.
+
+===RBF pinning through Rule 5===
+
+RBF rules require that no replacement trigger the removal of more than 100 transactions ("Rule 5"). This number includes the descendants of the conflicted mempool transactions. Mallory can make it more difficult to replace transactions by attaching lots of descendants to them. For example, if Alice wants to replace 5 transactions and each has 21 or more descendants, the replacement will be rejected regardless of its fees.
+
+===RBF has no incentive compatibility requirement===
+
+There is currently no rule to enforce that a replacement transaction would be a better candidate for mining (Rule 6 is insufficient). A user could create a replacement transaction that pays more fees and is higher feerate, but would confirm slower than the original transaction.
+
+As a result, all transactions signed with SIGHASH_ANYONECANPAY are vulnerable to being replaced by a transaction that will confirm later than the original. <ref>https://github.com/bitcoin/bitcoin/pull/23121#pullrequestreview-766271585</ref>
+
+===Child fees don't count towards RBF rules===
+
+A transaction must meet all fee-related requirements (Rules 3, 4, 6) alone; its child's fees cannot be used. A ''Package RBF'' policy would allow a transaction's child to be used for its RBF requirements.
+
+In LN, conflicting commitment transactions signed with the same fees cannot replace each other, even if accompanied by a fee-bumping child. This limitation necessitates the presence of two anchor outputs, allowing both parties to fee-bump either commitment transaction that enters their mempool.
+
+===Package limit pinning and replacing CPFP Carve Out===
+
+Policy limits the number and total virtual size of an unconfirmed transaction's descendants. A fee-bumping child of an unconfirmed transaction (CPFP) may be rejected for exceeding the descendant limit. When a transaction has multiple outputs owned by different parties, a malicious party can prevent the other(s) from CPFPing their transaction by attaching enough descendants to monopolize the descendant limit (''package limit pinning'').
+
+LN commitment transactions rely on CPFP carve out <ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html "CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)"]</ref> to avoid package limit pinning.
+
+There are weaknesses with this approach of using 2 anchors and CPFP Carve Out. This proposal helps address a few of them (see Related Work for how other weaknesses are addressed):
+
+* A switch to cluster mempool necessitates the removal of CPFP Carve Out <ref>https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393#the-cpfp-carveout-rule-can-no-longer-be-supported-12</ref>.
+* CPFP Carve Out only allows *one more* child to be added to the transaction. This means it cannot guarantee the ability to CPFP for more than 2 parties of a shared transaction.
+
+==Specification==
+
+This document describes one set of policy rules that can realistically be deployed today and is useful to today's applications. If mempool improvements enable more accurate rules or new application requirements emerge, it may be appropriate to implement a different set of policy rules to achieve the same goal.
+<ref>Examples of potential changes:
+* If increasing the maximum child size enables a new use case while still providing acceptable pinning bounds, we can loosen that rule.
+* If [https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393 cluster mempool] is implemented and some of the rules could be applied to all transactions instead of just v3, there is no need to specify them as additional rules.
+* The implementation of things like "replacement must be more incentive compatible" could change.
+</ref>
+
+===1 Parent with 1 Small Child===
+
+In addition to the node's other standardness and policy rules, the following rules apply to transactions with <code>nVersion</code> field set to 3 ("v3 transaction").
+
+1. A v3 transaction signals replaceability, even if it does not signal BIP125 replaceability.
+
+2. A v3 transaction's unconfirmed ancestors must all be v3. Any descendant of an unconfirmed v3 transaction must also be v3.
+<ref>Rationale:
+* Requiring packages to be all-or-none v3 makes it possible to enforce v3 toplogy limits. For example, the v3 descendant limit would not be very meaningful if it could be bypassed by creating a non-v3 child.
+* Combined with Rule 1, inheriting v3 gives us the property of "inherited signaling" when descendants of unconfirmed transactions are created. Checking whether a transaction signals replaceability this way does not require mempool traversal, and does not change based on what transactions are mined.
+</ref>
+Note: A v3 transaction can spend outputs from _confirmed_ non-v3 transactions.
+
+3. An unconfirmed v3 transaction cannot have more than 1 unconfirmed ancestor. An unconfirmed v3 transaction cannot have more than 1 unconfirmed descendant. CPFP Carve Out is not granted to v3 transactions.
+<ref>Rationale:
+* The larger the descendant limit, the more transactions may need to be replaced. See #1 in Rule 3 Pinning section above. This also makes pinning using Rule 5 more difficult, since a directly conflicting transaction has fewer possible descendants.
+* These two limits (ancestor count 2, descendant count 2) effectively create a cluster limit using the existing ancestor and descendant limits. Increasing them to 3 would imply an infinite cluster count limit.
+* This 1-parent-1-child topology makes it possible to use ancestor score (minimum of ancestor feerate and individual feerate) as a measure of incentive compatibility.
+
+<br />Q: Why not allow multiple parents to enable batched fee-bumping?
+<br />To mitigate Rule 3 pinning, we need to prevent a child of an unconfirmed v3 transaction from bringing in more unconfirmed ancestors. See #2 in Rule 3 Pinning section above.
+
+<br />Q: Why not allow another child?
+<br />Allowing another child disables the ability to use ancestor score to measure incentive compatibility. Imagine the original transaction, A, has a child B and co-parent C (i.e. B spends from A and C). C also has another child, D. B is one of the original transactions and thus its ancestor feerate must be lower than the package's. However, this may be an underestimation because D can bump C without B's help. This is resolved if v3 transactions can only have v3 ancestors, as then C cannot have another child.
+
+<br />Q: Why allow any descendants at all?
+<br />At least 1 descendant is required to allow CPFP of the presigned transaction. Without package RBF, multiple anchor outputs would be required to allow each counterparty to fee-bump any presigned transaction. With package RBF, since the presigned transactions can replace each other, 1 anchor output is sufficient.
+</ref>
+
+4. A v3 transaction that has an unconfirmed v3 ancestor cannot have a sigop-adjusted virtual size larger than 1000vB.
+<ref>Rationale: Limit the amount of virtual bytes (and thus fees) that may need to be replaced, while leaving a comfortable amount of space for inputs to fund the transaction.
+<br />Q: Why not bigger?
+<br />The larger the descendant size limit, the more vbytes may need to be replaced. With default limits, if the child is e.g. 100,000vB, that might be an additional 100,000sats (at 1sat/vbyte) or more, depending on the feerate. Restricting all children to 1000vB reduces the upper bound of the additional fees by a factor of 100.
+
+<br />This rule is also easily tacked on to existing logic for policy and wallets. A maximum size standard transaction (100KvB) can have up to 1000vB of descendants to be within the default descendant limit (101KvB).
+
+<br />Q: Why not smaller?
+<br/>The smaller this limit, the fewer UTXOs a child may use to fund this fee-bump. For example, only allowing the v3 child to have 2 inputs would require wallets to maintain a pool of high-value confirmed UTXOs. However, as the fee-bumping child only needs to fund fees (as opposed to payments), just a few UTXOs should suffice. With a limit of 1000vB and usage of taproot outputs, the child can have 15 inputs and 2 outputs (calculated using [https://bitcoinops.org/en/tools/calc-size/ this tool]).
+</ref>
+
+5. An individual v3 transaction is permitted to be below the mempool min relay feerate, assuming it is considered within a package that meets the mempool's feerate requirements.
+<ref>Rationale: This allows contracting protocols to create presigned transactions with 0 fees and fee-bump them using CPFP at broadcast time.
+</ref>
+
+This 1-parent-1-child (aka cluster size 2) topology restriction makes v3 transactions much easier to reason about, which enables implementing additional RBF features
+<ref>
+For example, [https://github.com/bitcoin/bitcoin/pull/25038 this implementation] of package RBF compares the replacement and to-be-replaced transaction(s) using their ancestor scores. This score is accurate for v3 transactions due to their limited cluster size.
+[https://github.com/bitcoin/bitcoin/pull/28984 This implementation] of package RBF uses a feerate diagram.
+There are also suggestions to allow "sibling eviction" for v3: if a new transaction would exceed a transaction's descendant limit, consider evicting a descendant if it is low fee(rate). Sibling eviction is feasible for v3 because the question of which child to evict is trivial; there is only 1 option.
+</ref>.
+
+
+Implementation: https://github.com/bitcoin/bitcoin/pull/28948 and https://github.com/bitcoin/bitcoin/pull/28984
+
+==Backward Compatibility==
+
+Transactions with <code>nVersion=3</code> were previously nonstandard. There are no known conflicts with previous usage.
+
+==Intended Usage==
+
+Generally, users with no interest in spending unconfirmed outputs from a transaction can use v3 for more robust RBF abilities.
+
+This proposal allows for a different solution to fee-bumping in LN, in which commitment transactions are signed with 0 fees and include a single anchor that can later be used to add fees at broadcast time
+<ref>Proposals for changes to LN commitment transaction format using v3 and a single anchor:
+* [https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 "Lightning transactions with v3 and ephemeral anchors"]
+* [https://github.com/instagibbs/bolts/commits/zero_fee_commitment bolts proposal branch]
+* See "Intended usage for LN" section in [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html "New transaction policies (nVersion=3) for contracting protocols"]
+</ref>.
+A similar fee-bumping model can also be used in other contracting protocols
+<ref>Examples of non-LN protocols that have shown interest in, designed, or built fee-bumping using v3:
+* A LN-Symmetry implementation using v3 and ephemeral anchors: [https://delvingbitcoin.org/t/ln-symmetry-project-recap/359 LN-Symmetry Project Recap] [https://github.com/instagibbs/lightning/tree/eltoo_support branch]
+* See "Managing Fees Safely" mentioning ephemeral anchors in [https://jameso.be/vaults.pdf "Vaults and Covenants"]
+</ref>.
+
+==Related Work==
+
+The [https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki Ephemeral Anchors] proposal builds on top of this one to add more features.
+It changes the anchor script to be anyone can spend, allowing anybody to add fees and reducing the onchain footprint and fee costs.
+It also allows anchor outputs to have 0 value, eliminating the need to deduct anchor output amounts from the channel balance.
+
+The [https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393/7 Cluster Mempool] proposal makes deeper changes to mempool structure and policy rules, allowing for more incentive-compatible RBF rules for all transactions (not just ones with special topology restrictions like v3), among other things.
+
+Cluster Mempool provides a more holistic solution to some of the problems listed (such as adding an incentive compatibility requirement to RBF and safely enabling package RBF for more complex topologies). However, it does not help resolve RBF Pinning through Rule 3 and Rule 5. Also, since Cluster Mempool removes CPFP Carve Out<ref>https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393#the-cpfp-carveout-rule-can-no-longer-be-supported-12</ref>, a policy like v3 is a beneficial intermediate step for applications that rely on it.
+
+[https://bitcoinops.org/en/topics/package-relay Package Relay] includes changes in p2p protocol, transaction relay logic, and mempool policy to enable nodes to accept and relay packages of transactions. Much of this proposal's utility relies on the existence of package relay for 1 parent and 1 child (the package topology v3 supports).
+
+==Alternatives==
+
+Various alternatives have been proposed across multiple discussion threads
+<ref>Proposals and discussions dedicated to improving RBF:
+* [https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff "RBF Improvements"]
+* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html "Improving RBF Policy"]
+* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016998.html "[PROPOSAL] Emergency RBF (BIP 125)"]
+<br />Proposals and discussions dedicated to improving or creating new fee-bumping mechanisms:
+* [https://github.com/lightning/bolts/pull/1036 "Add option to sign commitments at various feerates"]
+* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html "A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent"]
+* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html "A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring"]
+* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html "Thoughts on fee bumping"]
+</ref>.
+Some alternatives work in conjunction with this proposal (see Related Work).
+
+A few popular ideas that were not incorporated into this work are summarized here.
+
+===Alternatives: add static incentive compatibility rule in RBF policy===
+
+Add incentive compatibility requirement to RBF policy using some existing score or static calculation
+<ref>Examples of such proposals and suggestions:
+* [https://github.com/bitcoin/bitcoin/pull/23121 "check ancestor feerate in RBF, remove BIP125 Rule2"]
+* [https://github.com/bitcoin/bitcoin/pull/26451 "Enforce incentive compatibility for all RBF replacements"]
+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019841.html
+* https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4081349#gistcomment-4081349
+</ref>.
+
+As the incentive compatibility "score" of a transaction must be dynamically calculated given the structure of mempools today, there is no satisfactory solution. A full calculation is too computationally expensive. Static values can overestimate or underestimate, leading to more pinning problems <ref>Four examples of static calculations and an example in which they are all inaccurate: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff#mining-score-of-a-mempool-transaction</ref>.
+The ability to calculate incentive compatibility scores efficiently is a primary feature and motivation for both v3 and cluster mempool.
+
+===Alternatives: replace by feerate===
+
+Instead of using Rule 3 and/or 4, allow replacements with a higher feerate.
+One variation of this proposal is to apply this rule in certain exceptional scenarios or when the replacement would confirm "soon"
+<ref>Examples of such proposals and suggestions:
+* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016998.html "[PROPOSAL] Emergency RBF (BIP 125)"]
+* [https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff#fees-in-next-block-and-feerate-for-the-rest-of-the-mempool]
+* [https://petertodd.org/2024/one-shot-replace-by-fee-rate "One-Shot Replace-by-Fee-Rate"]
+</ref>.
+
+The primary problem with these proposals is the potential for free relay and DDoS attacks.
+
+Removing Rule 3 and 4 in general would allow free relay
+<ref>Examples of free relay with the removal of Rule 3 and/or 4:
+<br/> Consider a rule where the fee can be decreased (remove Rule 3 and 4) but the feerate must double. In this scenario, a 100KvB transaction can be replaced by a 100vB transaction paying 200 sats. That's 200 sats to relay 100,200vB of transaction data, which is less than 0.002sat/vB. It becomes quite cheap to replace large portions of the mempool, decreasing both its average feerate and total absolute fees.
+
+<br/>Consider a rule where the fee can stay the same (keep Rule 3 but keep Rule 4) but the feerate must double. The attacker can start out with 100KvB transaction, paying 1sat/vB. A user can reduce its size over and over again, doubling the feerate each time until it gets too small, and end up paying 100Ksat for 100KvB(1 + 1/2 + 1/4 + ... log2(mintxsize)) -> approaches 200KvB. This means the attacker pays a
+rate of 0.5sat/vB to relay transactions, which is below our "free relay" threshold of 1/sat/vB.
+</ref>.
+
+Using a separate "Replace by Feerate" ruleset in special scenarios can also lead to free relay, as there may be conditions in which two sets of transactions can replace each other, each using a different ruleset.
+<ref>
+Consider a rule where a distinct set of rules ("Replace by Feerate") applies in the following scenario:
+* The replacement transaction(s) would be included in the next block template (another way of saying it would be in the "top 1 block of the mempool").
+* The to-be-replaced transaction(s) would not be included in the next block template.
+
+<br/>With the "Replace by Feerate" rules, the replacement transaction(s) only need to have a feerate that is some multiple <code>r</code> higher than the to-be-replaced transactions. In this case, consider <code>r=2</code>, i.e. the feerate must double.
+
+<br/>We can construct two sets of transactions, A and B, where A can replace B using the existing Replace by Fee rules, while B can replace A using the special "Replace by Feerate" rules.
+
+<br />Let's say the feerate of "next block" transactions is <code>fb</code>, while the mempool minimum ferate is <code>fm</code>. Let's say <code>fb</code> is at least twice as large as <code>fm</code>, which is typical.
+
+<br />There is a confirmed UTXO <code>Or</code>. The attacker first broadcasts a large transaction <code>P</code> with feerate <code>fm</code>, creating output <code>Op</code>.
+
+<br />Set A consists of a single transaction: <code>A1</code> (spends both <code>Or</code> and <code>Op</code>) has feerate <code>fb + 1</code>. <code>A1</code> is thus a child of P, but is not high fee enough to meaningfully CPFP its large parent.
+
+<br />Set B consists of two transactions: <code>B1</code> (spends <code>Or</code>) has feerate <code>fb</code> and <code>B2</code> (spends <code>Op</code>) has feerate <code>fm</code>. <code>B2</code> is thus a child of P, but is not high fee enough to meaningfully CPFP its large parent. The size of <code>B1</code> + <code>B2</code> should be the same as the size of <code>A1</code>.
+
+<br /><code>A1</code> can replace <code>B1</code> and <code>B2</code> using the normal Replace by Fee rules:
+* Assuming the size of <code>A1</code> is <code>B1</code> + <code>B2</code>, its total fee is <code>(B1_size + B2_size) * (fb + 1)</code> or <code>(B1_size * fb) + (B2_size * fb) + (B1_size) + (B2_size)</code> or <code>(B1_size * fb) + (B2_size * fb) + (A1_size)</code>.
+* <code>B1</code> and <code>B2</code> pay fees of <code>B1_size * fb</code> and <code>B2_size * fm</code>. So <code>A1</code> pays <code>A1_size</code> additional fees, meeting Rule 3 and 4.
+* <code>A1</code> also has a higher feerate than <code>B1</code> and <code>B2</code>, meeting Rule 6.
+* <code>A1</code> meets Rule 2: while <code>P</code> may seem like a "new" ancestor, it is not new for <code>B1</code>, one of the replacees.
+
+<br /><code>B1</code> replaces <code>A1</code> using the special Replace by Feerate rules:
+* <code>B1</code>'s incentive compatibility score is equal to <code>fb</code> ("next block").
+* <code>A1</code>'s incentive compatibility score is <code>fm</code> (not "next block").
+* <code>B1</code>'s feerate is <code>fb</code> which we established as at least double <code>fm</code>.
+<br /><code>B2</code> is broadcast separately after the replacement.
+
+<br />A and B being able to replace each other results in infinite relay using the same fees: an attacker could broadcast these two sets of transactions (with some minimal modifications to change their IDs) over and over again. In practice, <code>B1</code> would likely confirm soon due to its high feerate, but not before quite a few replacements. <code>P</code> (which is likely to stay in mempools for a long time due to its low feerate) can also be used to launch a number of these replacement cycles simultaneously.
+</ref>
+
+Another issue is the complexity of defining and implementing a "would confirm soon" or "is in the top N portion of the mempool." These proposals require an efficient way to assess the incentive compatibility score of a transaction and/or where it ranks amongst the other mempool transactions. This isn't feasible without something like cluster mempool (also see the "add static incentive compatibility rule in RBF policy" section above).
+
+<ref>Concerns
+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017020.html
+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017002.html
+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
+* https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4044451#gistcomment-4044451
+</ref>.
+
+===Alternatives: implement rate-limiting without fee rules===
+Since Rule 3 and 4 are for rate-limiting, replace them with a mempool-wide or per-peer rate limits on replacements by outpoint and/or bandwidth
+<ref>Examples of such proposals and suggestions:
+* https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4081349#gistcomment-4081349
+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019820.html
+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017024.html
+<br />Related proposal for changing the amount of bandwidth that replacement transactions use:
+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019820.html
+</ref>.
+
+There doesn't seem to be any fleshed-out proposal that works. For example, an outpoint-based rate limit could easily be bypassed by an attacker by exhausting the limit for an unconfirmed UTXO, then replacing the transaction that created that UTXO. A problem with any global rate limit is that, in the absence of reputation or node identities, the limit could be exhausted by an attacker, thus restricting replacements for honest users. There are also other concerns about implementation complexity, free relay issues, and other unresolved edge cases
+<ref>Concerns
+* https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4081559#gistcomment-4081559
+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019921.html
+* https://docs.google.com/document/d/1LpYF17HdbXPGHKSl3WYdxG4XTJBNJKSn-c2UJ2yphhE/edit?usp=sharing
+</ref>.
+
+Note that the v3 proposal does not conflict with this idea. It could still be implemented and deployed independently.
+
+==Acknowledgements==
+
+Thank you to everyone who contributed to this proposal (alphabetical order):
+
+* Matt Corallo
+* Suhas Daftuar
+* Antoine Poinsot
+* Antoine Riard
+* Gregory Sanders
+* Bastien Teinturier
+
+==References and Rationale==
+
+<references/>
+