Skip to main content
Bitcoin

Return to Question

added 179 characters in body
Source Link
pinhead
pinhead
  • 5.2k
  • 2
  • 24
  • 43

From Bip125:

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.

From Bip125:

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.

From Bip125:

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.

Source Link
pinhead
pinhead
  • 5.2k
  • 2
  • 24
  • 43

Is "inherited" replace-by-fee signaling implemented as described in BIP125?

From Bip125:

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.