Skip to content

fix standalone private keys encryption and usage #1959

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

OBorce
Copy link
Contributor

@OBorce OBorce commented Aug 19, 2025

  • fix encryption of the standalone private keys when a new password is created or changed
  • fix watching/scanning for relevant public key destinations belonging to standalone keys (only public key has destinations used to work before)
  • fix wallet balance to show spendable UTXOs belonging to standalone private keys.

@@ -298,18 +298,19 @@ fn create_wallet(chain_config: Arc<ChainConfig>) -> DefaultWallet {
}

#[track_caller]
fn create_block<B, P>(
fn create_block_with_address_reward<B, P>(
Copy link
Contributor

Choose a reason for hiding this comment

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

  1. The name looks strange. create_block_with_reward_address or create_block_with_reward_destination would be better.

  2. It doesn't make sense to return an Address from this function. Or even constructing it, because the function only needs Destination.


// success after unlock
wallet.unlock_wallet(&password.unwrap()).unwrap();
if rng.gen::<bool>() {
Copy link
Contributor

Choose a reason for hiding this comment

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

In such cases it's better to add a parameter to the test instead of randomly deciding what to do (because the code paths are quite different)

Comment on lines 1293 to 1295
wallet
.add_standalone_private_key(DEFAULT_ACCOUNT_INDEX, standalone_sk, None)
.unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

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

For completeness, it's better to check both cases - i.e. both when the key is added before the wallet is encrypted and after that.
(via a test parameter or at least a random bool)

)
.unwrap();
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Another scenario worth checking is:

  1. encrypt the wallet.
  2. add a standalone private key.
  3. while the wallet is encrypted, encrypt it again with a different password.
  4. check that that the key works (i.e. it was re-encrypted with the new password).

Probably it's better to make it a separate test though.

@@ -5363,7 +5493,7 @@ fn test_add_standalone_private_key(#[case] seed: Seed) {

// Check amount is still zero
let coin_balance = get_coin_balance(&wallet);
assert_eq!(coin_balance, Amount::ZERO);
assert_eq!(coin_balance, block1_amount);
Copy link
Contributor

Choose a reason for hiding this comment

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

The comment "Check amount is still zero" is now wrong.

P.S. the later comment "but the transaction has been added to the wallet" will also have to be changed.

vec![],
block1_amount,
0,
Destination::PublicKey(standalone_pk),
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps we should try both PublicKey and PublicKeyHash here (via a test parameter or a random bool).

@@ -1847,7 +1842,7 @@ impl<K: AccountKeyChains> Account<K> {
Destination::PublicKeyHash(pkh) => {
self.key_chain.is_public_key_hash_mine_or_watched(*pkh)
}
Destination::PublicKey(pk) => self.key_chain.is_public_key_mine(pk),
Destination::PublicKey(pk) => self.key_chain.is_public_key_mine_or_watched(pk.clone()),
Copy link
Contributor

Choose a reason for hiding this comment

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

Btw, I guess there is no test that covers this fix. Can you add one?

#[rstest]
#[trace]
#[case(Seed::from_entropy())]
fn locked_wallet_standalone_keys(#[case] seed: Seed) {
Copy link
Contributor

Choose a reason for hiding this comment

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

  1. I'd say the emphasis here is on "standalone_keys" and not "locked_wallet".
  2. Do we still need test_add_standalone_private_key? It looks like it does only a subset of what this test does. (I guess the only thing this test doesn't do is check the result of wallet.get_transaction, but we could add the check).
  3. If it's still needed, let's put the two tests near each other.

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.

2 participants