Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: Use MiniWallet in mempool_limit.py #22543

Merged
merged 3 commits into from Sep 14, 2021

Conversation

ShubhamPalriwala
Copy link
Contributor

This is a PR proposed in #20078

This PR enables running another non-wallet functional test even when the wallet is disabled thanks to the MiniWallet, i.e. it can be run even when bitcoin-core is compiled with --disable-wallet.

It also includes changes in wallet.py in the form of a new method, create_large_transactions() for the MiniWallet to create large transactions.

Efforts for this feature started in #20874 but were not continued and that PR was closed hence I picked this up.

To test this PR locally, compile and build bitcoin-core without the wallet and run:

$ test/functional/mempool_limit.py

@amitiuttarwar
Copy link
Contributor

approach ACK :)

@practicalswift
Copy link
Contributor

Concept ACK

@DrahtBot
Copy link
Contributor

DrahtBot commented Jul 28, 2021

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

Conflicts

No conflicts as of last run.

@theStack
Copy link
Contributor

Concept ACK

@ShubhamPalriwala ShubhamPalriwala force-pushed the diswallet-mempool_limit branch 3 times, most recently from 78de7bf to 4beb43c Compare August 3, 2021 14:47
@Zero-1729
Copy link
Contributor

Concept ACK

1 similar comment
@Shubhankar-Gambhir
Copy link
Contributor

Concept ACK

Copy link
Contributor

@NikhilBartwal NikhilBartwal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept and Approach ACK and Tested dcd75d8

Checked that:

  • Running test/functional/mempool_limit.py after compiling bitcoin core from source with --disable-wallet leads to Test Skips: Test Skipped: wallet has not been compiled.
  • Running the same test with the same flag with the PR paches now successfully runs the tests: Tests successful

Just had a few comments to add :)

Copy link
Contributor

@hg333 hg333 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tACK dcd75d8

tested on Ubuntu 20.04
On Master Branch:

$ time ./test/functional/mempool_limit.py 
...
real	0m17.054s
user	0m3.117s
sys	0m0.515s

On PR Branch:

$ time ./test/functional/mempool_limit.py 
...

real	0m7.905s
user	0m2.777s
sys	0m0.139s

test/functional/mempool_limit.py Show resolved Hide resolved
Copy link

@Kirandevraj Kirandevraj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept and Approach ACK and Tested c6b17eb
Compiled Bitcoin core with this PR patch and --disable-wallet flag and ran the test/functional/mempool_limit.py test: Test successful
Compiled Bitcoin core without this PR patch with the same --disable-wallet flag and ran the test: Test Skipped

Copy link
Contributor

@DariusParvin DariusParvin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK bec7849
Tested it and looks good! A few suggestions

test/functional/mempool_limit.py Outdated Show resolved Hide resolved
test/functional/test_framework/wallet.py Outdated Show resolved Hide resolved
test/functional/mempool_limit.py Outdated Show resolved Hide resolved
Copy link
Member

@josibake josibake left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for taking the suggestion for send_large_transactions! one small pep8 fix suggested

test/functional/mempool_limit.py Outdated Show resolved Hide resolved
@josibake
Copy link
Member

josibake commented Sep 2, 2021

ACK e8a3ff3

nicely done, happy to see the send_large_transactions helper function being added to miniwallet!

Copy link
Contributor

@Zero-1729 Zero-1729 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re-ACK e8a3ff3

LGTM 💾

test/functional/mempool_limit.py Outdated Show resolved Hide resolved
test/functional/mempool_limit.py Outdated Show resolved Hide resolved
test/functional/test_framework/wallet.py Outdated Show resolved Hide resolved
test/functional/mempool_limit.py Outdated Show resolved Hide resolved
test/functional/mempool_limit.py Outdated Show resolved Hide resolved
@ShubhamPalriwala
Copy link
Contributor Author

PR ready for review

Thank you to everybody who has reviewed it. However, the recent suggestions made the PR better and more helpful hence the changes as suggested have been implemented.

Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

review ACK 22c7392 🍚

Show signature and timestamp

Signature:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

review ACK 22c73921c5c753c2e97fefbd207b163e610af15 🍚
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUiNiQwAlZ9W+JInYlneTbs9NDBJWdFX+6yy4GyhGTls+oxQZa+f4AM7uNK28ak1
oja9zQn9c/xTfOO3k2C3W6ly0M7aonKgW09++7AWtSGT3vKQmQN0ElvZdPJVH+gb
0aOxetJQrVHxBvwvFmiS2mq9WqmHLMPCOKZ9Rkj/36hMH5ItI/ylkBccqfq3RS/9
1XidxJWmtFVBai2nqmVrRfYIJenpplxDFMJXevMV9oq0iSsC1DL2boB3wBCtp0uY
OGlI1ghPWFO3kACX+oI+ruHIqxGuyA7lChhIs/D+dDckXeyk5rKwtaBPXS08qbuu
wYk71Co0wq2tlj3lI7LsRZwaQ1Zovhhdw2iwPe6Q1KPaRCO9wn7eCtHEenn7gS7v
8CEBAtqaOGL11JBq9IyIGnHfo5cMERUdyeuY0lb34RCsieMoDXlMT9OgBD9JXEhw
hdoJnrBwWZ5T39/gdmmsSJUs5MpF2nP+9Mk2YN5zI+kTRzCIwVPFo15FfOK+HO1z
aUF/Ov9m
=3RiU
-----END PGP SIGNATURE-----

Timestamp of file with hash 668a0177b4b7850b6d72a3a9f719e35848f7d38faaf8b37423b4d77b70903b93 -

