Indicate RBF replaceability, also after transactions have been confirmed #27794

1. 
   torkelrogstad commented at 11:03 am on May 31, 2023: contributor

   Please describe the feature you’d like to see added.

   Wallet transactions retrieved with RPC should indicate RBF replaceability, also after they are confirmed.

   Is your feature related to a problem, if so please describe it.

   Currently, RBF replaceability is set to a hard ’no’ if the transaction has any confirmations:

   https://github.com/bitcoin/bitcoin/blob/30d6c7d8c0441956fac37252921c795569002d07/src/wallet/rpc/transactions.cpp#L46-L55

   This makes it hard to figure out if this transaction has the RBF flag set. To determine this currently, the user would need to parse the raw transaction data and iterate over the transaction inputs, and inspect their sequence number. This is not something I think it’s reasonable to expect people to do.

   Describe the solution you’d like

   I’d like the bip125-replaceable field to indicate the RBF flag of the transaction, also after it has received confirmations.

   Describe any alternatives you’ve considered

   No response

   Please leave any additional context

   No response

2. torkelrogstad added the label Feature on May 31, 2023
3. 
   maflcko commented at 11:16 am on May 31, 2023: member

   A confirmed transaction can not be in the mempool, so can not be replaced in the mempool, whether with bip125 or not.

   I don’t see a use case to run the bip125 signal logic on confirmed transactions, and it shouldn’t be hard to run it yourself if you just want to do it despite no use case?

4. 
   torkelrogstad commented at 11:33 am on May 31, 2023: contributor

   I have a use case for this:

   I’m developing a service that receives bitcoin, with a Bitcoin Core wallet as the underlying wallet. When a transaction comes in I check whether or not it is BIP125 replaceable. If it is not, I run it through certain actions when first seeing it in the mempool. Upon receiving a confirmed transaction I need to run the transaction through those actions, if that has not already happened when seeing it in the mempool (i.e. for confirmed transactions that was replaceable).

   It isn’t too hard to check the sequence numbers myself. However, it is way harder than looking at a bool field of a RPC response. Especially for developers who might not be familiar with the technicalities of bitcoin transactions or RBF.

5. 
   maflcko commented at 12:14 pm on May 31, 2023: member

   I didn’t get the use case. You can simply skip your action that checks the rbf status when the transaction is confirmed.
6. 
   torkelrogstad commented at 12:25 pm on May 31, 2023: contributor

   I have a set of actions S, that every transaction needs to go through.

   If a transaction T does not signal BIP125-replaceability, I want to run S when T is in the mempool. If T does signal BIP125-replaceability, I want to run S when T is confirmed.

   Currently it is not possible to find out (through the RPC interface, at least) whether or not T signals BIP125-replaceability once it is confirmed.

7. 
   sipa commented at 12:31 pm on May 31, 2023: member

   The bip125-replaceable field does not indicate whether the transaction itself signals replaceability, but whether replaceability rules currently apply to it. This is a function of both the transaction itself, and any unconfirmed ancestors it may have. As a result, it’s expected to change over time.

   And for confirmed transactions, the answer to the question “do replaceability rules currently apply to it?” is trivially no.

8. maflcko added the label Questions and Help on May 31, 2023
9. maflcko removed the label Feature on May 31, 2023
10. 
    torkelrogstad commented at 2:23 pm on May 31, 2023: contributor

    Ok, thanks for the input. IMO what I’ve laid out here is something consumers of this API would care about. The Core API in general is very hard to work with, this being one example.
11. torkelrogstad closed this on May 31, 2023

    ---

12. 
    sipa commented at 2:25 pm on May 31, 2023: member

    @torkelrogstad I’m still confused about what you’re trying to do. The only sensible answer to the question whether a confirmed transaction is replaceable is no. Whatever purpose you have for caring about that, by the time a transaction confirms, it shouldn’t matter anymore to anything.
13. 
    sipa commented at 2:38 pm on May 31, 2023: member

    @torkelrogstad Oh, I think I understand now, re-reading your earlier comments.

    Having bip125-replaceable return true for confirmed signalling transactions is not a solution to your issue, because it can already change over time.

    Imagine a transaction T1 (which does signal) and a descendant transaction T2 (which does not signal), both unconfirmed. bip125-replaceable will be true for both, because the BIP125 rules say both are replaceable. Once T1 confirms, however, T2’s bip125-replaceable will become false. Even if bip125-replaceable is changed to return true for transactions that signal post confirmation, it won’t be true for T2, because it does not signal.

    It appears to me that what you want to do is run S whenever a transaction confirms, unless you’ve run S for that transaction already (regardless of its bip125 status at the time of confirmation).

14. bitcoin locked this on May 30, 2024

Contributors
torkelrogstad maflcko sipa

Labels
Questions and Help