1

The main objective is confidentiality, not allowing others to know how much one holds in their balance. by enabling a user to receive tokens in their balance with each transaction using a unique public address derived from the same private key.

  1. Can someone that knows the user's public key and one of their public addresses know what is the total balance of the user?

  2. Can the main private key be used to sign transactions from a sub wallet? In other words, to move tokens from a sub-wallet, can it be done using the private key from the main wallet, or does it need to be the sub-wallet's private key? Some code to exemplify how would be tremendously helpful =)

  3. Is it correct to say that the only way to generate multiple public addresses is through the path used to derive the sub wallets from the master seed? I'm doing like in the TypScript code below:

import { getMnemonic, language, toSeed } from "bip39-ts";
import { hdkey } from 'ethereumjs-wallet';
import Wallet from 'ethereumjs-wallet';

// the quantity of words in the mnemonic of the wallet created for users,
// can be 12 | 15 | 18 | 21 | 24
const mnemonicLength = 24

// generate the user's mnemonic
const mnemonic = getMnemonic(language['english' as keyof typeof language], mnemonicLength);
console.log('mnemonic', mnemonic)

// derive the seed phrase from the mnemonic
const seed: Buffer = toSeed(mnemonic);

// create an HD Wallet
const hdWallet = hdkey.fromMasterSeed(seed)

// get the wallet's extended private key
const xprv = hdWallet.privateExtendedKey()
console.log('xprv', xprv)

// generate the main wallet:
const walletFromExtendedPrivateKey = Wallet.fromExtendedPrivateKey(xprv.toString())
const privateKey = walletFromExtendedPrivateKey.getPrivateKeyString()
const publicKey = walletFromExtendedPrivateKey.getPublicKeyString().slice(2)
const addreess = walletFromExtendedPrivateKey.getAddressString();
console.log('main privateKey', privateKey)
console.log('main publicKey', publicKey)
console.log('main addreess', addreess)


// generate two sub wallets:
const subWallet0 = walletFromExtendedPrivateKey.derivePath("m/44'/60'/0'/0").getWallet();
const subWallet0PrivateKey = subWallet0.getPrivateKeyString()
const subWallet0PublicKey = subWallet0.getPublicKeyString().slice(2)
const subWallet0Address = subWallet0.getAddressString()
console.log('subWallet0PrivateKey', subWallet0PrivateKey)
console.log('subWallet0PublicKey', subWallet0PublicKey)
console.log('subWallet0Address', subWallet0Address)

const subWallet1 = walletFromExtendedPrivateKey.derivePath("m/44'/60'/0'/1").getWallet();
const subWallet1PrivateKey = subWallet1.getPrivateKeyString()
const subWallet1PublicKey = subWallet1.getPublicKeyString().slice(2)
const subWallet1Address = subWallet1.getAddressString()
console.log('subWallet1PrivateKey', subWallet1PrivateKey)
console.log('subWallet1PublicKey', subWallet1PublicKey)
console.log('subWallet1Address', subWallet1Address)

2 Answers 2

1

Maybe this tool can help to understand the wallet logic. And if it only has a private key, it cannot see other balances. but can see every balance if it has main words.

1
  • Thanks. It's a nice tool I wish I found it before I manually implemented the same thing to run my tests =) Still, it doesn't contain the answers I'm looking for. Commented Jan 6, 2023 at 23:14
0

After doing lots of digging I have the answers to my own questions:

  1. No. However, extended keys correspond to an entire (sub)tree of keys.

    Therefore, knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys.

    It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.

  2. No, but the main private key can be used to derive the sub-private key needed to sign a transaction. In other words, it needs to be the sub-wallet's private key.

  3. Yes in practice, no in theory: There are also hardened-keys or paths for other chains, but they are all variations of the same logic that uses a path to derive the sub-wallets.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.