<p>I do not think it’s useful to invent new monikers that nobody else uses to distinguish the different specifications and sets of rules we are talking about. How about these descriptions:</p>
<ul>
<li><strong>Bitcoin Core’s actual RBF behavior</strong><br />
is specified per the code of Bitcoin Core and has changed over the years. Notably, Bitcoin Core pull request <a href="https://github.com/bitcoin/bitcoin/pull/6871" rel="nofollow noreferrer">#6871</a> introduced in November 2015 nSequence-based opt-in full-RBF behavior.</li>
<li><strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki" rel="nofollow noreferrer">BIP 125</a></strong><br />
BIP 125 was an attempt in December 2015 to formally describe the RBF behavior implemented by Bitcoin Core. Even when published, the BIP had some subtle differences from the implemented behavior and therefore Bitcoin Core was never fully compliant with BIP 125.</li>
<li><strong>Bitcoin Core’s documentation of the implemented behavior</strong><br />
In December 2021, a description of the behavior implemented in Bitcoin Core was added to the repository’s <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy" rel="nofollow noreferrer">policy documentation</a> which highlights the differences between the implementation and BIP 125 and includes a change log that summarizes how the implemented behavior was adapted over the years.</li>
<li><strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki" rel="nofollow noreferrer">BIP 431</a> (TRUC transactions)</strong><br />
A related but distinct set of rules was specified in January 2024 with BIP 431: Topology Restrictions for Pinning. An implementation of BIP 431 was included in the Bitcoin Core v28.0 release.</li>
</ul>
<p>BIP 125 specifies a set of rules under which a transaction may replace a prior transaction that signaled replaceability. Bitcoin Core implements similar but distinct rules, and notably since Bitcoin Core v24.0.1, node operators may accept replacements even in the case the original transaction did not explicitly signal replaceability by activating the <code>mempoolfullrbf</code> startup option. This option will be active by default starting with Bitcoin Core v28.0 due to being broadly adopted by a super majority of the hashrate.</p>
<p>BIP 431 proposes that senders set a transaction’s version field to version 3 to request that node operators enforce topological restrictions on that transaction while it is unconfirmed. We refer to these transactinos as  &quot;topologically restricted until confirmed&quot; or TRUC transactions. These topological restrictions apply independently of BIP 125 and the mempool behavior of Bitcoin Core applied to all transactions, and are only applied to transactions that set version 3. BIP 431 neither supersedes BIP 125, nor changes the behavior of Bitcoin Core in regard to transactions that do not use version 3. As these topological restrictions prevent TRUC transactions from forming packages larger than two transactions, some <a href="https://github.com/bitcoin/bitcoin/pull/28970" rel="nofollow noreferrer">basic opportunistic package relay</a> and <a href="https://github.com/bitcoin/bitcoin/pull/28984" rel="nofollow noreferrer">package replacement</a> can happen for TRUC transactions with the features shipped in Bitcoin Core v28.</p>
<p>The overall Package Relay Project is tracked in <a href="https://github.com/bitcoin/bitcoin/pull/28970" rel="nofollow noreferrer">Bitcoin Core #28970</a>.</p>

CC BY-SA 4.0
2024-08-22T14:42:03.823Z
2024-08-22T15:05:48.103Z
2024-08-22T15:05:48.103Z
Murch
<p>This is a work in progress answer taken mostly from the notes of the <a href="https://bitcoincore.reviews/25038" rel="nofollow noreferrer">Bitcoin Core PR review club</a> on February 22nd 2023 on &quot;nVersion=3 and Package RBF&quot;. As always alternative answers are welcome.</p>
<blockquote>
<p>What is BIP 125? Which BIP 125 rules are still being enforced in default policy in Core today? Which aren't? Which BIP 125 rules have been replaced with alternative rules in Core today?</p>
</blockquote>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki" rel="nofollow noreferrer">BIP 125</a> outlined how a transaction could signal that it was replaceable by a replace-by-fee (RBF) transaction. It was later discovered that the signaling rules as described in BIP 125 <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html" rel="nofollow noreferrer">didn't match</a> what was implemented in Bitcoin Core. Hence although a versioning system for BIP 125/RBF rules hasn't currently been introduced I'll use a RBF rule versioning system in this answer to be clear on exactly what rule I'm referring to.</p>
<p>Although the original Bitcoin Core implementation predated BIP 125 I will call the BIP &quot;version 1&quot; and the original Bitcoin Core implementation &quot;version 2&quot; because later changes and future versions (&quot;version 3&quot; and later) were made from the Bitcoin Core implementation and not from the BIP. This versioning system I am introducing is distinct to the &quot;V3&quot; transaction proposal which would set the <code>nVersion</code> field in the transaction to <code>3</code>.</p>
<p>Issues with BIP 125: <a href="https://gist.github.com/instagibbs/b3095752d6289ab52166c04df55c1c19" rel="nofollow noreferrer">https://gist.github.com/instagibbs/b3095752d6289ab52166c04df55c1c19</a></p>
<p>Current RBF rules (BIP 125 v3) in Bitcoin Core: <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy</a></p>
<blockquote>
<p>What (and where) is the proposed replacement for BIP 125?</p>
</blockquote>
<p>I'm not sure this exists yet. We'll call this BIP 125 v4 to differentiate from what is currently implemented in Core (BIP 125 v3) today.</p>
<blockquote>
<p>What is V3 Policy? Is the proposed replacement for BIP 125 part of V3 Policy?</p>
</blockquote>
<p>Link: <a href="https://github.com/bitcoin-core-review-club/bitcoin/blob/7198dac47279967be1a5d97c5423df60ff3b7df5/doc/policy/version3_transactions.md" rel="nofollow noreferrer">https://github.com/bitcoin-core-review-club/bitcoin/blob/7198dac47279967be1a5d97c5423df60ff3b7df5/doc/policy/version3_transactions.md</a></p>
<blockquote>
<p>What is package RBF and is this part of V3 Policy or a separate proposal to V3 Policy? Is the intention that package RBF will (eventually) be enabled at the same time as V3 Policy or can they be enabled at different times.</p>
</blockquote>

