mempool: Add the bypass_feerate_accuracy option to testmempoolaccept #25532

pull w0xlt wants to merge 16 commits into bitcoin:master from w0xlt:add_bypass_feerate_accuracy changing 21 files +277 −135
  1. w0xlt commented at 4:17 am on July 3, 2022: contributor

    This PR adds the the bypass_feerate_accuracy option to testmempoolaccept RPC, which allows skipping the minimum mempool fee rate validation.

    This enables testing of HTLC-timeout transactions signed with 0-feerate (with BOLT9 option_anchors_zero_fee_htlc_tx).

    For more context, check #25434#pullrequestreview-1020896809.

    Since this PR is built on top of #25577 and #25434, only the last 4 commits are new here.

  2. mempool: change `maxfeerate` to be a members of an `options` argument
    `maxfeerate` becomes a member of an "options" object rather than
    a positional argument.
    
    The idea is that any new parameters in the future will also go into
    options.
    199b3148c0
  3. mempool: make `test_accept` parameter explicit 563dd147df
  4. DrahtBot added the label Mempool on Jul 3, 2022
  5. w0xlt force-pushed on Jul 3, 2022
  6. DrahtBot commented at 3:40 pm on July 3, 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:

    • #25577 (mempool, refactor: add MemPoolBypass by w0xlt)
    • #25487 ([kernel 3b/n] Decouple {Dump,Load}Mempool from ArgsManager by dongcarl)
    • #24007 ([mempool] allow tx replacement by smaller witness by LarryRuane)
    • #23897 (refactor: Move calculation logic out from CheckSequenceLocksAtTip() by hebasto)

    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.

  7. luke-jr commented at 1:38 am on July 6, 2022: member

    Approach NACK.

    Adding “bypass_” after bypass option is just a clunky way of rewriting #7533 / #20753.

    For #25434 there might be a reason to handle it specially as a specific mock time/height, but that doesn’t apply here.

  8. glozow commented at 3:43 pm on July 6, 2022: member
    Could you (or perhaps @ariard, seeing the suggestion at #25434#pullrequestreview-1020896809) provide a use case for bypassing the minimum feerate checks?
  9. ariard commented at 1:52 am on July 8, 2022: member

    Let’s say your a LN node receiving a counterparty’s signature for a HTLC-timeout (BOLT2’s commitment_signed). In the optimistic case, this transaction is never going to be broadcast as LN channels don’t have a bounded lifetime. This HTLC-timeout is signed with 0-feerate (with option_anchors_zero_fee_htlc_tx) and should be aggregated with a fee-bumping input thanks to SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. As the LN node, you would like to know if this transaction respects all the non-final and non-fee checks to broadcast it at anytime in the future, thus avoiding to accept a non-sane input from your counterparty. @luke-jr are you raising that #7533 should be opened again as a technical approach is more straighforward ? If so I invite you to do so and let contributors evaluate which approach is the better. Or could you qualify more your concerns e.g the maintenance cost or API misusage ?

    If you’re raising the concern that Lightning shouldn’t make safety-critical assumptions on transaction-relay policy, I’ll let the burden on you to propose the design of a second-layer to scale bitcoin payments as much decentralized and privacy-preserving (once we have fix all the issues).

  10. luke-jr commented at 2:02 am on July 8, 2022: member

    @luke-jr are you raising that #7533 should be opened again as a technical approach is more straighforward ? If so I invite you to do so and let contributors evaluate which approach is the better. Or could you qualify more your concerns e.g the maintenance cost or API misusage ? @MarcoFalke has already reopened it as #20753.

    If you’re raising the concern that Lightning shouldn’t make safety-critical assumptions on transaction-relay policy, I’ll let the burden on you to propose the design of a second-layer to scale bitcoin payments as much decentralized and privacy-preserving (once we have fix all the issues).

    It shouldn’t, but that’s beside the point I am making here. There’s nothing inherent in the original Lightning design that necessarily makes such assumptions…

  11. jonatack commented at 10:50 am on July 9, 2022: contributor
    @w0xlt in the PR description, for reviewers I would suggest (a) mentioning that only the last 3 commits are new here, and (b) adding a “why” motivation in the PR description, because if the why doesn’t make sense then the what probably doesn’t matter.
  12. validation: Add `MemPoolBypass` for bypassing mempool checks 9e8703ca5f
  13. mempool: add `MemPoolBypass` parameter to `ProcessNewPackage` 14eff472b3
  14. mempool: add `MemPoolBypass` parameter to `AcceptToMemoryPool` 420a3c4dc0
  15. mempool: add `MemPoolBypass` parameter to `ProcessTransaction` 17db819b72
  16. mempool: add `MemPoolBypass` parameter to `ATMPArgs` 26ee1a47e4
  17. validation: add `m_bypass_{relative,absolute}_timelock` 12ac626430
  18. validation: add option to bypass contextual timelock checks
    This is for test_accepts only, and not allowed in an actual submission
    to mempool - see assert statements.
    
    Provide an option to bypass BIP68 nSequence and nLockTime checks. This
    means clients can use testmempoolaccept to check whether L2 transaction
    chains (which typically have timelock conditions) are valid without
    submitting them. Note that BIP112 and BIP65 are still checked since they
    are script (non-contextual) checks. This does not invalidate any
    signature or script caching.
    
    Co-authored-by: glozow <gloriajzhao@gmail.com>
    b70a926081
  19. rpc: add optional bypass_timelocks for testmempoolaccept
    Co-authored-by: glozow <gloriajzhao@gmail.com>
    afc299806c
  20. test: check if `bypass_{absolute,relative}_timelock` works
    Test the bypass_timelock options in testmempoolaccept. This lets us
    bypass BIP68 relative locktime checks (in nSequence) and absolute
    locktime checks (in nLocktime).
    
    Co-authored-by: glozow <gloriajzhao@gmail.com>
    7ec6416310
  21. test: check if bypass_timelocks do not affect scripts
    OP_CSV and OP_CLTV script checks are still done,
    so setting bypass_timelocks=True doesn't mean that
    bad scripts pass.
    
    Co-authored-by: glozow <gloriajzhao@gmail.com>
    a006b8fd5a
  22. ariard commented at 0:59 am on July 14, 2022: member

    @MarcoFalke has already reopened it as #20753.

    AFAICT #20753 only allows to bypass IsStandardTx / AreInputsStandard / IsWitnessStandard, not the feerate checks object of this PR>. Further, I think an API where the check is explicit rather than relying on error strings is more robust.

    It shouldn’t, but that’s beside the point I am making here. There’s nothing inherent in the original Lightning design that necessarily makes such assumptions…

    And on that point, I really think the original Lightning design should have underscore more that failure to propagate a time-sensitive transaction should be considered as a break of the security model. Of course, if you’re thinking about an ideal world where every LN node is a miner that wouldn’t be an issue. That is not the real world. Or if you’re saying that a LN node shouldn’t make expectations about confirming a transaction before a timelock expiration, I believe that’s the foundation of the payment channel design you’re questioning.

  23. validation: Add `bypass_feerate_accuracy` to `MempoolTestCriteria` 20d049dd2e
  24. validation: Add `bypass_feerate_accuracy` validation logic 4bf7da5895
  25. rpc: add `bypass_feerate_accuracy` option to `testmempoolaccept` RPC 9ec3f3b666
  26. test: add functional tests for `bypass_feerate_accuracy` option 7368c07824
  27. w0xlt force-pushed on Jul 15, 2022
  28. w0xlt commented at 7:32 pm on July 15, 2022: contributor
    Rebased on top of https://github.com/bitcoin/bitcoin/pull/25434/commits/a006b8fd5a16c5283c25c4b8d93d96d485896816. @jonatack I added the suggested information in the PR description.
  29. luke-jr commented at 7:34 pm on July 15, 2022: member

    Further, I think an API where the check is explicit rather than relying on error strings is more robust.

    Using a different JSON string for no reason is not an improvement.

  30. DrahtBot commented at 3:52 pm on July 18, 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”.

  31. DrahtBot added the label Needs rebase on Jul 18, 2022
  32. glozow commented at 10:28 am on August 1, 2022: member

    This HTLC-timeout is signed with 0-feerate (with option_anchors_zero_fee_htlc_tx) and should be aggregated with a fee-bumping input thanks to SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. As the LN node, you would like to know if this transaction respects all the non-final and non-fee checks to broadcast it at anytime in the future

    Seems like there isn’t a reason to disable the feerate checks altogether. Rather, the better approach is to allow CPFP in the package submitted for testing, and the fee-bump should be included.

  33. glozow commented at 2:53 pm on October 3, 2022: member
    Closing for now as this builds on #25434 which still needs conceptual review. Can reopen when this is no longer blocked.
  34. glozow closed this on Oct 3, 2022

  35. bitcoin locked this on Oct 3, 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-11-21 15:12 UTC

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