Using EQUALVERIFY with different public keys, but generated from the same seed

Question

I am building certain system that involves Bitcoin and therefore I need to understand well how it works under the hood.

In order to receive funds, for every new transaction new public key and its hash should be generated. I assume that is done via extending the parent public key and generating new child key for every transaction. All of that makes sense, up until the point when the user who previously received funds, let's say Mike, decides he wants to use funds he received and send them to someone else, let's say Alice. In that situation he has to construct unlocking script with signature and public key that he submits to stack in addition to locking script attached to his previous address where he received funds. Locking script also (in addition to operators) has a public key. Now, at one point EQUALVERIFY function will be executed which is supposed to compare public key hash from locking script and the one from unlocking script and see if they are the same.

My question is, if for every transaction new public key is generated, then how will we even know which public key was used for certain transaction? Although, all of the keys are generated by same user and global seed, they can differ and as far as I understood EQUALVERIFY just performs basic equality operation. It doesn't check if two public key in some way originate from same seed. That would mean that if public keys from both scripts are not exactly the same, EQUALVERIFY will return FALSE.

I believe I am missing some piece of this process. Thanks!

Answer 1

Multiple keys can indeed be derived from the same master key or seed, but it's important to realize that this results in distinct public keys as well as distinct private keys. The public key is converted to an address, handed out, transactions are received on that address, and to spend the received output then, the public key is revealed together with a signature with the corresponding private keys.

In other words, the blockchain and the nodes verifying it do not know or care which keys were generated from the same seed. That is purely a local wallet decision. Nodes just see distinct public keys, and signatures with their corresponding private keys. In fact, the very earliest wallet software did not use seed/master key derivation, and just used randomly generated keys for every new address.

To determine which private key to sign with (and which corresponding public key to reveal), wallets just keep a map around from all public key hashes they have generated to the information about their derivation (which index in the derivation, possibly which parent key it was derived from).

When setting up a new wallet using existing seed phrase the wallet can potentially reconstruct the map of the keys easily. Since all the child keys derived from the parent are derived in a deterministic way, the wallet can just derive hundreds or even thousands of potential keys and addresses where transactions might have landed at some point of time. Then the blockchain can be checked for those addresses and see if the record about them exists on the chain and if they indeed received any funds.