test/functional/mempool_limit.py Outdated Show resolved Hide resolved
@maflcko
Copy link
Member

maflcko commented Sep 13, 2021

lmk if you want this merged or address the nits

@ShubhamPalriwala
Copy link
Contributor Author

@MarcoFalke the nits have been addressed! PTAL.
The PR is ready to be merged from my end :)

@maflcko
Copy link
Member

maflcko commented Sep 13, 2021

ack

Copy link
Contributor

@amitiuttarwar amitiuttarwar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the git commit breakup a bit confusing - I think the last commit 41fa226 should be merged into the first commit cdf1bf6, because it's cleaning up the code that was introduced in this PR. It makes more sense to just introduce it correctly in the first place- it simplifies review & git blame history in the future.

Also, I'd prefer if the git commit messages were more descriptive & adhered to the conventions of this codebase. For example, I've never seen the prefix feat:. I used the command git log -S "miniwallet" to see that most of the miniwallet refactors use the prefix test: or maybe refactor:. A more common prefix instead of replace: or fix: would probably be style:. In terms of descriptiveness, commit messages are the most useful when you explain why the change is being made. While this is fine to skip on self-evident changes (like fixing a typo or renaming to node), the first commit could describe the motivation. If you're interested in learning more, check out https://chris.beams.io/posts/git-commit/.

All that said, I think the code introduced looks reasonable, so review ACK 41fa226. If you decide to clean up the git history, I'm happy to reack- it should not produce a code diff.

ShubhamPalriwala and others added 3 commits September 14, 2021 00:52
Co-authored-by: ShubhamPalriwala <spalriwalau@gmail.com>
Co-authored-by: stackman27 <sishirg27@gmail.com>
Signed-off-by: ShubhamPalriwala <spalriwalau@gmail.com>
@ShubhamPalriwala
Copy link
Contributor Author

Thank you for the git suggestions @amitiuttarwar
Updated and force-pushed the commits for a more clear understanding of the changes.

The PR is once again up for review. Hopefully one last time

@amitiuttarwar
Copy link
Contributor

ACK 08634e8, only git changes since last push (and one new line).

Copy link
Contributor

@Zero-1729 Zero-1729 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 08634e8 🧉

@maflcko maflcko merged commit 2b26497 into bitcoin:master Sep 14, 2021
@maflcko
Copy link
Member

maflcko commented Sep 14, 2021

Thanks for taking the feedback. Looks good now.

@theStack
Copy link
Contributor

Note that the helper send_large_txs with its current interface is misleading, as the passed fee_rate is not respected. It is merely passed to MiniWallet's create_self_transfer, but this function can't look in the future and thus is unable to know that several outputs are appended to the transaction after, modifying its size and hence also decreasing it's feerate. I'd suggest to either pass an absolute fee that is simply deducted from tx.vout[0].nValue before the transaction is sent (simple solution), or keep the interface, but fix the fee calculation by deducting dependend on the tx's final vsize (a little more complex solution). In both cases, create_self_transfer needs to be called with a zero fee_rate first. Will take a look into that later.

@maflcko
Copy link
Member

maflcko commented Sep 14, 2021

@theStack See also #22543 (comment) , where I mentioned in-lining helps. I think we should pick the simplest/shortest code to achieve the goal of creating txs with different fee levels. The feerate doesn't need to be exact for the purposes of mempool eviction. The current code achieves its goal, but improvements are welcome if there are any.

@theStack
Copy link
Contributor

@MarcoFalke: Sure, but in this case the fee-rate is not just "not exact", but off by several orders of magnitute, considering that the tx's vsize changes from 96 to 67552 vbytes (>700x), and MiniWallet only calculates the fee based on the 96 vbytes. So the value passed to this function is neither really a fee-rate nor an absolute fee, but something weird in-between that has just been increased (by 10x) until the test passes. I tried to increase the clarity of the test in #22972.

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Sep 15, 2021
maflcko pushed a commit to bitcoin-core/gui that referenced this pull request Oct 29, 2021
…_limit.py

2600db6 test: fix misleading fee unit in mempool_limit.py (Sebastian Falbesoner)

Pull request description:

  The PR is a follow-up to #22543. The helper `send_large_txs` in its current interface has a fee_rate parameter, implying that it would create a transaction with exactly that rate. Unfortunately, this fee rate is only passed to MiniWallet's `create_self_transfer` method, which can't know that we append several tx outputs after, increasing the tx's vsize and decreasing it's fee rate accordingly.

  In our case, the fee rate is off by several orders of magnitude, as the tx's vsize changes changes from 96 to 67552 vbytes (>700x), i.e. the value passed to this function is neither really a fee rate nor an absolute fee, but something in-between, which is very confusing. It was suggested to simply in-line this helper as it's currently only used in this single test (bitcoin/bitcoin#22543 (comment), bitcoin/bitcoin#22543 (comment)), but I could imagine that this helper may also become useful for other tests and may be moved to a library (e.g. wallet.py) in the future.

  Clarify the interface by passing an absolute fee that is deducted in the end (and also verified, via testmempoolaccept) and also describe how we come up with the value passed. On master, the comment says that the fee rate needs to increased "massively"; this word is also removed because the fee rate only needs to be higher for the test to succeed.

ACKs for top commit:
  stratospher:
    ACK 2600db6.

Tree-SHA512: 0bfacc3fa87603970d86c1d0186e51511f6c20c64b0559e19e7e12a68647f79dcb4f436000dee718fd832ce6a68e3bbacacb29145e0287811f1cb03d2f316843
@bitcoin bitcoin locked and limited conversation to collaborators Oct 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet