There are plenty of projects now that listen to bitcoind using its rpc interface and maintain a complementary view of the block-chain in a SQL database, sometimes adding extra information. These applications generally poll bitcoind at regular intervals. It's very difficult to audit how these applications respond to changes in the best-chain that involve a block rollback. Many times those application break because they were not tested enough in chain split scenarios. Also when creating another full bitcoin implementation, is good if one can simulate these scenarios by connecting the node in development to bitcoind and commanding bitcoind.
Is there a way to do this already? If not, then I propose the addition of a new rpc command "truncate-and-submit-blocks": truncate-and-submit-blocks block-height number-of-blocks-to-submit block1-in-hex ... blockN-in-hex
The idea of allowing the submission of multiple blocks is that the additions are done atomically, so other connected applications can be tested for sudden best-chain switches without other unpredictable race conditions.
Also it's possible to implement only "truncate block_hight" but this requires the testing script to control when the complementary application polls for new data.
Also a block-chain locking mechanism could help, allowing something like the following rpc commands:
lock-block-chain truncate 200000 submitblock .... submitblock .... unlock-block-chain
