Topic: Detecting forks with bitcoind (Read 734 times)
Thank you for the answer. I'll look into it. I think it would be useful to create RPC API command to return info about such status. For example "getforkstatus 6" could return true if longest chain is longer or equal than next longest chain by at least 6 block. Additionally some --forknotify command-line parameter could notify about detecting blockchain fork...
If there is a longer fork with more work that your node thinks is invalid, you'll get this alert:
Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade.
(see the GetWarnings() function in main.cpp).
If you are on the fork with the most work... I suppose if the second-best chain was forked more than 6 blocks back and contained more than... oh, 5 blocks and the timestamp on the last block in that chain was less than ?an hour ago? that could trigger another alert.
All that might be tricky to implement-- either (or both) forks might themselves have forks. Or, theoretically, there could be three or more active forks, some of which might have equal proof-of-work...
Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade.
(see the GetWarnings() function in main.cpp).
If you are on the fork with the most work... I suppose if the second-best chain was forked more than 6 blocks back and contained more than... oh, 5 blocks and the timestamp on the last block in that chain was less than ?an hour ago? that could trigger another alert.
All that might be tricky to implement-- either (or both) forks might themselves have forks. Or, theoretically, there could be three or more active forks, some of which might have equal proof-of-work...
Is there any way to detect blockchain fork using bitcoind and RPC? I would like to suspend accepting incoming transactions during blockchain forks longer than or close to my level of required confirmations (i.e. 6). AFAIK client has to track all branches so this information is available in it. I think it could be important failsafe measure especially in light of ongoing discussion about replacing transactions with new ones with higher fee.
Jump to: