1
If at the middle of the execution of scriptSig + scriptPubKey we get the value 'True', while there are remaining values or operators in the stack, is the transaction valid? Or should the stack be empty + top result is 'True' ? I believe it is not because someone can just send unlocking script with the 'OP_TRUE' and cause any UTXO to be unlocked.
5
Contrary to the book Mastering Bitcoin, there is no boolean value of "True" in Bitcoin Script. An executed transaction script is valid when the top item remaining in the stack at the conclusion of execution is non-zero. To combat transaction malleability BIP62 (transaction version 3) also introduces the additional validity requirement that the stack must contain no additional data elements, only the single non-zero value.
3
I suspect you may have a misconception over how the script is executed, and what the stack contains during execution.
First, remember that the full script is created by adding the two partial scripts together in this order: scriptSig + scriptPubKey.
Each element of the full script is either a value which is pushed onto the stack, or an operation which examines and/or manipulates the stack.
A valid script is executed left to right until either the end is reached, or an operation indicates a failure. If the script completes without any operation indicating an early failure, then the top of the stack (alone) indicates the failure/success. As user Bitcoin has already said, any non-zero value is considered a success, and any items beneath the stack's top are (currently) ignored.
If someone tried to create a tx whose scriptSig was simply OP_TRUE, the entire script would typically look like:
OP_TRUE OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
The first script step pushes 1 onto the stack, next it's duplicated, and then the duplicate on top is hashed. After executing these first three script instructions, you'd have:
Stack:
HASH160(1) <-- stack top
1
Remaining (unexecuted) script: <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
Next <PubkeyHash> is pushed onto the stack, and then the two top elements (<PubkeyHash> and HASH160(1)) are compared, which causes the script to fail.
In short, because scriptPubKey is added after scriptSig, scriptSig has no way to "override" what scriptPubKey tells the script interpreter to eventually execute. (There's no such instruction as "exit immediately with success" that scriptSig could include.)
Finally, user Bitcoin also mentioned that BIP62 changes the "in the end, ignore everything but the top of the stack" rule. This will probably be true one day (and would make no difference in this example anyways), however as of today the rules in BIP62 haven't yet been implemented (except for the one also mentioned in BIP66).