CC BY-SA 4.0
2023-02-23T16:11:01.860Z
There is no versioning of BIP125. BIP125 describes a set of rules and it has not changed.
V3 refers to a completely separate set of policies to apply to transactions with nVersion set to 3.
glozow
CC BY-SA 4.0
2023-02-23T16:14:15.030Z
@glozow: There isn't. It does make it hard to follow without them. Whenever I see say "Rule 3" I have no idea whether it is referring to Rule 3 in BIP 125, Rule 3 as originally implemented in Core, today's Rule 3 in Core, a proposed future change to Rule 3 in Core etc. I get "V3" is not referring to BIP 125 version 3 (which as you say hasn't been versioned)
Michael Folkson
CC BY-SA 4.0
2023-02-22T15:47:02.923Z
2023-03-01T11:28:16.083Z
2023-03-01T11:28:16.083Z
Michael Folkson
<p>Whenever I try to review P2P and mempool (default) policy proposals I end up going round in circles around this maze of docs, mailing list posts and pull requests. Some of them are outdated, some present the latest state of proposal(s), sometimes two proposals are presented together, sometimes presented separately. Some docs I found really useful in the past I can't find anymore. Can you answer these questions and provide a link to the latest state of the proposal?</p>
<p>What is BIP 125? Which BIP 125 rules are still being enforced in default policy in Core today? Which aren't? Which BIP 125 rules have been replaced with alternative rules in Core today?</p>
<p>What (and where) is the proposed replacement for BIP 125?</p>
<p>What is V3 Policy? Is the proposed replacement for BIP 125 part of V3 Policy?</p>
<p>What is package RBF and is this part of V3 Policy or a separate proposal to V3 Policy? Is the intention that package RBF will (eventually) be enabled at the same time as V3 Policy or can they be enabled at different times?</p>
<p>I get the proposals are evolving over time (and so no criticism necessarily directed towards the authors) but this confusion makes it really hard for me to follow what is going on.</p>

<p2p><replace-by-fee><package-relay><pinning-attack>
What and where are the current status of the BIP 125 replacement, the V3 Policy proposal, package RBF etc?
Michael Folkson
# What and where are the current status of the BIP 125 replacement, the V3 Policy proposal, package RBF etc?

(Asked by: username_0 on 2023-02-22)

Whenever I try to review P2P and mempool (default) policy proposals I end up going round in circles around this maze of docs, mailing list posts and pull requests. Some of them are outdated, some present the latest state of proposal(s), sometimes two proposals are presented together, sometimes presented separately. Some docs I found really useful in the past I can't find anymore. Can you answer these questions and provide a link to the latest state of the proposal?

What is BIP 125? Which BIP 125 rules are still being enforced in default policy in Core today? Which aren't? Which BIP 125 rules have been replaced with alternative rules in Core today?

What (and where) is the proposed replacement for BIP 125?

What is V3 Policy? Is the proposed replacement for BIP 125 part of V3 Policy?

What is package RBF and is this part of V3 Policy or a separate proposal to V3 Policy? Is the intention that package RBF will (eventually) be enabled at the same time as V3 Policy or can they be enabled at different times?

I get the proposals are evolving over time (and so no criticism necessarily directed towards the authors) but this confusion makes it really hard for me to follow what is going on.

**Tags:** p2p, replace-by-fee, package-relay, pinning-attack


---

## 2 answers

### Answer by username_1 on 2024-08-22. Score: 1

I do not think it’s useful to invent new monikers that nobody else uses to distinguish the different specifications and sets of rules we are talking about. How about these descriptions:

* **Bitcoin Core’s actual RBF behavior**  
  is specified per the code of Bitcoin Core and has changed over the years. Notably, Bitcoin Core pull request [#6871](https://github.com/bitcoin/bitcoin/pull/6871) introduced in November 2015 nSequence-based opt-in full-RBF behavior.
* **[BIP 125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki)**  
  BIP 125 was an attempt in December 2015 to formally describe the RBF behavior implemented by Bitcoin Core. Even when published, the BIP had some subtle differences from the implemented behavior and therefore Bitcoin Core was never fully compliant with BIP 125.
* **Bitcoin Core’s documentation of the implemented behavior**  
  In December 2021, a description of the behavior implemented in Bitcoin Core was added to the repository’s [policy documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy) which highlights the differences between the implementation and BIP 125 and includes a change log that summarizes how the implemented behavior was adapted over the years.
* **[BIP 431](https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki) (TRUC transactions)**  
  A related but distinct set of rules was specified in January 2024 with BIP 431: Topology Restrictions for Pinning. An implementation of BIP 431 was included in the Bitcoin Core v28.0 release.

BIP 125 specifies a set of rules under which a transaction may replace a prior transaction that signaled replaceability. Bitcoin Core implements similar but distinct rules, and notably since Bitcoin Core v24.0.1, node operators may accept replacements even in the case the original transaction did not explicitly signal replaceability by activating the `mempoolfullrbf` startup option. This option will be active by default starting with Bitcoin Core v28.0 due to being broadly adopted by a super majority of the hashrate.

BIP 431 proposes that senders set a transaction’s version field to version 3 to request that node operators enforce topological restrictions on that transaction while it is unconfirmed. We refer to these transactinos as "topologically restricted until confirmed" or TRUC transactions. These topological restrictions apply independently of BIP 125 and the mempool behavior of Bitcoin Core applied to all transactions, and are only applied to transactions that set version 3. BIP 431 neither supersedes BIP 125, nor changes the behavior of Bitcoin Core in regard to transactions that do not use version 3. As these topological restrictions prevent TRUC transactions from forming packages larger than two transactions, some [basic opportunistic package relay](https://github.com/bitcoin/bitcoin/pull/28970) and [package replacement](https://github.com/bitcoin/bitcoin/pull/28984) can happen for TRUC transactions with the features shipped in Bitcoin Core v28.

The overall Package Relay Project is tracked in [Bitcoin Core #28970](https://github.com/bitcoin/bitcoin/pull/28970).


---

### Answer by username_0 on 2023-02-22. Score: -1

This is a work in progress answer taken mostly from the notes of the [Bitcoin Core PR review club](https://bitcoincore.reviews/25038) on February 22nd 2023 on "nVersion=3 and Package RBF". As always alternative answers are welcome.

> What is BIP 125? Which BIP 125 rules are still being enforced in default policy in Core today? Which aren't? Which BIP 125 rules have been replaced with alternative rules in Core today?

[BIP 125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) outlined how a transaction could signal that it was replaceable by a replace-by-fee (RBF) transaction. It was later discovered that the signaling rules as described in BIP 125 [didn't match](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html) what was implemented in Bitcoin Core. Hence although a versioning system for BIP 125/RBF rules hasn't currently been introduced I'll use a RBF rule versioning system in this answer to be clear on exactly what rule I'm referring to.

Although the original Bitcoin Core implementation predated BIP 125 I will call the BIP "version 1" and the original Bitcoin Core implementation "version 2" because later changes and future versions ("version 3" and later) were made from the Bitcoin Core implementation and not from the BIP. This versioning system I am introducing is distinct to the "V3" transaction proposal which would set the `nVersion` field in the transaction to `3`.

Issues with BIP 125: <https://gist.github.com/instagibbs/b3095752d6289ab52166c04df55c1c19>

Current RBF rules (BIP 125 v3) in Bitcoin Core: <https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy>

> What (and where) is the proposed replacement for BIP 125?

I'm not sure this exists yet. We'll call this BIP 125 v4 to differentiate from what is currently implemented in Core (BIP 125 v3) today.

> What is V3 Policy? Is the proposed replacement for BIP 125 part of V3 Policy?

Link: <https://github.com/bitcoin-core-review-club/bitcoin/blob/7198dac47279967be1a5d97c5423df60ff3b7df5/doc/policy/version3_transactions.md>

> What is package RBF and is this part of V3 Policy or a separate proposal to V3 Policy? Is the intention that package RBF will (eventually) be enabled at the same time as V3 Policy or can they be enabled at different times.

> **Comments:**
> **username_2**: There is no versioning of BIP125. BIP125 describes a set of rules and it has not changed. V3 refers to a completely separate set of policies to apply to transactions with nVersion set to 3.  
> **username_0**: @username_2: There isn't. It does make it hard to follow without them. Whenever I see say "Rule 3" I have no idea whether it is referring to Rule 3 in BIP 125, Rule 3 as originally implemented in Core, today's Rule 3 in Core, a proposed future change to Rule 3 in Core etc. I get "V3" is not referring to BIP 125 version 3 (which as you say hasn't been versioned)  

---

