Skip to content

[NO MERGE] optimize fee estimation test, re-include in regular list#564

Open
instagibbs wants to merge 1 commit intoElementsProject:masterfrom
instagibbs:reenable_fee_test
Open

[NO MERGE] optimize fee estimation test, re-include in regular list#564
instagibbs wants to merge 1 commit intoElementsProject:masterfrom
instagibbs:reenable_fee_test

Conversation

@instagibbs
Copy link
Contributor

@instagibbs instagibbs commented Apr 5, 2019

Turning off mempool consistency checks sped up this test by 30%.

@instagibbs
Copy link
Contributor Author

Actually seems to work reasonably. Test took under 500 seconds, and whole suite in about 44 minutes.

@instagibbs instagibbs changed the title [WIP] optimize fee estimation test, re-include in regular list optimize fee estimation test, re-include in regular list Apr 10, 2019
@instagibbs
Copy link
Contributor Author

It's passing consistently. Restarting one more time, @stevenroose could you ACK/merge if it passes again?

@instagibbs
Copy link
Contributor Author

interesting, the section where it's supposed to recover in a few seconds failed to.

Timed out at this section:

# Don't make a block, race condition when pegin-invalid block
        # is awaiting further validation, nodes reject subsequent blocks
        # even ones they create
        print("Now waiting for node to re-evaluate peg-in witness failed block... should take a few seconds")
        self.sync_all(self.node_groups)
        print("Completed!\n")

One mempool was missing a tx to the end of the test. Wonder what happened there... leaving this PR open then.

@instagibbs instagibbs changed the title optimize fee estimation test, re-include in regular list [NO MERGE] optimize fee estimation test, re-include in regular list Apr 11, 2019
tomt1664 pushed a commit to tomt1664/elements that referenced this pull request Mar 11, 2026
Contributes to ElementsProject#564 by providing an interface for mapLocalHost
through net -> node interface -> clientModel. Later this value can be
read by GUI to show the local addresses.
tomt1664 pushed a commit to tomt1664/elements that referenced this pull request Mar 11, 2026
Adds a new row to the Node Window (debugwindow.ui)
under the Network section which shows the LocalAddresses.

fixes ElementsProject#564
tomt1664 pushed a commit to tomt1664/elements that referenced this pull request Mar 11, 2026
189c987 Showing local addresses on the Node Window (Jadi)
a5d7aff net: Providing an interface for mapLocalHost (Jadi)

Pull request description:

  This change adds a new row to the Node Window (debugwindow.ui)
  under the Network section which shows the LocalAddresses.

  fixes ElementsProject#564

  <!--
  *** Please remove the following help text before submitting: ***

  Pull requests without a rationale and clear improvement may be closed
  immediately.

  GUI-related pull requests should be opened against
  https://github.com/bitcoin-core/gui
  first. See CONTRIBUTING.md
  -->

  <!--
  Please provide clear motivation for your patch and explain how it improves
  Bitcoin Core user experience or Bitcoin Core developer experience
  significantly:

  * Any test improvements or new tests that improve coverage are always welcome.
  * All other changes should have accompanying unit tests (see `src/test/`) or
    functional tests (see `test/`). Contributors should note which tests cover
    modified code. If no tests exist for a region of modified code, new tests
    should accompany the change.
  * Bug fixes are most welcome when they come with steps to reproduce or an
    explanation of the potential issue as well as reasoning for the way the bug
    was fixed.
  * Features are welcome, but might be rejected due to design or scope issues.
    If a feature is based on a lot of dependencies, contributors should first
    consider building the system outside of Bitcoin Core, if possible.
  * Refactoring changes are only accepted if they are required for a feature or
    bug fix or otherwise improve developer experience significantly. For example,
    most "code style" refactoring changes require a thorough explanation why they
    are useful, what downsides they have and why they *significantly* improve
    developer experience or avoid serious programming bugs. Note that code style
    is often a subjective matter. Unless they are explicitly mentioned to be
    preferred in the [developer notes](/doc/developer-notes.md), stylistic code
    changes are usually rejected.
  -->

  <!--
  Bitcoin Core has a thorough review process and even the most trivial change
  needs to pass a lot of eyes and requires non-zero or even substantial time
  effort to review. There is a huge lack of active reviewers on the project, so
  patches often sit for a long time.
  -->

ACKs for top commit:
  pablomartin4btc:
    re-ACK 189c987
  furszy:
    utACK 189c987

Tree-SHA512: 93f201bc6d21d81b27b87be050a447b841f01e3efb69b9eca2cc7af103023d7cd69eb5e16e2875855573ef51a5bf74a6ee6028636c1b6798cb4bb11567cb4996
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant