So, consider two transactions Tx1 and Tx2, in this case Tx2 spends the output of Tx1.
The output of Tx1 contains the receiver's Hash160 public key.
When the receiver wants to spend his Bitcoin, he creates Tx2, which references Tx1's output as input.
In the scriptSig part of Tx2, the receiver inserts his signature and his original public key, then broadcast this transaction to the network.
If the scriptSig passes verification, then Tx1 is spent by Tx2.
Did I explain this correctly?
Yes, that is correct.
To get into more detail: the verification process is actually a program that runs and outputs "true" or "false" at the end of it, or crashes while running, which is treated as a "false". In the case of a normal address spend -- like the situation you are talking about -- the program is:
Step 1: keep the signature handy because we'll need it later
<signature>
Step 2: keep the public key handy because we'll need that also
<pubkey>
Step 3: make a copy of whatever data was in Step 2 (which in this case is the public key)
<OP_DUP> -- which stands for DUPLICATE
Step 4: make a hash160 of the copied data from step 3
<OP_HASH160>
Step 5: Put this other hash next to the hash we derived in step 4
<hash>
Step 6: Compare the two values produced by steps 4 and 5 (in this case, two hashes -- the one provided by the output, and the one derived by the scriptSig field's public key) and check to make sure the two hashes are equal, otherwise the transaction is invalid. Then, assuming they're equal, toss them out, so all we have is that original signature and public key from the first two steps.
<OP_EQUALVERIFY>
Step 7: Assume the two things left are a signature and public key and attempt to validate the signature with the given public key. If it's a bad signature, or if they're not a signature and public key, mark the transaction as invalid. If they are a signautre and public key and it's a good signature, output "true"
<OP_CHECKSIG>
That's the full program that runs. The "code" for that program is "written" by putting whatever code is in the spending transaction's signature field in front of whatever code is in the input transaction's output field, and combining them together, and running that combined code as a single program. If the program runs without fail and returns "true", the transaction is valid.
There are for example "addresses" where the output "address" code just says "return true" and the spending transaction doesn't have any code at all. And of course that combined program does indeed return true and is a valid transaction. And there are "addresses" that can never be spent. You've heard of "OP_RETURN"? Well that particular bit of code means "stop validating the transaction and return false". That's why those outputs can never be spent. Because eventually the code-checker hits that instruction and dutifully stops checking and returns false, making the transaction invalid.
The term "address" is really deceiving, because there aren't actually addresses. There are no accounts. There are only these little mini-programs that run. The term "address" is just for us humans to make Bitcoin seem easier. An "address" is just an output with a piece of code which gets executed when it is spent.
