Don't confuse RBF with double-spend! That's totally not the same thing. Double spending is an attack scenario where you spend the same funds twice (like, to 2 different addresses). RBF just allows you to bump the fee to have the transaction be verified quicker.
Actually RBF is like a sub-category of double spend.
Technically speaking when the same UTXO is spent in 2 different transactions, we call that a double spend. When you bump the fee of a transaction you are actually creating an entirely different transaction (it has to even be signed again) and the fact that the two transactions differ only in the output amount doesn't change that.
What RBF does is that it "reserves the right to double spend" the UTXOs in a tx marked by RBF for the signer but with certain restrictions, such as the increased fee has to be proportional to the tx size not any small amount.
Okay, yes, I stand corrected! I wanted to clarify though that there is a difference between let's say 'allowed double-spend through RBF' and 'malicious double-spend'. As long as you wait for your confirmations, you're good, no matter if the sender used RBF or not; and the
Hal Finney attack is possible with RBF on or off, from my understanding.
By the way, very interesting, if you scroll down a bit there's a so-called vector76 attack, which is possible even though as a recipient you see 1 confirmation. So I would always wait for like 3 confirmations if I'm in a hurry and the amount is not larger, but for anything else 6 confirmations.
You don't need to mine 2 blocks in a row. Mining a single block is sufficient if the network resolves the fork the way you want, and it might be possible to set things up so that this is likely.
Let's say I observe the timing of when nodes are broadcasting transactions and how they are propagating through the network. By watching for which nodes are earliest to broadcast transactions from my target, I manage to establish a direct connection to my target.
I use a similar method of watching block broadcasts to establish connections to most of the mining pools.
Now I create a transaction making a valid, large deposit into my target. I do not broadcast this transaction but I add it to a block that I am attempting to mine. I mine solo, just like normal, except that I have an extra non-broadcasted tx that I am including.
Eventually, I succeed in creating a valid block. I do not broadcast it immediately, but instead I wait until someone else mines a block, and when that happens, I immediately broadcast my block to my target. If my target sees my block before the other block, they will accept it, and my transaction will have one confirmation. The block chain has forked, and my target (and possibly other nodes, if my target relays quickly enough) will believe that my block is the correct one, while other nodes will believe that the other fork is the correct one.
I immediately request a withdrawal, and my target generates a transaction sending the large amount of coins to an address I control. I also double-spend some of the inputs, sending the coins to myself. The part of the network that did not receive my block first (which hopefully is most of the miners) will accept this as valid and work to include it in the next block.
If my block eventually "wins" because enough miners saw my block first and added onto it first, then I have just made a deposit and withdrawal, and I lose nothing.
If my block eventually "loses", then the deposit is invalidated. If the deposit tx was not one of the inputs to the withdrawal transaction, then the withdrawal is still valid.