You said is possible for a pool operator to coordinate with a scammer to include the scammer's transaction in their block.
If transaction is verified by a node operator it will stay in the operator's mempool until a miner will add it to a block.
The only scenario that could work is this:
The scammer creates tx1 and tx2 that are spending the same exact UTXOs (double spend) but have different outputs. The scammer sends tx1 to the bitcoin network so it propagates among all nodes and sends tx2 to the participating pool so only that pool sees the double spend and nobody else.
So at this point, everyone's mempool has tx1 so the person receiving the funds in tx1 sees the good propagation and lack of double spend and accepts the unconfirmed transaction and makes the trade. Then the first block found by that pool contains tx2 and invalidates tx1, effectively ripping off the receiver.
Obviously, this is solved if the receiver waits for confirmation.
That's one example. If we want to take a look at a more extreme example, imagine the following:
uchegod-21 will play the part of the naive scam victim.
DannyHamilton will play the part of the scammer.
pooya87 will play the part of a mining pool operator willing to collude in a scam.
- DannyHamilton agrees to purchase a VERY valuable NFT from uchegod-21 for 18 BTC.
- uchegod-21 agrees to provide the NFT to DannyHamilton after he sees 1 confirmation on the Bitcoin blockchain because he heard that transactions are permanent once they are confirmed.
- DannyHamilton notices that the mining pool operated by pooya87 has a LOT of hashpower and that it OFTEN solves 2 or more consecutive blocks
- DannyHamilton contacts pooya87 and tells him that if the pool succeeds in assisting, then he'll pay pooya87 10 BTC
- pooya87 agrees to attempt to help
- DannyHamilton creates 2 transactions. Transaction_A that pays uchegod-21 18 BTC, Transaction_B that spends the exact same bitcoins but pays pooya87 10 BTC, and the remaning 8 BTC are sent to a second address that DannyHamilton controls.
- DannyHamilton provides pooya87 Transaction_B and asks pooya87 to include it in the pool's next block AND let him know when the mining pool has solved the block, but NOT to broadcast the solved block to the network. Instead, he tells pooya87 to have the pool immediately start working on a second block on top of the solved block, and broadcast both blocks together once the second block is solved.
- As soon as DannyHamilton hears that pooya87's pool has secretly solved the first block (Secret_Block_1), he broadcasts Transaction_A paying the 18 BTC to uchegod-21. (This block is at block height x)
- At some time after that some other miner solves and broadcasts a block (Public_Block_1) that includes this Transaction_A and uchegod-21 sees a confirmation. Transaction_A is in the blockchain. (This block is also at block height x)
- uchegod-21 immediately sends the NFT to DannyHamilton
- A short while later, pooya87's pool solves a second block (Secret_Block_2) on top of the secret block (Secret_Block_1) that contains Transaction_B (This block is at block height x+1)
- pooya87 broadcasts BOTH of the blocks (Secret_Block_1 and Secret_Block_2) that his pool has solved.
- The entire network sees that this is a longer chain (Their current chain that includes Public_Block_1 is only x blocks long, whereas this new chain that includes BOTH Secret_Block_1 and Secret_Block_2 is x+1 blocks long)
- The entire network (including the wallet that uchegod-21 is using) abandons Public_Block_1 and replaces it in their own copies of the blockchain with Secret_Block_1 AND Secret_Block_2.
- Suddenly uchegod-21 no longer has the 18 BTC. The transaction paying him those bitcoins doesn't exist.
- Initially the nodes all consider adding Transaction_A back into their mempool to be confirmed later (since it was in the block that was replaced and is not in the replacement blocks). However, when they attempt to validate Transaction_A before putting it back in their mempool, they see that those bitcoins are already spent in their blockchain (in Transaction_B). Therefore, they reject Transaction_A entirely as an invalid transaction.
- DannyHamilton quickly finds a buyer for the NFT for 16 BTC, and completes the transaction before uchegod-21 can make it publicly known to the world that he's been scammed.
- The participants of pooya87's pool all go paid their normal expected payouts, and don't even realize that they participated in the scam.
- pooya87 himself is 10 BTC richer.
- DannyHamilton is 6 BTC richer (acquired an NFT for free, sold it for 16 BTC, paid 10 BTC of that to pooya87).
- uchegod-21 lost a very valuable NFT, and in exchange, he received a very important life lesson about needing multiple confirmations on very high-value transactions.
Now, there are no risks to DannyHamilton at all. Worst case, if pooya87's pool fails to find that second block before the public blockchain adds a second block then DannyHamilton paid 18 BTC for an NFT worth 18 BTC. DannyHamilton gets a fair deal and so does uchgod-21 in that situation.
pooya87 did take on some risk in this situation though, which is why DannyHamilton needed to offer pooya87 the majority of the profits in order to convince pooya87 to cooperate. If pooya87's pool couldn't solve that second block fast enough, then he wouldn't get the 10 BTC payment from DannyHamilton (remember DannyHamilton agreed to pay pooya87 "if the pool
succeeds in assisting"). If pooya87's pool doesn't solve that second block fast enough, then pooya87 will be sitting on a secret block (Secret_Block_1) that is invalid. He therefore won't ever get paid the usual 6.25 BTC (at today's block subsidy) for having solved that block. Normally, he wouldn't get to keep most of that 6.25 anyhow (since he'd have to pay the pool participants for their shares in mining that block). Now, if he's set this all up carefully enough, then perhaps his pool participants won't know about Secret_Block_1, and therefore they won't expect to be paid for solving it. In that case, pooya87 only loses out on the small percentage of that block reward that he would normally get to keep as a pool operator. However, if he's paying his participants for every share they submit, then he's going to owe his participants nearly 6.25 BTC of his own money to keep them from wondering why their revenue dropped suddenly for a few blocks.
This exact same scam can be pulled off for 2 blocks (2 confirmations) or 3 blocks (3 confirmations) or more, but the risk to the pool operator grows with every additional block. First, the chances that they'll actually be able to stay ahead of the rest of the network long enough to succeed becomes much much smaller with each additional block needed. So their chances of successfully accomplishing the attack approaches 0% very quickly. Second, the amount that the pool fails to earn from the blocks that they don't broadcast increases by 6.25 BTC (at today's block subsidy level) for every additional block. So, it becomes a more expensive attack with a smaller chance of succeeding.
This is why a lot of services are willing to accept transactions after 3 blocks. At that point, any cooperating pool is risking 18.75 BTC (over $800,000 at today's exchange rate), and trying to hide this fact from their participants long enough to solve 3 blocks in a row without anyone noticing. Meanwhile, unless the pool controls nearly half of the entire world's hashpower, the chances that they will solve the next 3 blocks in a row before the rest of the world succesfully solves 3 blocks are very very slim. Now, if you were accepting a transaction valued at 200 BTC or more, then there's enough of a pay-off there that it might be worth for a pool to try. In that case, the transaction recipient might require 4 confirmations (or more). For smaller amounts, 3 confirmations is probably enough.
It's up to the transaction recipient to be aware of the value of the transaction and to make a demand for a reasonable number of confirmations before allowing the transaction sender to receive whatever they are getting in exchange for the bitcoins.
Alternately, the transaction recipient can make sure that they have some other method of enforcing payment. If I have a strong personal relationship with the transaction sender, and I know with relative certainty that I'll be able to find them and force them to pay, then I can accept fewer confirmations (perhaps even 0 confirmations). If I am holding as collateral something of value that belongs to the transaction sender, then I can perhaps accept less (even zero) confirmations with the knowledge that I can simply refuse to release the collateral. These are but a few examples where it may make sense to accept few or zero confirmations. Perhaps you can think of others. Essentially, any situation where you might be willing to accept a paper check written against a bank account is a situation where you might also be willing to accept a bitcoin transaction with zero confirmations. A check might be written against an account with insufficient funds. A Bitcoin transaction with zero confirmations might not ever confirm, and may become invalid before it can confirm.