First, a quick overview of what happens when you submit a transaction to the network:
- Each node that hears about your transaction will check to see if it is valid according to their view of the network. If it is valid, the node may broadcast the transaction to its peers, and may add the transaction to its local mempool. If it is invalid, the transaction will be discarded (not broadcast further, not stored in the mempool).
- At some point, a miner's node will hear about your transaction. If it is valid and the fee-rate is sufficient, then the miner will add it to the block template that they are mining on.
- If the miner finds a block that includes your transaction, then we say the transaction is 'confirmed'. As this block propogates across the network, individual nodes will check to ensure it is valid, and then update their local copy of the blockchain (and their mempool) appropriately.
With that in mind, lets look at your questions:
1) Will every mining node that read from the pool both these 2 transactions discard the second one ? So as to put in a block only the first transaction (the correct one)
No, because the mining node will have no way to determine which transaction was truly 'first'. Many nodes follow a 'first seen' policy to determine which transaction they will broadcast and store, but given the choice between the two transactions, a miner could include either one.
2) Suppose that for some reasons a mining node A mines the first transaction in a block and propagate its blockchain to the network. At the same time a mining node B mines the second transaction in another block and propagates its blockchain to the network. This creates a fork in the blockchain. Will the other nodes of the network simply reject the B's blockchain because they know that transaction T1 is the correct one ?
This situation leads to what is referred to as a stale block (or sometimes, and orphan block). Nodes will store both blocks, and it will not be clear which block will be the 'winner' until a miner finds another block, that builds off one of the two blocks in question.
The other block will be discarded, and so if there are conflicting transactions (that spend the same input) in each block, it is only when one chain is extended that it will become clear which transaction will be included in the blockchain history.
Blockchain reorganizations like this are the reason for the often-cited '6 block confirmation' recommendation when receiving a transaction.
3) To me it seems impossible that double spending can happen, every node will almost immediately read transactions T1 and T2 from the pool and discard T2, or discard a block if it contains T2. So i don't understand the need for waiting for 6 confirmations to be sure a transaction is correct.
A certain output can only be spent once in the blockchain record, this is guaranteed by the network's consensus rules. So a 'double-spend' usually involves some trickery to defraud a transaction's recipient, by convincing them to accept a transaction that will not ultimately end up in the blockchain record. For example:
- Attacker sends txA to victim, while also creating txB that spends the same coins back to the attacker. Victim accepts the unconfirmed transaction, and releases payment/goods to the attacker. Later, txB is confirmed in a block, so the victim doesn't receive payment (txA is now invalid).
- Attacker sends txA to an exchange, while mining a block with txB (spending coins back to attacker, as above). txA confirms in a block, so the exchange credits the attackers account balance, and the attacker quickly withdraws coins (receiving a new UTXO on chain). At the same time, the attacker hopes to mine more blocks than the rest of the network, so that they can publish their longer chain (that includes txB instead of txA), and thus have txA erased from the blockchain history. This would leave the exchange without their deposit, but the attacker would still receive the withdrawal (since it would likely come from an unrelated UTXO that the exchange owned).
Thus, the 6 confirmation recommendation (see the link above for more info). Also worth noting: the 6 block confirmation rule is important even in cases where someone is not actively trying to defraud you: stale blocks happen naturally, so by waiting for multiple confirmations you help ensure you don't accept a transaction that is included in a block that doesn't end up in the eventual longest chain.
