diff --git a/bip-v3.mediawiki b/bip-v3.mediawiki
new file mode 100644
index 0000000000..52fcce3234
--- /dev/null
+++ b/bip-v3.mediawiki
@@ -0,0 +1,250 @@
+<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/28984 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.
+</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 transations 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 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]
+</ref>.
+
+A general removal of Rule 3 and 4 is not feasible as it opens the door to DoS attacks. It seems unclear how to design and implement a useful and safe threshold at which the rules can be bypassed (the notion of confirming "soon" is messy and may be too complex to implement), if such a threshold exists at all
+<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>.
+As such, the v3 proposal just aims to help users avoid such scenarios as much as possible.
+
+===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 transations use:
+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019820.html
+</ref>.
+
+There doesn't seem to be a fleshed-out proposal that examines all edge cases. There are 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
+</ref>.
+Note that the v3 proposal does not conflict with this idea at all.
+
+==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/>
+