test: test RBF rule 3 #25461

pull jamesob wants to merge 1 commits into bitcoin:master from jamesob:2022-06-test-rbf-rule3 changing 2 files +33 −0
  1. jamesob commented at 7:02 pm on June 23, 2022: member

    Somewhat surprisingly, RBF rule 3 (absolute fees of replacement transaction must meet or exceed original) is untested.

    In other words, applying the following patch:

     0diff --git a/src/policy/rbf.cpp b/src/policy/rbf.cpp
     1index e25f5c7c5b..e4f2d9d728 100644
     2--- a/src/policy/rbf.cpp
     3+++ b/src/policy/rbf.cpp
     4@@ -162,14 +162,6 @@ std::optional<std::string> PaysForRBF(CAmount original_fees,
     5                                       CFeeRate relay_fee,
     6                                       const uint256& txid)
     7 {
     8-    // BIP125 Rule [#3](/bitcoin-bitcoin/3/): The replacement fees must be greater than or equal to fees of the
     9-    // transactions it replaces, otherwise the bandwidth used by those conflicting transactions
    10-    // would not be paid for.
    11-    if (replacement_fees < original_fees) {
    12-        return strprintf("rejecting replacement %s, less fees than conflicting txs; %s < %s",
    13-                         txid.ToString(), FormatMoney(replacement_fees), FormatMoney(original_fees));
    14-    }
    15-
    16     // BIP125 Rule [#4](/bitcoin-bitcoin/4/): The new transaction must pay for its own bandwidth. Otherwise, we have a DoS
    17     // vector where attackers can cause a transaction to be replaced (and relayed) repeatedly by
    18     // increasing the fee by tiny amounts.
    

    then recompiling and running the full test suite causes no failures.

    This is sort of a moot point, because the check following the removed check (rule 4 following rule 3) implicitly requires the absolute fee of the replacement to exceed the original. So effectively, you can’t violate rule 3 even if its code is removed.

    But still, it seems like we should probably explicitly test for the enforcement of rule 3. This test creates a failure when the above patch is applied.

  2. in test/functional/feature_rbf.py:737 in f48305d5a8 outdated
    732+
    733+        bigtx = CTransaction()
    734+        bigtx.vin = [CTxIn(tx0_outpoint, nSequence=0)]
    735+        bigtx.vout = [CTxOut(int(0.9 * COIN), big_output)]
    736+        bigtx_hex = bigtx.serialize().hex()
    737+        bigtx_txid = self.nodes[0].sendrawtransaction(bigtx_hex, 0)
    


    brunoerg commented at 7:07 pm on June 23, 2022:
    0test/functional/feature_rbf.py:737:9: F841 local variable 'bigtx_txid' is assigned to but never used 
    1^---- failure generated from lint-python.py
    
    0        self.nodes[0].sendrawtransaction(bigtx_hex, 0)
    
  3. brunoerg commented at 7:14 pm on June 23, 2022: contributor
    Concept ACK
  4. DrahtBot added the label Tests on Jun 23, 2022
  5. test: test RBF rule 3
    Prior to this change, removing the RBF rule 3 code was not caught by a
    test failure. Add a testcase to ensure that rule 3 is enforced.
    6de5e66685
  6. jamesob force-pushed on Jun 23, 2022
  7. DrahtBot commented at 2:53 am on June 24, 2022: contributor

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #25522 (test: Remove -acceptnonstdtxn=1 from feature_rbf.py by MarcoFalke)
    • #25353 (Add a -mempoolfullrbf node setting by ariard)
    • #22867 (test: Extend test coverage of BIP125 and document confusing/inconsistent behavior by mjdietzx)

    If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

  8. theStack commented at 2:03 pm on June 24, 2022: contributor
    Concept ACK
  9. glozow commented at 9:56 am on June 27, 2022: member
    Rule 4 implies Rule 3, so isn’t this just testing the error string?
  10. jamesob commented at 2:18 pm on June 27, 2022: member

    Rule 4 implies Rule 3, so isn’t this just testing the error string?

    I think we should either remove the “dead” code and fold rule 3 into rule 4 or add this test. Having untested code in RBF policy code does not seem like a good state.

  11. shaavan commented at 2:45 pm on June 27, 2022: contributor

    I think we should either remove the “dead” code and fold rule 3 into rule 4 or add this test.

    I think it depends on what we value more:

    1. To maintain the completeness of the code by explicitly writing conditions for all the rules. Or,
    2. To keep the code clean, minimal, and free of redundancies.

    If there is no predetermined consensus on which option is better, then, in my opinion, I prefer the second option. And so, I favor removing the “dead” code.

  12. glozow commented at 4:26 pm on June 29, 2022: member

    I think we should either remove the “dead” code and fold rule 3 into rule 4 or add this test. Having untested code in RBF policy code does not seem like a good state.

    I wouldn’t call this code “dead” since it is executed, I interpret it as testing debug messages rather than adding coverage of policy code. I am in favor of folding Rule 3 and 4 together since one is encapsulated in the other. (edit: apologies for scope creep)

  13. jamesob commented at 1:07 pm on June 30, 2022: member

    I have never worked on a project before where adding a simple test that provides novel coverage has been conceptually nit-picked to this degree.

    An “error string” is part of the public interface of this software. We don’t know which users are relying on this particular error string. Its continued existence should be verified with a test if practical, which luckily in this case it is.

    If you want to change the public interface, in principle the right way to do that is with some kind of deprecation schedule. Until then we should not be in a state where we can remove a central chunk of policy code and not have any tests fail.

  14. MarcoFalke renamed this:
    test: test RBF rule #3
    test: test RBF rule 3
    on Jul 4, 2022
  15. MarcoFalke commented at 2:16 pm on July 7, 2022: member

    No opinion on what to do here. I think anything is fine if reviewers like it.

    The error string seems to be hit 4 times already in the tests (probably in non-rbf related ones): https://marcofalke.github.io/btc_cov/total.coverage/src/policy/rbf.cpp.gcov.html#169

  16. DrahtBot commented at 4:05 pm on July 7, 2022: contributor

    🐙 This pull request conflicts with the target branch and needs rebase.

    Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a “draft”.

  17. DrahtBot added the label Needs rebase on Jul 7, 2022
  18. Empact commented at 7:08 am on July 22, 2022: member

    I’m in favor of testing what we have, and removing what we don’t need. The former is generally easier than the latter.

    ACK https://github.com/bitcoin/bitcoin/pull/25461/commits/6de5e666855be3bd7aba0c9bbdb10f6ddb3a1df7

  19. MarcoFalke commented at 2:20 pm on July 29, 2022: member
    Are you still working on this? Is this still relevant after test/rbf_tests.cpp?
  20. jamesob commented at 2:31 pm on July 29, 2022: member
    I still think that testing the interface is important. Will rebase if it’s not too much trouble otherwise will close.
  21. jamesob closed this on Sep 7, 2022

  22. bitcoin locked this on Sep 7, 2023

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-22 03:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me