test: refactor: introduce generate_keypair helper with WIF support
#27733
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsNo conflicts as of last run. |
In functional tests it is a quite common scenario to generate fresh
elliptic curve keypairs, which is currently a bit cumbersome as it
involves multiple steps, e.g.:
privkey = ECKey()
privkey.generate()
privkey_wif = bytes_to_wif(privkey.get_bytes())
pubkey = privkey.get_pubkey().get_bytes()
Simplify this by providing a new `generate_keypair` helper function that
returns the private key either as `ECKey` object or as WIF-string
(depending on the boolean `wif` parameter) and the public key as
byte-string; these formats are what we mostly need (currently we don't
use `ECPubKey` objects from generated keypairs anywhere).
With this, most of the affected code blocks following the pattern above
can be replaced by one-liners, e.g.:
privkey, pubkey = generate_keypair(wif=True)
Note that after this commit, the only direct uses of `ECKey` remain in
situations where we want to set the private key explicitly, e.g. in
MiniWallet (test/functional/test_framework/wallet.py) or the test for
the signet miner script (test/functional/tool_signet_miner.py).
theStack
force-pushed
the
generate_wif_bytes_keypair
branch
from
25f19c0
to
1a572ce
Compare
|
Addressed review comment #27733 (comment) and rebased on master -- with the merge of #25634 there was another Changes since the initial version can be reviewed via |
stratospher
reviewed
Jun 20, 2023
There was a problem hiding this comment.
ACK 1a572ce. neat to have this since keypair generation is done in lots of places.
|
ACK 1a572ce There are 3 remaining uses of ECKey outside of this new utility function, each of which are deterministic uses. |
|
reACK 1a572ce |
maflcko
reviewed
Jun 21, 2023
| k = ECKey() | ||
| k.generate() | ||
| return bytes_to_wif(k.get_bytes(), k.is_compressed) | ||
| def generate_keypair(compressed=True, wif=False): |
There was a problem hiding this comment.
Nit to force named args:
def generate_keypair(*, compressed=True, wif=False):
sidhujag
pushed a commit
to syscoin/syscoin
that referenced
this pull request
Jun 21, 2023
joostjager
pushed a commit
to joostjager/bitcoin
that referenced
this pull request
Jun 26, 2023
…per with WIF support 1a572ce test: refactor: introduce `generate_keypair` helper with WIF support (Sebastian Falbesoner) Pull request description: In functional tests it is a quite common scenario to generate fresh elliptic curve keypairs, which is currently a bit cumbersome as it involves multiple steps, e.g.: privkey = ECKey() privkey.generate() privkey_wif = bytes_to_wif(privkey.get_bytes()) pubkey = privkey.get_pubkey().get_bytes() Simplify this by providing a new `generate_keypair` helper function that returns the private key either as `ECKey` object or as WIF-string (depending on the boolean `wif` parameter) and the public key as byte-string; these formats are what we mostly need (currently we don't use `ECPubKey` objects from generated keypairs anywhere). With this, most of the affected code blocks following the pattern above can be replaced by one-liners, e.g.: privkey, pubkey = generate_keypair(wif=True) Note that after this commit, the only direct uses of `ECKey` remain in situations where we want to set the private key explicitly, e.g. in MiniWallet (test/functional/test_framework/wallet.py) or the test for the signet miner script (test/functional/tool_signet_miner.py). ACKs for top commit: instagibbs: ACK bitcoin@1a572ce kevkevinpal: reACK [1a572ce](bitcoin@1a572ce) stratospher: ACK 1a572ce. neat to have this since keypair generation is done in lots of places. Tree-SHA512: ceb695ba7b34dc9f65357b55be03e67609e7e13a178083d405284eff4d8d3c5cea4fb0b6632658604a533f38ebfefc33e0c375995cc21ebc7843442ad764287b
luke-jr
pushed a commit
to bitcoinknots/bitcoin
that referenced
this pull request
Oct 20, 2023
In functional tests it is a quite common scenario to generate fresh
elliptic curve keypairs, which is currently a bit cumbersome as it
involves multiple steps, e.g.:
privkey = ECKey()
privkey.generate()
privkey_wif = bytes_to_wif(privkey.get_bytes())
pubkey = privkey.get_pubkey().get_bytes()
Simplify this by providing a new `generate_keypair` helper function that
returns the private key either as `ECKey` object or as WIF-string
(depending on the boolean `wif` parameter) and the public key as
byte-string; these formats are what we mostly need (currently we don't
use `ECPubKey` objects from generated keypairs anywhere).
With this, most of the affected code blocks following the pattern above
can be replaced by one-liners, e.g.:
privkey, pubkey = generate_keypair(wif=True)
Github-Pull: bitcoin#27733
Rebased-From: 1a572ce [partial]
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In functional tests it is a quite common scenario to generate fresh elliptic curve keypairs, which is currently a bit cumbersome as it involves multiple steps, e.g.:
Simplify this by providing a new
generate_keypairhelper function that returns the private key either asECKeyobject or as WIF-string (depending on the booleanwifparameter) and the public key as byte-string; these formats are what we mostly need (currently we don't useECPubKeyobjects from generated keypairs anywhere).With this, most of the affected code blocks following the pattern above can be replaced by one-liners, e.g.:
Note that after this commit, the only direct uses of
ECKeyremain in situations where we want to set the private key explicitly, e.g. in MiniWallet (test/functional/test_framework/wallet.py) or the test for the signet miner script (test/functional/tool_signet_miner.py).