Conflicted transactions in blockchain reorganizations When my service detects a conflicted transaction (either sent or received) it rollbacks everything that was logically built upon this transaction. The "problem" is that transactions can go from category conflicted to sent/received if a blockchain reorganization happens, so my question is how long (how many blocks) should my service wait in order to be positive that a conflicted transaction will never  get included into a block?

I have found this question to be helpful: What is the longest blockchain fork that has been orphaned to date?
I know you're looking for some magic constant, but it doesn't exist.  Your code needs to deal with reorgs of any depth back to the genesis block.

This may seem like a annoyance of dealing with the block chain, but it's how payments have always worked.  Even if some guy pays you with a suitcase full of verified gold bars, a court order can compel you to return those bars at any later point.  (For example, it's fairly common for the court to order stolen property returned to its previous owner without any compensation to its current owner even if the current owner didn't know it was stolen when he bought it.  This notably happens occasionally with art stolen 70 years ago during WWII.)

If you really want to take a shortcut and leave dealing with long reorgs up to some future programmer or database admin, then any arbitrary constant will do.  This is why many high-value sites require six confirmations---not because six is the correct value, but because approximately one hour of confirmations is a nice arbitrary value.