Offline generated transactions, how is a transaction signature verified?

[BTime]

I have been working with BTCurious' offlineTransaction JavaScript code.  It is nicely coded.
https://www.strongcoin.com/blog/the_easiest_way_to_create_secure_offline_bitcoin_transactions
I have added to it to make it helpful understanding transactions as well as adding comments.
I can make it available if someone helps me with that.  I'm not sure how to accomplish it at this time.

It can now specify a change account and it shows the transaction structure (in my text format and JSON).  It can also show the transaction structure for a transaction string (what the original program was designed to generate) and change coding for a public key, a transaction hash and a Bitcoin address.  This allows one to verify the data in a transaction with a form that is more often seen/found.

What I have not been able to do yet is signature verification.  The scriptSig contains the signature and the public key.  The signature is a hash of transactions with the private key.  The code documents how this is done.  According to BTCurious and others, it is done correctly and works.  I would like to verify this for myself.  I am not a cryptography expert, otherwise, I probably would not have to ask.

How is the public key used to verify the signature in a Bitcoin transaction?

Thanks in advance for any assistance.

[1714841911]

1714841911

[BTime]

Consider this post CLOSED.

I have determined the answer myself.  I find the documentation to be very confusing about this process.
I was reading at https://en.bitcoin.it/wiki/OP_CHECKSIG
The "How it works" section does not seem to make sense to me.
The very last sentence of the first paragraph at the top of the page explains it.

Transactions are verified using the requirement specified in the previous transaction by the entry that received the Bitcoins now being spent.
The controlling requirement for signature verification is defined by the transaction entry that transferred the Bitcoins to the account in the first place.
One would expect that the script for the previous_transaction receiving address will include:
OP_DUP OP_HASH160 {address} OP_EQUALVERIFY OP_CHECKSIG
so that signature verification will occur when the Bitcoins are "spent."  I don't know if that is required.  It is dependent on the Bitcoin sender's transaction "string."  The receiver has no control over this.  If this is not required, it seems like a flaw.

The process is:
For each Bitcoin transaction_source entry,
load the signature and the public key onto the stack,
look up the previous transaction specified in this entry's outpoint.hash and outpoint.index,
get the script from that previous_transaction entry,
duplicate and push the public key (already on the stack) onto the stack again,
calculate its RIPEMD160(SHA256(PK)),
push the Bitcoin address in the script just retrieved onto the stack,
compare the two, if equivalent, then, (note that this verifies the source of the Bitcoins from the saved transaction blocks)
generate a hash of the (usually) entire current transaction with all source entry's scripts removed and the current entry's script replaced with the script retrieved,
use the entry's public key and the signature and compare it to the hash for verification,
if verification is true, this is a valid entry, continue.

I hope that this helps anyone that views it.