<p>The answer to this question is: no, inherited signaling is not currently implemented in Bitcoin Core as described in BIP 125.</p>
<p>In May 2021, Antoine Riard discovered the missing implementation could be exploited in the context of the Lightning Network &quot;pinning attacks against second-stage HTLCs&quot; as well as other contexts:</p>
<p><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html</a></p>

CC BY-SA 4.0
2021-05-11T15:26:46.970Z
2021-05-11T15:26:46.970Z
pinhead
<p>From <a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki" rel="noreferrer">Bip125</a>:</p>

<blockquote>
  <p>Explicit signaling: A transaction is considered to have opted in to
  allowing replacement of itself if any of its inputs have an nSequence
  number less than (0xffffffff - 1).</p>
  
  <p>Inherited signaling: Transactions
  that don't explicitly signal replaceability are replaceable under this
  policy for as long as any one of their ancestors signals
  replaceability and remains unconfirmed.</p>
</blockquote>

<p>However, it looks to me like only "explicit" signaling is tested. See this part of the BIP125 pull request that was merged into Bitcoin Core:</p>

<p><a href="https://github.com/bitcoin/bitcoin/pull/6871/files#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR841" rel="noreferrer">https://github.com/bitcoin/bitcoin/pull/6871/files#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR841</a></p>

<p>It's very clear that incoming TXs are checked for conflicts (double spends) and if the conflicting TX does not explicitly signal RBF with its input sequence, then the new TX is rejected.</p>

<p>If implicit signaling were implemented, I would expect to see a recursive check for the conflicting TX's mempool ancestors, or check some kind of flag stored with the TX metadata.</p>

<p>OR, is the text of the BIP just describing what happens to descendants of replaced transactions, in that they are evicted when their explicitly-signaling ancestor is replaced.</p>

<mempool><replace-by-fee>
Is "inherited" replace-by-fee signaling implemented as described in BIP125?
pinhead
# Is "inherited" replace-by-fee signaling implemented as described in BIP125?

(Asked by: username_0 on 2019-07-03)

From [Bip125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki):

> Explicit signaling: A transaction is considered to have opted in to
> allowing replacement of itself if any of its inputs have an nSequence
> number less than (0xffffffff - 1).
>
> Inherited signaling: Transactions
> that don't explicitly signal replaceability are replaceable under this
> policy for as long as any one of their ancestors signals
> replaceability and remains unconfirmed.

However, it looks to me like only "explicit" signaling is tested. See this part of the BIP125 pull request that was merged into Bitcoin Core:

<https://github.com/bitcoin/bitcoin/pull/6871/files#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR841>

It's very clear that incoming TXs are checked for conflicts (double spends) and if the conflicting TX does not explicitly signal RBF with its input sequence, then the new TX is rejected.

If implicit signaling were implemented, I would expect to see a recursive check for the conflicting TX's mempool ancestors, or check some kind of flag stored with the TX metadata.

OR, is the text of the BIP just describing what happens to descendants of replaced transactions, in that they are evicted when their explicitly-signaling ancestor is replaced.

**Tags:** mempool, replace-by-fee


---

## 1 answers

### Answer by username_0 on 2021-05-11. Score: 4 | Accepted answer

The answer to this question is: no, inherited signaling is not currently implemented in Bitcoin Core as described in BIP 125.

In May 2021, Antoine Riard discovered the missing implementation could be exploited in the context of the Lightning Network "pinning attacks against second-stage HTLCs" as well as other contexts:

<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html>


---

