@hugeblack
The "bump fee of an opt-in rbf tx" feature of, for example, electrum is indeed using the rbf flag set on the original transaction to replace it with a transaction with a higher fee. But AFAIK, you can also replace the transaction with a transaction funding a totally different address. This is, however, not implemented into the gui of most popular wallets (because of obvious reasons).
bitcoind -help | grep zapwallettxes:
Delete all wallet transactions and only recover those parts of the blockchain through -rescan on startup (1 = keep tx meta data e.g. account owner and payment request information, 2 = drop tx meta data)
Basically, by starting bitcoind with these arguments, and re-using the same unspent outputs, you have created a double spending transaction. Most nodes will reject this tx unless the original transaction had the rbf flag set.
What i'm trying to say:
It doesn't matter if you're bumping the fee of a tx with the rbf flag set, or if you zap your wallet txes and then re-use some of the same unspent outputs, or if you create a new transaction using the same unspent outputs that have been used for an unconfirmed tx with the rbf flag set. You're basically double spending in all these cases. The big difference is that if a tx has the rbf flag set, you're basically telling the node it's OK to replace the original transaction, whilst if this flag is not set most nodes will reject the double spending transaction.
Bottomline: if you're selling something, wait for a confirmation before delivering goods or services. If the tx that's being used to pay you is opt-in RBF, defenately wait for one confirmation. The RBF flag is not evil, in times of mempool congestion i'd urge everybody to opt-in rbf, but chances of getting scammed when accepting 0 conf tx's are slightly higher when this flag was set.
