What I don’t understand is the need for the hashing of B’s public key
Hashing the public key is done for two reasons. It is a cost saving measure as it reduces the size of A’s transaction. It also protects the actual public key so that, if Elliptic Curve Cryptography is broken, the private key cannot be reversed from the public key because the public key is not known until it is used in an input to a transaction.
and the previous transaction,
Including the hashing of the previous transactions lets a transaction refer to the transactions it is spending from so that you can verify whether the money is legitimate.
and what exactly is being verified/signed.
The message that is signed is the transaction (the one that is being created) itself. Of course it does not contain the signatures, but it contains everything else – the transactions being spent from and the outputs being created. This protects the other parts of the transaction from being modified by people not authorized to spend the money.
If transaction i – 1 is being hashed in transaction i, that means only transaction i – 1 is known. It says nothing about transaction i – 2, where the same money that is being spent in transaction i could have already been spent. It doesn’t seem like transaction i – 1 or i keeps a list of all previous transactions, so there’s no way of verifying where the buyer in i actually has the money.
i - 1 contains the hash of transaction
i - 2, which contains the hash of
i - 3, and so on and so forth until you reach transaction
i - i (the “first” transaction) which is a special transaction known as a coinbase. This is a coin generation transaction. Thus by following the entire chain of transactions backwards, you can verify if the money actually exists.