3

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?

|improve this question
  • 1
    What probability do you want? In fact there is only one transaction in the blockchain which can not be overwriten by reorganization. It is coinbase transaction in block #0 – amaclin Dec 7 '14 at 17:12
  • @amaclin according to bitcoin.stackexchange.com/a/4638/14319 there has never been a fork longer than 4 blocks except for the March 12 2013 blockchain fork which was 31 blocks long but according to my understanding it is unlikely to happen again, is that correct? All I'm looking for is a "safe" number of blocks after which a chain reorg is unlikely to happen. – Doug Peters Dec 7 '14 at 17:28
2

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.

|improve this answer
  • Thanks David. Do you believe that a grand fork like this one: bitcoin.org/en/alert/2013-03-11-chain-fork is likely to ever happen again? – Doug Peters Dec 7 '14 at 21:54
  • I'd be surprised if it doesn't happen again as we move into an era where miners use alternative full node implementations, block subsidies drop, and new variables like side chains are introduced. The remarkable thing to me is that we manage to maintain consensus as well as we do---that's really a credit to the hard work of the Bitcoin Core developers. – David A. Harding Dec 7 '14 at 23:21
  • Definitely we will see long forks. Especially if the difficulty will fall. Lower values of difficulty/hashrate give lower cost for double-spending attacks. – amaclin Dec 8 '14 at 9:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.