Bitcoin transactions validation process

Question

I have a general understanding of building blocks. But am hoping someone can fill in the details/gaps. Also, can you correct if something is not right? Thanks.

Scenario:

1. Bitcoin transactions are broadcast to the bitcoin network.
2. Nodes receive the transactions.
3. Each node puts the transactions into their own internal mempool - or is it a network mempool that all nodes draw transactions from?
4. At some point, some nodes begin mining (hashing to find correct hash with leading zeros). When does this begin? I assume as soon as possible since it is a race. So then, it does not necessarily use the data in a fully built block, right?
5. At some point, the mining nodes fill up a block with transactions from mempool (they pull the ones with highest fees). Each node validates each transaction it puts into its block against the entire blockchain.
6. When a node finds a winning hash, it announces the winning parameters to the network.
7. The network can easily check the hash using the parameters (dataset, nonce value, etc.) that the winning node sends out.

So here's where I am a bit unclear. How/when do the transactions in the winning block get verified by the rest of the network? Is it during the time when they verify the winning hash? Do they also verify that all transactions are good at that time?

How many nodes must approve/verify the winning hash before it is accepted into the bitcoin network as the next block to be added?

Thanks.

Answer 1

Everything MCCCS wrote is good, but just to clarify on your last question:

How many nodes must approve/verify the winning hash before it is accepted into the bitcoin network as the next block to be added?

This question is slightly misguided: there is no 'accepting a block into the bitcoin network', because this assumes there is some network-wide threshold of acceptance that must be reached, or some sort of central yes/no switch for a block's acceptance.

The reality is that the network is made up of independently acting nodes. Each node decides for itself whether or not a block is valid, and it is by these 'consensus rules' that the network happens to come to agree on what the longest (most work) blockchain is. Once a valid block is broadcast, each node will independently work to verify that it is valid, and then add it to their local copy of the blockchain if it passes all the tests. The network is designed such that we expect all nodes that follow these consensus rules will remain in consensus, even though they are acting independently.

Answer 2

3: Each node has its own mempool. Each node validates the new transactions that they receive when they receive.

4-5-6: Nodes don't mine, miners do. Miners never stop, and each [some interval] they fetch a new block template from the pool operator's node, wh[ose merkle hash] includes new transactions. When they find a block, it is published and transactions in that block can't be changed.

Q: When nodes receive new blocks, they verify its hash (whether it's lower than the target difficulty), the previous block's hash it contains, and the transactions it has. (Notice that most of the accepted transactions are received twice by each node, which is what Compact Blocks] aims to solve)

Q: It doesn't matter, blocks propogate rapidly, and even if a (wrongly-designed) client rejects it, that block is still a part of the blockchain (as it is valid and there are no competing blocks)

Answer 3

I think if you add two more steps at the start then it makes more sense.

1. Transaction creation. (when User A sends coin to user B)
2. Transaction verification.

The transaction is transmitted to the neighbouring nodes and those nodes verify the transaction. If the transaction is valid those nodes transmit it further to their neighbouring nodes in the network. If the transaction is not valid it does not get populated in the network.