Understanding how validation of a transaction works

Question

As far as I understood, a transaction works like this:

Alice wants to send 5 BTC to Bob. Alice creates her digital signature that contains transcation info like id etc. She encrypts the signature with her private key. She creates scriptPubKey and scriptSig, she has the Bitcoin-Adress of Bob.

This transaction has to be verified by nodes. A node checks this transaction. He checks if Alice really has 5 BTC by checking her input. If it's ok, then all is fine. The node additionally checks Alice's digital signature. The node extracs Bob's Bitcoin Adress from Alice's signature. If it's ok, the Node puts the transaction to the mempool.

Nothing was mined until here. Now, due to the broadcast system and p2p network of Bitcoin, a Miner picks this transcation from the mempool.

What does he do now? Does he assume, that the transaction is valid or does he check the transaction again ?

If he does not check the transaction again, and assumes, that the transcation is valid, he creates a Merkle-Tree of several transactions, puts it in a block. Uses SHA-256(Blockhash+nonce) and tries to mine.

Is that right, what I've understood so far or did I make a mistake ?

Answer 1

Alice creates her digital signature that contains transcation info like id etc.

The digital signature only applies to certain inputs and outputs within the transaction, depending on the SIGHASH type. The default is SIGHASH_ALL, in which case all inputs and outputs are signed by every participant in the transaction (where one participant equals the required keys for an input). It is possible that all participants are actually the same key (or set of keys for a multisig address).

She encrypts the signature with her private key.

Nothing is encrypted. The signature is over plaintext data, and the signature is serialized into the tx as is. There is no encryption anywhere.

She creates scriptPubKey and scriptSig, she has the Bitcoin-Adress of Bob.

The scriptPubKey is created prior to the signing, as it is part of the unsigned transaction in the vout. The scriptSig is created using the signature and the public key (when spending a pay-to-pubkey-hash input), or the redeem script (when spending a pay-to-script-hash input). For segwit addresses, the signature and witness program are not serialize within the input, but are added to a special witness field in the transaction.

The node extracs Bob's Bitcoin Adress from Alice's signature

Bob's address is part of the vout set in the transaction. It is not included in the signature. In certain SIGHASH types, the output is signed and verified by the signature, but it is not included in it.

a Miner picks this transcation from the mempool.

Every node maintains its own mempool. The correct flow would be:

• The transaction makes its way across the p2p network to the miner's node
• The miner's node verifies the transaction
• If valid, the tx is added to that node's mempool
• The tx may make its way into the block template being mined at some point, depending on the fee.

he creates a Merkle-Tree of several transactions, puts it in a block. Uses SHA-256(Blockhash+nonce) and tries to mine.

Only the merkle tree root is added to the block header.

The hashing operations are performed on the block header, which contains the nonce.

The merkle tree is not stored anywhere. When needed, it is constructed from the list of transactions in the block.