Is there some relation between xPub and multiple accounts (addresses?)

[HockeyDevil07]

Continuing the discussion from [Coins / Wallets Disappeared on New App Install]:

I’m rerencing my other topic it helps anyone (myself for sure) follow my train of thoughts and questions here. My previous thread was my first time hearing about xpubs. I am trying to put this into context of what I have done so far and what else I understand.

In the process of trying to set myself up to receive XDC and mange it through my Trezor wallet, I read this page (https ://trezor .io/coins/detail/xdce-crowd-sale), which led me to creating a wallet here (https ://wallet .xinfin.network/#/). I attempted to set up with an account using the Trezor hardware, but it failed to connect because they are using Trezor Connect V6.

So I created a wallet there instead using the mnemonic phrase. When I was set up I was presented with a screen that said “Address to Interact With” and a list of addresses.

I’ve never seen anything like that before. Up until now I’ve been under the impression a wallet and an address were the same, so please bear with me.

I was reading other topics in this forum and came to the conclusion that I could still use my Trezor to manage the XDC if I created an account on Metamask with the Trezor wallet. I followed these instructions (https ://trezor .io/learn/a/metamask-and-trezor) and again, saw the same thing with multiple accounts listed. I didn’t know what this meant because I’ve only ever seen one in the Trezor Suite.

This answer was in my previous topic:

@matejcik

For purposes of, e.g., inheritance, you should keep separate track of which coins you own, ideally also with addresses or xpubs so that it is easy to figure out whether the seed / passphrase is correct.

Looked up what xPubs were; this rang a bell since as a web developer I often work with SSL certificates. I’ve set up a PKI for securing my home network, and am familiar with the Root CA - Intermediate Certificate - Leaf Certificate relationship. It sounds to me like xPubs are very similar to intermediate certificates. The intermediate certificates can sign the final used certs on websites, and if someone trusts the Root CA then the certificate is accepted.

Is this analogy proper? Is an extended public key like an intermediate certificate, able to create child public keys which are a 1:1 association with an address? So, when securing my home network, I create the Root Private / Public Key pair to create the CA, then an intermediate certificate, then individual SSL certificates for websites from the intermediate one. And, my Trezor hardware wallet has created a “root” Private / Public Key pair, then an xPub, which creates more public keys associated with individual addresses?

[HockeyDevil07]

And to follow up, how is this all managed by the Trezor? I only have three active coins right now, BTC, ETH and XRP. I have found the xPub for BTC. I don’t see anything equivalent for ETH or XRP though. From my reading I understand it’s a Bitcoin standard, so it would make sense if it only applies to BTC. I have only received one BTC transaction, one ETH, but several XRP. The XRP address has always been the same in my Trezor Suite. But, when connecting my Trezor wallet into Metamask, I did see multiple ETH accounts to choose from there and I’m not sure if that’s related to this (or how it’s otherwise relted).

@matejcik

In rare cases, you might also need to manually add another account for the coin: if Suite doesn’t find funds in the first one, it will not scan the next one. Typically it should not be possible to start using the second account if the first one is unused, but it can sometimes happen.

I wasn’t aware ofthat I could create more accounts until readomg through the forum and Trezor blog posts then referencing the suite. But, are these already created for me, but I am just not ‘activating’ them or ‘using’ them until I use the feature to add an account in the suite? When when signing up on Metamask I saw several accounts listed to choose from (as the example in the documentation), but definitely only have one set up in the suite.

Sorry if this is very scatterbrained. This is the best I’ve been able to organize my thoughts so far so any help is appreciated haha.

[matejcik]

@HockeyDevil07

It sounds to me like xPubs are very similar to intermediate certificates. The intermediate certificates can sign the final used certs on websites, and if someone trusts the Root CA then the certificate is accepted.

Kind of, in a very narrow way. The big difference between xpubs (and generally the BIP-32 HD wallets) and certificates is that certificates exist independent from one another. When you need a new key, you don’t go to the CA to give it to you. You generate it at home and ask the CA to sign it. The private part is not known to the CA.

Whereas in the BIP-32 hierarchy, a child key is directly derived from the parent: your “CA” analog fully implies all the “certificates” it can ever give you.

You start at the top with a “master secret” (which is your seed, put through some HMAC-SHA512 rounds) and generate one “extended key” from it. (that’s where the “X” in xpub comes from). This is a cryptographic private key on some curve, which you could use to derive a public key and sign things, if you wanted… but you don’t want that. What you want is to derive a bunch of child extended keys, and then children of those, a couple times.

Every extended key has a tree of child keys underneath it. So you can pluck it at any point of the hierarchy and get the whole subtree.

So it’s not that xpub confers “trust” as an intermediate CA would – instead, xpub is actually all the data that you need to calculate all the addresses at home.

(There’s a nifty mathematical trick that allows you to derive an “extended public key” from the “extended private key”, and the extended public key can generate just the public part of all the child keys, while you still need the extended private key to generate the private child keys. But if you’re interested in that, go read the BIP-32 spec.)

This is also where derivation paths come from: a derivation path specifies what derivation steps to take if you want to arrive at a particular point.
The most surefire backup is seed + derivation paths + generated addresses or xpubs. Right now, derivation paths for particular coins or account types are just conventions, sometimes different wallet apps differ in what derivation paths they use. So if a couple years down the line everyone switches to a different derivation path standard, you still know how to find your keys.
(derivation path is also part of a bitcoin descriptor, exactly for this reason)

See if you can answer your own questions from the second post, armed with this new information

[HockeyDevil07]

Thank you for the explanation. Your writing encouraged me to dive back into my CA and PKI setups and review everything I had going on there. I think I understand the difference you’re explaining. The CA as central trust authority that makes sense for TLS stuff. But, in the decentralized world we essentially are building these keys ourselves, signing them ourselves, etc. So although the analogy of the chain / hierarchy between keys is shared between the two, the parties and purpose are ultimately very dissimilar.

@matejcik

This is also where derivation paths come from: a derivation path specifies what derivation steps to take if you want to arrive at a particular point.
The most surefire backup is seed + derivation paths + generated addresses or xpubs.

Okay, derivation paths was something I had an upcoming question for but through looking up that I went down a rabbit hole that explained a lot. I started reading more on the Trezor blog and through other searching found this page (https ://learnmeabitcoin .com/technical/derivation-paths) which I ended up reading a series of pages from regarding hierarchical deterministic wallets.

@matejcik

See if you can answer your own questions from the second post, armed with this new information

@HockeyDevil07

But, are these already created for me, but I am just not ‘activating’ them or ‘using’ them until I use the feature to add an account in the suite?

If I’m understanding correctly, Trezor is a hierarchical deterministic wallet (or, it uses that functionality in its software). So all of these keys are determined by virtue of the seed that it generates at the start.

So, this is my understanding based on that other reading and using this Trezor blog post (https ://blog .trezor.io/wallet-accounts-and-addresses-bdfa6b66b037).

1. When my Trezor is initialized, it generates the recovery phrase based on entropy and the pre-defined word list.
2. It generates a seed/wallet from that. It can generate multiple through the passphrase feature by appending your selected passphrase(s) to the recovery phrase.
3. The rest of the keys can be determined based on the wallet structure and derivation paths. In the suite, when I choose to Add an account (or do it through activating a new coin), pre-defined standards determine the rest of of the keys.
   1. It generates an extended key for each coin type based on its pre-defined value (Bitcoin 0, Etherium 50, Litecoin 2, etc).
   2. It generates an extended key for each account based on the key for the coin, and the index of the account (1st account is 0, 2nd is 1, etc).
   3. It generates the public key which an address is derived from the account public key and an index.

By using the feature to add new coins, accounts, addresses, etc, it’s just bringing into the user interface the history that can be gained through scanning the blockchain(s) for transaction data related to the these pre-determined keys.

Probably have more questions, but will wait to get any feedback on this and probably create separate topics so its organized.

[matejcik]

That is pretty much exactly how it works, well done .)

@HockeyDevil07

by appending your selected passphrase(s) to the recovery phrase.

It’s not actually “appending”, it’s using the passphrase as a key for the HMAC. But that’s an implementation detail. Thinking of it as “appending” gives you the right results too.

@HockeyDevil07

It generates the public key which an address is derived from the account public key and an index.

In case of Bitcoin and other utxo-based coins, you continue by deriving a “payment” extended key and “change” extended key, and from those you generate keys for individual addresses.

In case of Ethereum and other account-based coins, you could stop at the account extended key and use it directly (an extended key can also be used as a normal private/public key, the “extension” is just additional data for the derivation process). For Historical Reasons™ we don’t do that but continue down the same “change” and “address” derivation steps.
(but, e.g., Monero or Stellar stop at the account level)

[HockeyDevil07]

@matejcik I’m an eager learner, I really want to understand haha. And man, I’ve posted the same types of questions in other community forums when I want to learn something mostly to get crickets. The fact that you were here to answer my questions is just awesome. Really appreciate it!

And not to mention the how mindblowing it is now to put that together. The actual cryptography stuff is still a little ethereal to me but now that I’m understanding the wallet on this level I can see how brilliant and powerful this stuff is.

I’ll probably have more questions later but for now I am satiated thanks a bunch!