Question 1) It says that when bob makes a transaction to alice, that transaction goes to bob's malicious node. then bob changes signature so that It still stays valid transaction. and After that, there's a chance that this transaction will take place quicker than the original transaction that some other nodes have in mempool. and BOb has a chance of getting double * amount that alice is intended to transfer.
No, Bob will not get double. He will see two transactions that conflict with each other. No additional coins are created or spent. It is just annoying and wallets do not handle these conflicting transactions very well.
I'm curious what bob's malicious node change in a signature part that it still stays alice's signature and still valid? how is it possible?
The signature is malleable. An ECDSA signature is composed of two values, R and s. Due to how the signature verification algorithm works, it is possible to replace the s with it's negation (-s). -s is easily computable by a third party, so an attacker can compute -s, replace the s value with the inverse, and send the new transaction. Because the contents of the transaction are now different due to the replacement of s with -s, the transaction has a different id so is considered different. But it is still completely valid.
QUestion 2) How does segwit work? I know scriptSig is deleted from transaction, but where is it saved?
Segwit defines a new transaction format which is an extension of the original transaction format. In this format, a new field is added that is known as scriptWitness. The scriptWitness is where the signatures go. For nodes that do not have segwit, they only receive transactions in the old format. They won't see the scriptWitness.
The signatures are not deleted from the transaction. They are just moved elsewhere.
QUestion 3) if it's saved in blockchain still, then how is it a less size and how can block have more transactions than now?
Blocks are not actually physically smaller. The block size has increased without a hard fork.
What segwit also did was redefine the metric of block size from bytes to a new unit called weight. To calculate the weight of a block, you have to look at the transactions. Each byte of a transaction that is part of the original transaction format is counted as 4 weight units. Each byte that is part of the new segwit transaction format is 1 weight unit. The maximum number of weight units in a block is 4000000. The math works out such that an old node will not see a block with more than 1 MB of data (since they do not receive transaction in the new format).
So with this new definition of a weight unit, transactions without segwit have more weight units than transactions that use segwit. Thus transactions are "smaller" so more transactions can fit in a block.
Question 4) They say signature part is saved as the merkle root hash. but how can a node check that specific signature is related to specific transaction?
The signature is not saved in the merkle root hash. You cannot save any data in a hash. The signatures are committed to in the merkle root hash. What that means is that the data that went into the merkle root hash includes the signatures. This makes it so that the signatures cannot be once the transactions are in a block. The reason that this needs to be done is because the merkle root is only over the txids, which the scriptWitnesses are not part of (they are ignored in the txid calculation). So the full transaction hash (known as the wtxid) is used in a witness merkle root which is included in the coinbase transaction. This results in that hash being part of the coinbase transaction's txid which goes into the merkle root of the block.
